敵対的AIに先手を打つ ― エージェント型ソースコードレビューによるアプローチ

執筆者: Alex Tselevich、Michael Maturi

脅威モデリング

AIをコードセキュリティ分析に活用する際にまず重要となるのが、対象コードベースに対する脅威モデルの構築です。ソフトウェアアーキテクチャは千差万別であり、脅威モデルがなければ、攻撃ベクトル、ビジネスロジック、到達可能性といった貴重な文脈情報を見失いかねません。

従来のソースコードレビューエンジンが硬直的なパターンマッチングルールに依存しているのに対し、LLMには、一般ユーザーがアクセスできるコードと、管理者に限定されたコード、あるいは実行されることのないコードとを区別できるという明確な利点があります。

私たちのパイプラインはまず、Explorerエージェントを投入して対象コードベースの中核的な目的を特定するところから始まります。このエージェントはソフトウェアの領域(Webアプリケーションかデスクトップアプリケーションかなど)を判定し、発見済みのドキュメントをレビューし、スキャン対象から除外すべきディレクトリ(単体テストを含むものなど)にフラグを立て、Specialist Explorerサブエージェントを投入します。

これらのSpecialist Explorerは、認証、認可、ルーティングなど、それぞれの専門領域を詳細に調査します。その出力はThreat Model Synthesisエージェントに渡され、各知見を統合して一貫性のある脅威モデルにまとめ上げます。

この段階の分析が完了すると、コンサルタントには脅威モデルのテキスト表現とビジュアル表現の両方が提示され、分析を続行する前に検証を行います。この承認ゲートにより、パイプラインの以降の工程が正確な基盤の上で動作することを担保します。

図3は、本ハーネスが生成した視覚的脅威モデルのレイアウト例で、どのアプリケーションコンポーネントが外部に露出しており、それらがどのように接続しているかを示しています。

エントリーポイントの発見

脅威モデルが確立されると、対象範囲内のすべてのファイルを分析するために並列化されたDiscoveryエージェントを展開します。これらのエージェントは軽量なGemini Flash Liteモデルを使ってコードを大規模に処理し、HTTPルートやプロセス間通信(IPC)リスナーなど、ドメイン固有の攻撃ベクトルを含む重要なアプリケーションのエントリーポイントを抽出します。同時に、これらのエントリーポイント内にネストされたユーザー入力の識別可能なすべてのソースを分離・抽出します。

コンテキストの拡充

分析対象のエントリーポイントが選定されると、ハーネスはそれぞれを専用のEnrichmentエージェントに割り当てます。エンタープライズアプリケーションでは、エントリーポイントを単独で分析するだけでは不十分な場合がほとんどです。サニタイザーや権限設定、ルーティング条件といった重要なコンポーネントは、しばしば広範囲に分散しているためです。

さらに、脆弱性はネストされた関数呼び出しの奥深く、元のソースから何段階も、複数ファイルにまたがった先に潜んでいることが少なくありません。このギャップを埋めるため、Enrichmentエージェントはコードベース内を移動し、割り当てられたエントリーポイントに関連するコードを文脈情報として集約します。そして、この集約したデータを評価し、そのエントリーポイントにAccess ControlエージェントによるさらなるDeeper分析、Data Flow Analysisエージェントによる分析、あるいはその両方が必要かどうかを判定します。

仮説の生成

効果的なコード分析は、制御フローとデータフローという2つの主要な特性を観察することにかかっています。制御フローがタスクや命令の実行順序を規定するのに対し、データフローは情報がアプリケーション全体をどのように移動し、変換されていくかを追跡します。

私たちのAVDHは、これらの重要なタスクをそれぞれAccess ControlエージェントとData Flow Analysisエージェントに委任しています。

この段階では、これらのエージェントによる自己検証は最小限にとどめています。主な目的は、幅広くブレインストーミングを行うことにあるためです。生成される仮説の膨大な量を管理するため、この創造的なプロセスはコンサルタントが設定するConfidence Filterによって制御されます。

Access Controlエージェントは、対象エントリーポイントを取り巻く保護機構を評価し、アプリケーションのユーザーにとっての全体的なアクセス可能性を判定します。その主な目的は、セキュリティ上の前提を検証すること、そして特権機能が制限されているか、あるいは意図せず権限のないユーザーに露出していないかを確認することです。この分析により、チェックがそもそも行われていなかったり、誤ったIDに対して行われていたりする欠陥、たとえば認可漏れ、権限昇格、クロスサイトリクエストフォージェリ(CSRF)といった問題が明らかになります。

一方、Data Flow Analysisエージェントは、初期のエントリーポイントからアプリケーション全体にわたるユーザー入力の流れを追跡します。ネストされた関数呼び出し、サニタイザーによる変換、データベースなどのストレージ境界をデータがどのように通過していくかをトレースします。

このエージェントの目的は、ユーザーが提供したデータが最終的に危険な「シンク」、すなわち悪意ある入力が実行されて害をもたらしうる関数に到達するかどうかを判定することです。この綿密なトレースにより、SQLインジェクション、クロスサイトスクリプティング(XSS)、コマンドインジェクション、パストラバーサルといった脆弱性クラスが明らかになります。

仮説の検証

対象コードベースに対して仮説が生成されると、私たちのハーネスは新たなエージェント群を投入してそれらを検証します。LLMにおいて、温度(temperature)パラメータは出力のばらつきやランダム性を左右します。温度が低いほど予測可能で安定した応答が得られる一方、高い値では毎回まったく異なる結果が生成されることがあります。

私たちのハーネスはこれを利用し、高い温度設定を施した複数のValidationエージェントを投入して各仮説を評価させると同時に、それらの判定を処理して最終決定を下す単一のValidationSynthesisエージェントを配置しています。高い温度を用いることで、予測可能でありきたりな応答よりもはるかに幅広い可能性を検証範囲に含めることができます。最終的に、この温度設定は、最終判断を下すエージェントにより豊かで包括的な文脈情報を提供することになります。

Synthesisエージェントは、Validationエージェントによる推論と判定を評価し、その仮説が私たちの厳格な品質基準を満たし、全体の脅威モデルと整合しているかどうかを判定します。ここから、3つの結果のいずれかに分岐します。

• 確認済みの検出結果: 仮説が堅牢であり、Validationエージェントが独立してそれを検証した場合。

• 反証された仮説: Validationエージェントが、その欠陥の妥当性に異を唱える有力な矛盾証拠を示した場合。

• 却下された仮説: 仮説が確立済みの脅威モデルと整合しない、あるいは脆弱性の要件を満たさない場合。

人間の専門知識

専門家による検証

ハーネスが確認済みの検出結果を重複排除し、リスク評価を行った後も、私たちは人間の専門家による厳格なレビューを通じて分析を継続します。エクスプロイトを動的に再現し、概念実証(POC)コードを実行することでデューデリジェンスを行い、AIの前提が正確であること、そして攻撃経路を妨げる見えない補完的な統制が存在しないことを検証します。

検証が完了すると、コンサルタントはAIが生成した検出結果を自らの専門的な分析と統合し、正式な開示に向けて準備を進めます。逆に、この動的テストの段階を通過できなかった検出結果は破棄されます。

同様の脆弱性発見ハーネスの導入を検討しているネットワーク防御担当者の皆様には、検出結果を手作業で検証することを強くお勧めします。

蒸留された知識

確認済みの検出結果に対するヒューマン・イン・ザ・ループ検証は誤検知(false positive)の抑制には効果的ですが、見逃し(false negative)への対処も依然として必要です。

AIエージェントが見落とした脆弱性がないかどうかを判定するため、私たちはMandiantの専門知識を分析パイプラインに直接注入するルールベースのアプローチを考案しました。これは、スキルエンジニアリングの概念に似た手法で、コンサルタントたちの集合知から蒸留した高度に専門化されたプロンプトを用いるものです。

この人間の知見をAI主導の分析に直接統合することで、結果の精度は大きく向上します。この知識システムをモジュール化かつスケーラブルな状態に保つため、私たちはソフトウェアの領域を頂点に、言語、フレームワーク、脆弱性という3つの主要なルールカテゴリを続ける階層構造として構築しました。

フレームワークおよび言語に関するルールはパイプライン全体に適用され、対象コードベースで使われている特定の技術についてコンサルタントの知見をエージェントに与えます。これらのルールには、一般的なエントリーポイントの定義パターンや固有の攻撃対象領域といった重要な詳細に加え、脅威モデリングに不可欠な追加の文脈情報が含まれます。

これに対し、脆弱性に関するルールはパイプラインの最終段階でのみ適用され、特定の種類の脆弱性をどのように発見し、検証し、リスク評価するかを正確に規定します。この構造化されたシステムにより、分析パイプライン全体に、保守可能かつ高度にモジュール化された形でMandiantの人間の専門知識を注入することができます。

成果の測定

エージェント型コード分析パイプラインを維持し継続的に改善していく上では、正確なベンチマークと評価が欠かせません。私たちは、オーケストレーション・ハーネスの性能を測定するための厳格な社内手法を開発し、プロンプトの調整やルールの更新が品質の低下を招くことなく、データに裏付けられた確実な改善につながるようにしています。

皆様のコード分析パイプラインについても、進捗と有効性を測るために同様のベンチマークシステムを導入することをお勧めします。

ベンチマーク対象

公開されているコード脆弱性データセットは存在するものの、LLMを評価する上では学習データの汚染が大きな課題となります。最新のフロンティアモデルがすでにこれらの公開リポジトリを取り込んでいる可能性があり、その場合、モデルが脆弱性を真に推論しているのか、単に記憶した解答を思い出しているだけなのかを見分けることはほぼ不可能になります。

高い信頼性を持つ評価を確保するため、私たちは独自の合成コードベース群を開発しました。これらのカスタムベンチマークは、ソフトウェア領域、プログラミング言語、脆弱性の深度、そして従来型のモノリスから最新のマイクロサービスまでのアーキテクチャにわたっています。

重要な点として、私たちのセキュリティコンサルタントは、注入されたすべての脆弱性が実際に到達可能であり、動的に悪用できるものであることを手作業で検証しています。ハーネスとその基盤となるプロンプトを調整する際には、AIがこれらのベンチマークコードベースに過学習してしまうことを積極的に防ぐため、厳格なレビュープロセスを徹底しています。

ベンチマークの採点

私たちの採点プロセスは、AIによる評価と専門家によるヒューマン・イン・ザ・ループのレビューを組み合わせています。ハーネスがベンチマーク対象のディレクトリを分析すると、その出力は専用のGradingエージェントに渡されます。この採点エージェントは、パイプラインの検出結果を正解データセットと照合して評価しますが、その際、緩やかな意味的類似性ではなく、脆弱性の厳密な一致を要求します。

そこから、採点パイプラインはエッジケースに対応するために分岐します。

• 誤検知のトリアージ: ハーネスの検出結果のうち正解データにマッピングされないものは、それらが誤検知なのか正当な脆弱性なのかを最終的に分類する二次エージェントに回されます。

• 重複の解消: パイプラインが単一の正解データの問題に対して複数の検出結果を生成した場合、別のエージェントがそのクラスターを分析し、それらが重複しているかどうかを判定します。

最後に、人間の専門家が採点済みのデータを手作業でレビューし、AI審判の正確性を検証します。私たちはこの厳格なテストサイクルを、ハーネスの主要リリースのたびに複数のドメインとアーキテクチャにわたって実施し、LLM固有の非決定性を考慮して結果を平均化しています。

結論

ソフトウェア開発パイプラインの保護は、現代のエンタープライズ防御における決定的な課題として浮上しています。私たちの継続的な調査により、防御側が急速に高まる敵対的AIの能力への対応において、極めて大きな困難に直面していることが明らかになっています。

こうした新たな脅威に対抗するには、コードパイプラインの保護を最新の防御戦略の重要な構成要素とする必要があります。手作業によるソースコードレビューはAIのスピードに追いつくことができず、従来型のスキャンエンジンは、現代のソフトウェアに潜む幅広い脆弱性を一貫して見逃してしまいます。

しかし、私たちのハーネスの成功は、防御側が敵対的AIに対して優位を取り戻せることを証明しています。フロンティアモデルを専門家が定義したハーネスに組み込むことで、防御側はありふれた脆弱性の発見を自動化できるのです。

こうした標準的な検出結果への対応をAIに任せることで、ソースコードの可視性はスケーラブルな防御力へと転換され、私たちのコンサルタントをはじめとする防御担当者は複雑な欠陥への対応に完全に集中できるようになります。このハーネスの構築と改良のプロセスを通じて、AIは人間の専門知識を増幅させる実践的な手段として展開されたときに最も効果を発揮する、ということが証明されたと私たちは確信しています。

私たちのツールは特定時点でのアセスメントと、プロアクティブで綿密な脆弱性発見のために構築されたものですが、私たちの最近のブログ記事では、CodeMenderがソフトウェア開発と脆弱性管理に対して継続的なAI主導の監視を提供することで、これをどのように補完しているかを解説しています。こうした機能をすぐに導入したい組織向けには、Google AI Threat Defenseが常時稼働型のプラットフォームを提供しています。これにはCodeMenderによるコードスキャンと修復機能が含まれており、システムの分析、脅威の優先順位付け、脆弱性へのパッチ適用、そして新たな攻撃に対する継続的な監視を行います。的を絞った深い分析を行うAVDHと、CodeMenderによる継続的なスキャンを組み合わせることで、二層構造の防御戦略が構築されます。このアプローチにより、複雑なエクスプロイトチェーンに対しては特定時点での修復を活用しつつ、開発ライフサイクル全体にわたる継続的な可視性を維持することができます。

私たちが実環境でこのパイプラインをどのように構築・展開しているのか、その詳細に関心のある方は、2026年9月15日から16日にかけてワシントンD.C.で開催されるCyber Defense Summitにぜひご参加ください。私たちはそこで「How Mandiant Orchestrates Gemini to Find Zero-Days Before Adversaries.」と題したセッションを発表いたします。ライブデモを交えながら、エージェント型ワークフローの展開から得られた教訓を共有し、AI主導の攻撃・防御能力の今後について議論する予定です。サミットへの登録はこちらから。