技術要約：オープンソースのLLMエージェントは静的アプリケーションセキュリティテスト（SAST）ツールを代替できるか？

問題提起

本論文は、エージェンティックAI（Agentic AI）、具体的には汎用的な大規模言語モデル（LLM）エージェントが、サイバーセキュリティの脆弱性スキャンにおいて、従来の静的アプリケーションセキュリティテスト（SAST）ツールを効果的に代替、あるいは匹敵することができるのかという、台頭する問いに取り組んでいる。生成AIはコード生成に革命をもたらしたが、著者らは、コードの「セキュリティ適合性」を検証する上でのその有効性を調査している。核心となる問題は、現代的なオープンソースの汎用LLMエージェントが、現実的な条件下でPythonコードベース内の一般的な脆弱性（例：SQLインジェクション、不適切なシークレット、パス・トラバーサル）を信頼性高く特定できるのか、それとも、確立されたルールベースのツールと比較して、固有の限界（ハルシネーション、高い誤検知率、説明可能性の欠如など）に苦しむのかを判断することである。

メソドロジー

本研究では、カスタム構築されたLLMエージェントと、検証済みのオープンソースSASTツールとの間の実証的な比較を行った。

• ベースライン・ツール: 低い誤検知率と中程度の精度で知られるPython特化型SASTツールであるBanditを、「正解（ソース・オブ・トゥルース）」および比較のためのベースラインとして使用した。
• 実験用エージェント: ディレクトリを再帰的にスキャンするように設計されたPythonベースのエージェント・アプリケーションであるSnitch。Snitchは、ローカルLLMのホスティングおよび実行にOllamaを活用している。
• 評価対象モデル: 以下の3つの異なるオープンソース汎用モデルをテストした：
  1. Gemma3 (Google): コーディング特化型としてマーケティングされている。
  2. Llama3.1 (Meta): 汎用LLM。
  3. Qwen2.5 (Alibaba): 推論、コーディング、デバッグを意図している。
• テスト対象: 複雑性と成熟度が異なる3つのオープンソースPythonリポジトリ：
  1. Yum: 引退したエンタープライズ級のパッケージマネージャー（高成熟度）。
  2. Beaverhabits: 個人の習慣トラッカー（カジュアルな商用）。
  3. Fail2ban: セキュリティ指向のサービスデーモン。
• 実験設計:
  • Banditですべてのリポジトリを最初にスキャンし、MediumおよびHighレベルの検出結果のベースラインを確立した。
  • 次に、Snitchが3つのモデルそれぞれを使用して、同じリポジトリをスキャンした（計9回のエージェントスキャン）。
  • プロンプティング: すべてのエージェント実行に対して、特定のSAST問題を特定する専門のサイバーセキュリティエンジニアとして振る舞い、結果を構造化されたJSON形式で出力するよう指示する、固定された詳細なプロンプトを使用した。
• 評価指標:
  • 再現率 (Recall): Banditが検出したMedium/Highレベルの検出結果のうち、エージェントによっても検出された割合（部分一致は0.5として重み付け）。
  • 誤検知 (False Positive: FP) 率: エージェントがフラグを立てたものの、Banditによってフラグが立てられず、人間によるレビューの結果、文脈の誤解またはハルシネーションであると判断された割合。
  • 複合スコア (Composite Score): 再現率 - FP率 として算出。
  • 実行時間 (Execution Time): 効率性を比較するために記録。

主要な結果

実証データは、評価されたオープンソースのLLMエージェントが、従来のSASTツールと比較して大幅にパフォーマンスが劣っていることを示している。

• 低い再現率: いかなるモデルも、0.25を超える再現率を達成できなかった。エージェントはBanditが特定した脆弱性の大部分を見逃した。
• 高い誤検知率: すべてのモデルが、**40%から90%**に及ぶ極めて高い誤検知率を示した。
  • 一般的なハルシネーションには、標準ライブラリの定数（例：calendar.MONDAY）をハードコードされたシークレットとしてフラグを立てる、.env ファイルの使用をプロダクション環境への漏洩と誤解する、あるいは無害なコードパターン（コメントやライセンスヘッダーなど）を脆弱性と識別するといったケースが含まれる。
  • Gemma3が最も高いFP率を示し、Qwen2.5が最も低かったものの、依然として相当なものであった。
• ハルシネーションと正確性:
  • エージェントは、脆弱性の場所（ファイル名および行番号）を頻繁にハルシネーション（捏造）し、存在しないファイルやコードブロックを参照した。
  • エージェントは時折、Banditが見逃した独自の課題（特定の不適切な requests.get の使用やパス・トラバーサルなど）を特定したが、これらは外部の正解（グラウンドトゥルース）なしには検証不可能であり、ノイズによって相殺された。
• パフォーマンスと効率性:
  • Banditは、リポジトリあたり1分未満でスキャンを完了した。
  • Snitch（LLMエージェント）は、コードベースのサイズに応じて、リポジトリあたり1〜4時間を要した。
  • 3つのモデルすべてにわたるエージェントスキャンの総実行時間は、Banditの数分に対し、約10〜12時間であった。

主な貢献

1. 実証的評価: 本論文は、理論的な推測を超えて、精度、再現率、FP率といった測定可能なパフォーマンス指標を用いて、SASTにおけるエージェンティックAIの厳格なデータ駆動型評価を提供している。
2. ベースライン比較: Banditを用いた直接的なパフォーマンス・ベースラインを確立し、汎用的なオープンソースLLMが現在のところ、専門的なセキュリティスキャニングタスクに必要な信頼性を欠いていることを実証した。
3. 限界の特定: LLMエージェントにおける特定の失敗モード、特に脆弱性の場所に関する「ハルシネーション」や、標準的な開発パターン（環境変数など）をセキュリティ上の欠陥と誤解する現象を浮き彫りにした。
4. 複合スコアの導入: 見逃された脆弱性とノイズ生成のトレードオフを包括的に評価するために、複合スコア（Recall - FP Rate）を導入した。

意義と主張

本論文は、現代のオープンソースGenAI LLMベースのエージェントは、現在のところ、現実的な条件下でのSASTスキャニングという専門的なタスクには適していないと結論付けている。

• 信頼性のギャップ: 高い誤検知率と低い再現率は、これらのエージェントをスタンドアロンのセキュリティツールとして信頼できないものにしている。「ハルシネーション」による脆弱性の場所に関する情報は、開発者が特定のファイルや行番号を信頼できないため、自動的な修復（レメディエーション）のための出力としてはほぼ無価値である。
• 効率性の障壁: LLMエージェントに要する計算コストと時間（数分 vs 数時間）は、標準的なCI/CDパイプラインへの統合において、ルールベースのツールと比較して禁止的な障壁となっている。
• AIの役割: 著者らは、エージェンティックAIはコードの生成や支援においては有望な兆しを見せているが、現在は検証に必要な精度と説明可能性が不足していると指摘している。本論文は、一貫性、速度、および追跡可能性の観点から、従来のルールベースのツールの方がコード分析において優れていると論じている。
• 将来の展望: 著者らは、クローズドソースまたは高度なプロンプトエンジニアリングを備えた特化型モデルであれば、結果を改善できる可能性があると述べているが、生成システムの本質的な限界（ハルシネーション、CVE定義のような外部知識ベースの欠如）が、現在、確立されたSASTツールを置き換えることを妨げていると考えている。彼らは、エージェントが従来のツールの「置き換え」ではなく、新しい問題のみに焦点を当てる「補完」として機能するという、ハイブリッドなアプローチの可能性を示唆している。