AI支援による脆弱性管理のブループリント

執筆者: Jules Czarniak

はじめに

Mandiant M-Trends 2026レポートでも指摘されている通り、平均エクスプロイト到達時間(TTE)はマイナス7日にまで短縮されています。つまり、パッチが存在する前の時点で、脆弱性が悪用されるケースが多くなっているということです。

このスピードに対応するため、多くのセキュリティチームが、自動化された脆弱性の発見と修復を目的として、大規模言語モデル(LLM)エージェントを自社のコードベースや開発環境、継続的インテグレーション/継続的デリバリー(CI/CD)パイプラインに組み込む方法を模索しています。しかし、成熟した統合プロセスを伴わずに特権を持つ人工知能(AI)エージェントを導入すると、新たなアーキテクチャ上のリスクが生じます。

本ブログでは、AI機能をセキュアに脆弱性管理ワークフローへ組み込む方法についてのお客様からの問い合わせを受け、Mandiant Consultingが実践的なガイダンスを提供します。AI支援による脆弱性管理のための運用ガードレールを確立する方法について、具体的なシナリオを交えて解説します。これらの事例が示しているのは、セキュリティチームがAIを活用してワークフローを加速させながら、同時に環境の構造的な健全性を保つことができるという点です。AIの能力と決定論的な制御、そして人間の知見を戦略的に組み合わせることで、メリットを最大化しつつリスクを抑えられると考えます。

AIエージェントを安全に導入するための運用ガードレールの確立

デプロイパイプラインに予測不能な障害を持ち込むことなく高度なAI機能を安全に採用するには、確立された業界標準を拠り所とする姿勢が必要です。

NIST AIリスクマネジメントフレームワーク(RMF)やOWASP Top 10 for LLMsのようなガイドラインは、リスクを特定するための包括的なベースラインを提供してくれますが、こうした管理策を実運用に落とし込むには、構造的なブループリントが必要です。

GoogleのSecure AI Framework(SAIF)やGoogleのセキュアなエージェント運用のアプローチのようなフレームワークは、実践的な道筋を示してくれます。これらは、組織に対し、既存の決定論的な制御をAIの実行環境にまで直接拡張することを求めるものです。AIエージェントを導入する際、セキュリティチームは以下のような特有の運用・構造上のリスクに対応する必要があります。

• エージェント投入前のデータセキュリティと多層防御: エージェントが個人を特定できる情報(PII)や保護対象保健情報(PHI)、その他機微なデータにアクセスできないようにする必要があります。組織は、プロンプトがモデルに到達する前の段階でデータセキュリティを徹底すべきです。これには、テストに際して合成データを用いた非本番環境を厳格に使用することも含まれます。本番環境については、セキュリティチームはハイブリッド型の多層防御モデルを導入すべきです。これには、関門として機能する第1層の決定論的ポリシーエンジンに加え、機微なデータを除去し悪意あるプロンプトインジェクションがエージェント層に到達する前にブロックする、専用のガードモデル(Model Armorや同種のプロバイダー非依存型ガードレールなど)による第2層の推論ベース防御が含まれます。脆弱性発見において特に重要なのは、セキュリティチームがコードベース自体を信頼できない入力として扱うべきだという点です。脅威アクターは、ソースコードのコメントやサードパーティ製の依存関係の中に間接的なプロンプトインジェクションを埋め込むことができます(たとえば、脆弱性を無視するようエージェントに指示したり、環境変数を持ち出させたりする隠し命令など)。そのため、社内スキャンであっても入力のサニタイズは必須要件となります。

• クラウドプロバイダーの制限とゼロデータ保持(ZDR): 多くのクラウド・LLMプロバイダーは、悪用を防ぐため、デフォルトで自動化された攻撃的セキュリティ検査をブロックまたは制限しています。組織は、許容される利用ポリシーに則って動くために、明確な行動規範と正式なテスト許諾契約を整備しておくべきです。さらに、独自コードや発見した脆弱性が外部モデルの学習に決して使われないことを担保するため、LLMプロバイダーとの間で厳格なゼロデータ保持(ZDR)契約を結ぶ必要があります。

• ワークロードの分離: エージェントのワークロードは、動的に制限された権限を持つ、厳密に隔離された非特権コンテナ内で実行されるべきです。堅牢なサンドボックス化によって権限昇格を防ぐことで、万が一エージェントが破壊的なコマンドを幻覚(ハルシネーション)によって生成したり、プロンプトインジェクションによって乗っ取られたりした場合でも、被害範囲を限定できます。

• レッドチーム演習: サンドボックスを動的に立ち上げてコードを実行できる自律型の脆弱性スキャナーを導入する前に、組織は包括的な保証活動の一環として、AIエージェント自体を人間主導のレッドチーム演習にかけるべきです。これにより、ジェイルブレイクや再帰的なロジックループ、複雑なプロンプトインジェクションに対するエージェントの耐性を検証でき、セキュリティツール自体が攻撃ベクトルと化すことを防げます。

• 最小権限のマシンIDと人間による統制: ワークロードは分離されるべきですが、エージェントはプルリクエストの生成やコードのコミットのために本質的に権限を必要とします。セキュリティチームは、こうしたエージェントが、説明責任とユーザーの同意を担保するために人間の管理者に紐付いた、独立かつ厳密にスコープを絞ったマシンIDの下で動作するようにすべきです。組織は、対象のリポジトリとブランチに限定して発行される、短命かつジャストインタイム(JIT)のトークンを使用すべきです。これにより、エージェントの権限を制限するという原則が徹底され、たとえプロンプトインジェクションによってエージェントのコンテナが侵害されたとしても、脅威アクターが隣接する企業のコードベースを改ざんする方向へ横展開できないようにします。

• スキルに対するサプライチェーンの耐性: 開発者がサードパーティ製のスキルやModel Context Protocol(MCP)サーバーでAIを拡張する際、セキュリティチームはこうした統合を信頼できないサプライチェーン構成要素として扱うべきです。MCPプラグインは、これまで無害だった統合が密かに悪意ある依存関係へと更新されてしまう、サプライチェーン汚染のリスクをもたらします。加えて、セキュリティチームは、セッションメモリの汚染や再帰ループの乗っ取りといった、エージェントオーケストレーションフレームワーク自体(LangChainやAutoGenなど)に内在する脆弱性についても評価すべきです。

• 有害フロー分析(TFA)と可観測な挙動: TFAの目的は、実行時のデータ経路を監視し、エージェントが検証されていない外部のエンドポイントへ機微な内部コンテキストを持ち出さないようにすることです。エージェントの動作・入力・推論・出力は、完全に可観測かつ透明にログ記録されなければなりません。LLMに対する動的なテイント追跡の実装は依然として複雑なアーキテクチャ上の課題ですが、組織はこうした実行時の可観測性と静的なサプライチェーン管理とを明確に切り分けて考える必要があります。脅威インテリジェンスを組み込み、入力されるエージェントツールをハッシュ化して検証することは、導入前に整合性を確認するための必須のベースラインとなります。しかし、静的な管理策だけではデプロイ後の挙動には対処できないため、データ持ち出しの緩和には、最終的には能動的な実行時監視と、実際のデータフローを追跡・制限するための安全な一元的ログ記録が欠かせません。

検証可能な整合性と構造的な耐性を求めるフレームワークの中でこれらのツールを実運用に組み込むことで、組織はAIのスピードとエンタープライズ防御との間のギャップを安全に埋めることができます。

人間主導の脅威モデリングが必要な理由

LLMは構文パターンの識別を得意としますが、ソースコード自体が、文書化されていないビジネス上の意図まで完全に映し出していることは滅多にありません。一部の組織は、Retrieval-Augmented Generation(RAG)を用いてLLMエージェントを社内Wikiや設計ドキュメント、課題管理システムに接続することで、この問題を解決しようとしています。

RAGはモデルに外部のビジネスコンテキストへのアクセスを与えますが、完璧な解決策とは言えません。企業のドキュメントは、しばしば古く、矛盾していたり、不完全だったりします。AIエージェントが古いアーキテクチャ図を参照してしまい、本番環境ではすでに存在しない安全な経路を自信満々に幻覚として生成してしまう可能性もあります。LLMエージェントは、矛盾する、文書化されていない人間の前提を解決することが苦手なため、レガシーアプリケーションと最新のエージェントワークフローの両方において、人間主導の脅威モデリングは依然として重要なセキュリティ管理策であり続けます。

セキュリティチームは、安全な基盤を確立するための構築前のシステム設計段階と、構築後のアーキテクチャレビューの両方で脅威モデリングを適用すべきです。AIエージェントは設定不備のある内部エンドポイントをローカルで首尾よく特定できるかもしれませんが、人間の脅威モデラーは、構造的な問いを投げかけます。「そもそも、なぜそのマイクロサービスが広範なデータベース読み取り権限を持っているのか」という問いです。

アーキテクチャ上の脆弱性を特定するには、ビジネスリスクやデータの機微性、運用上の制約について推論する必要があります。このプロセスを体系化するため、組織はPASTA(Process for Attack Simulation and Threat Analysis)のような業界フレームワークや、Mandiant脅威モデリングセキュリティサービスのようなサービスを活用し、信頼境界をマッピングして構造的な設計上の欠陥を洗い出し、代替の管理策に優先順位を付けることができます。設計が不十分なシステムのバグ発見を自動化エージェントに頼る場合、人間の監督を通じて基盤となるアーキテクチャを固めておくことが不可欠な要素となります。

SAIFの指針に沿ってこうしたAIエージェントが安全にサンドボックス化され、脅威モデリングによってアーキテクチャが検証された後、組織は通常これらを2つの異なる問題領域に適用できます。1つは、市販の既製ソフトウェア(COTS)やインフラにおける既知のCVEの量を管理するのを支援するエンタープライズ脆弱性管理、もう1つは自社製(1P)コードの脆弱性を特定するプロダクトセキュリティです。

トラック1: エンタープライズ脆弱性管理

基盤的なセキュリティと発見

本稿の第2のトラックでは、AIエージェントが独自コード内の複雑なゼロデイをどのように発見できるかを取り上げますが、組織はこうしたAI導入と並行して、エンタープライズインフラの規模の問題にも対処する必要があります。新しいAI機能が話題を独占する中にあっても、組織は、シークレットの氾濫や管理されていないサービスアカウント、FIDO2 MFAの未導入、レガシーなVPN集約装置といった基盤的なセキュリティ課題への対応を怠るべきではありません。昨年Mandiantが調査した侵入事案では脆弱性の悪用が最も多い初期感染経路でしたが、脅威アクターは脆弱性を突いた後の足場を確保・拡大する際、依然として基盤的な管理策の欠如や未パッチのエッジデバイスに一貫して頼っています。

さらに、AIは基盤的な可視性の代わりにはなりません。セキュリティチームはAIエージェントを導入すると同時に、External Attack Surface Management(EASM)やCloud Security Posture Management(CSPM)、Continuous Threat Exposure Management(CTEM)といった動的な発見能力を最大限に活用し、こうした戦術的な侵入口を塞ぐべきです。ハイブリッド環境やクラウド環境では、Wizのようなツールを使ってこの初期のフットプリントをマッピングできます。

リスクベースの脆弱性管理

脆弱性管理チームは、従来型のスキャナーが生成する現在の検出量にすでに圧倒されています。組織がEASMやCSPM、CTEMといった動的な発見ツールを自動化AIエージェントと併せて拡大していくにつれ、この検出結果の増加は問題をさらに悪化させることになります。この流入に対処するには、こうした多様な発見手法から得られるテレメトリを、まず正規化し重複排除する必要があります。この正規化されたデータは2つの目的を果たします。1つはリスクエンジンへ直接投入されること、もう1つは構成管理データベース(CMDB)内の古くなったレコードを修正するライブオーバーレイとして機能することです。重複排除された脆弱性を、この新たに更新された資産コンテキストや最前線の脅威インテリジェンスと併せて評価することで、RBVMエンジンは独自のリスクスコアを算出し、セキュリティチームが動的に修復の優先順位を付けられるようにします。

成熟したRBVMの手法では、加重平均を用いて0から100のスケールで独自のリスクスコアを算出します。このリスクベースのスコアを算出するためのサンプル計算式は以下の通りです。

最終スコア = (W_1 * S_vuln) + (W_2 * S_asset) + (W_3 * S_threat)

変数と重み(W)は組織のリスク許容度に応じてカスタマイズされます(たとえば脆弱性0.20、資産0.40、脅威0.40で合計1.0など)。一方、基礎となる各変数(S)は0から100のスケールでスコア化され、以下のように定義されます。

• 脆弱性の深刻度(S_vuln): その欠陥固有の技術的な深刻度です。これは、CVSSベーススコア(機密性・完全性・可用性への影響を本来的に反映している)を10倍することで算出されます。

• 資産コンテキスト(S_asset): 露出度とデータの機微性を組み合わせた指標です。スコアは、顧客データを保有するインターネット公開資産の100から、機微なデータを持たない社内限定資産の25まで幅があります。この影響を非技術系のステークホルダー向けに金銭的な用語へ変換するため、組織はFactor Analysis of Information Risk(FAIR)の原則をこの指標に組み込むことができます。ただし、このアプローチには、極めて正確で継続的に更新される財務データが必要となり、多くの企業が規模を保って維持するのに苦労しています。

• 脅威コンテキスト(S_threat): その脆弱性が持つ現実世界での緊急性です。スコアは、組織のプロファイルに関連する脅威アクターによって実際に悪用されている場合の100から、概念実証(PoC)が存在するか自律型AIエージェントによって容易に悪用され得る脆弱性クラスである場合の75、悪用が理論上のもので極めて複雑である場合の25まで幅があります。組織はまた、Exploit Prediction Scoring System(EPSS)の確率(パーセンテージ)をこの変数へ直接反映させるべきです。これにより、実際の悪用状況を示すテレメトリの変化に応じて脅威スコアが自動的に上下し、静的な脆弱性データを実際の脅威インテリジェンスと整合させることができます。

資産の独自リスクスコアは、CISAの拘束力のある運用指令(BOD)など、外部のコンプライアンス主導の要請が社内の優先順位付けを上書きしない限り、社内の修復サービスレベル合意(SLA)に直接反映されるべきです。リスク主導かつ脅威インテリジェンス主導の脆弱性優先順位付け手法は、組織が最も重大なセキュリティ脆弱性の管理・緩和にリソースを優先的に振り向ける助けとなります。この領域は、LLMが脆弱性管理プロセスを支援できる部分でもあり、特にチームが非構造化の脅威インテリジェンスを統合し、関連するリスクコンテキストをより効率的に浮き彫りにする作業を後押しできます。パッチ適用に厳格なSLOを課し、パッチ適用の例外にはリスク受容の正式な文書化を求めることで、脅威アクターに悪用され得る脆弱性の数を減らし、組織全体で未解決のリスクの可視性を高めることができます。さらに、組織はRBVMのデータを、セキュリティオーケストレーション・自動化・対応(SOAR)プラットフォームに直接統合し、アラートの自動エンリッチメントに活用すべきです。

封じ込めと可観測性

最新のアーキテクチャのブループリントは、脆弱性が必ず悪用されるという前提の下、攻撃対象領域の縮小を優先事項とする必要があります。従来型の境界防御から脱却し、組織はゼロトラストの原則に沿って、あらゆる資産・ワークロード・IDの周囲にセキュリティ境界を確立すべきです。

この方向性を実現する要素の1つが、強固な認証原則の実装です。組織は、継続的かつコンテキストを踏まえた認証・認可を徹底することで、暗黙の信頼を排除すべきです。Identity-Aware Proxy(IAP)などのZero Trust Network Access(ZTNA)ソリューションを活用することで、重要な管理インターフェース(SSHやRDPなど)や内部システムをインターネットへの直接的な露出から遮蔽し、検証済みのIDと準拠デバイスのみにアクセスを許可できます。

一般公開されているアプリケーションやAPIについては、攻撃対象領域の縮小には、ロードバランサーやAPIゲートウェイの段階でレイヤー7の検査を導入することが含まれます。この強化層により、厳格なスキーマ検証が行われ、不正な形式の受信トラフィックや潜在的なエクスプロイトが内部のアプリケーションロジックに触れる前に、それらを検知・無害化します。

ソフトウェアサプライチェーンの保護も、最新のブループリントにおいて同様に不可欠であり、組織は依存関係のトラックとビルドのトラックの両方において、Supply-chain Levels for Software Artifacts(SLSA)のようなフレームワークに沿うべきです。セキュリティポリシーでは、サードパーティ製の依存関係が、Google Assured Open Source Software(OSS)や同等のソリューションといった自動キュレーションサービスを備えた一元的なアーティファクトリポジトリを経由するよう義務付け、信頼できないコードが開発ライフサイクルに入り込まないようにすべきです。さらに、CI/CDランナー用の一時的なコンピューティングインフラを介して分離性・一時性・再現性の要件を実装することで、より高度なSLSAビルドレベル(SLSAレベル3など)へと成熟させていくことは、環境が短命かつ自動的に入れ替わるようにすることで、攻撃者による永続化の可能性を減らします。

こうしたビルド前の管理策を補完するため、すべての本番ワークロードにわたって実行時の可観測性を確立すべきです。これには、インフラレベルの挙動と、本番環境で実際に稼働している具体的な実行時ライブラリの両方を監視する必要があり、これによって静的なソフトウェア部品表(SBOM)だけでは把握しきれない、真に悪用可能なリスクを浮き彫りにできます。ワークロードの監視と並行して、組織はワークロードIDフェデレーションを実装することで、認証方法自体も強固にすべきです。静的な認証情報を廃止し、代わりに強固な暗号学的ID検証に裏付けられた短命なトークンを使用することで、組織は認証情報窃取や不正な横展開のリスクを低減できます。

内部環境においては、フラットなネットワークをきめ細かなセキュリティゾーンへと分解するために、マイクロセグメンテーションを徹底すべきです。Secure Access Service Edge(SASE)アーキテクチャを介してアプリケーショントラフィックをルーティングすることで、ネットワークルーティングを堅牢なID管理と直接統合し、認証されていないユーザーからは内部サービスが完全に見えないようにし、脅威を最初の侵入地点に封じ込めることができます。

最後に、ゼロトラストの枠組みの中での自動化された封じ込めとインシデント対応は、決定論的で監査可能なツールに依拠する必要があります。エンドポイント検知・対応(EDR)プラットフォームやSOARのプレイブックは、ハードコードされた実行ロジックを通じて信頼性の高い封じ込め作業を処理すべきです。AIツールはトリアージやポリシー提案を加速させる一方で、実際の実行能力は、アーキテクチャ全体の予測可能性を維持するため、明確に定義され事前にテストされたワークフローに限定しておく必要があります。

トラック2: プロダクトセキュリティと開発(自社製コード)

決定論的ツールと確率論的ツール

LLMエージェントを脆弱性管理およびセキュリティワークフローに組み込むには、決定論的ツールと確率論的ツールの違いを理解しておく必要があります。従来のSASTやDASTツールは、構造的なコード解析や明確な実行時観測を通じて脆弱性を評価するため、固定された手法を用います。一方でLLMは、決定論的な実行経路を追跡するのではなく、トークンを同時に処理して統計的・意味的な関係性を算出することで、ソースコードを評価します。

Chain of Thought(CoT)プロンプティングのような手法により、モデルは複雑なコード経路を中間的な推論ステップへと分解することでこのギャップを埋められますが、このプロセスは依然としてアーキテクチャ上の制約に縛られています。モデルがリポジトリ全体を取り込めるほど大きなコンテキストウィンドウを持っていたとしても、長い入力にわたってアテンションの劣化が生じることがあり、プロンプト内に介在する検証やサニタイズのロジックを正しく重み付けできないことがよくあります。たとえば、10行目で変数がテイント(汚染)され、500行目でサニタイズされている場合、アテンションの劣化によってモデルがそのサニタイズロジックを見失う可能性があります。さらに、企業のコードベースをコンテキスト制限内に収めるためにチャンク分割が必要な場合、その結果生じる断片化によって、モデルがエンドツーエンドのデータフローを見失う可能性もあります。

その結果、確率論的エンジンは、ハードコードされた認証情報や古い依存関係といった、局所的で静的な異常の発見には効果を発揮しますが、断片化されたチャンクや広範なコンテキストウィンドウにまたがる複雑な脆弱性については、しばしば誤った判断を下します。注目すべき例外は、こうした確率論的モデルが決定論的なフィードバックループと組み合わされる場合です。たとえば、C++のメモリ破壊を解析する際、LLMにテストハーネスを与えて反復的にコードを実行させ、クラッシュを確実に証明させることができます。こうした動的検証の応用については後段で詳述しますが、標準的なエンタープライズコードベース全体にわたる静的解析における根本的な制約は変わりません。すなわち、モデルは分散したロジックを一貫して評価することを苦手としているのです。

二値判定オラクルとアーキテクチャ判定オラクル

多くのセキュリティプログラムは、エージェントが自律的にテスト環境を立ち上げ、ツールを使ってペイロードを実行し、自らの発見を検証するワークフローへと移行しつつあります。これは有望なアプローチですが、どこで最も効果を発揮するのかを理解しておくことが重要です。

エージェントのワークフローは、二値判定かつ観測可能なオラクルを持つバグクラスに対して優れた性能を発揮します。つまり、システムが「クラッシュするかしないか」という客観的なフィードバックループを提供してくれるケースです。たとえば、モデルがC++カーネル内のメモリ破壊を探している場合、エクスプロイトの成功は疑いようがありません。ペイロードが実行され、その結果としてクラッシュが起これば、それが脆弱性の存在を確実に証明することになります。これが、Webブラウザやオペレーティングシステムといったメモリ安全でないターゲットにおいて、業界全体でAIによる脆弱性発見が急増している理由でもあります。

しかし、エンタープライズソフトウェアの大半は、検証にアーキテクチャ判定オラクルを必要とする脆弱性で占められています。認可バイパスや複雑なビジネスロジックの欠陥、間接的なサーバーサイドリクエストフォージェリといった脆弱性には、ビジネスコンテキストやサービス間の信頼境界についての理解が必要です。エージェントのペイロードが明確な結果を生み出せない場合、その脆弱性が幻覚によるものなのか、単にペイロードの構築を誤っただけなのかを、エージェントは確実に区別できません。エージェントの不正な形式のペイロードが、無関係なバックグラウンドプロセスをクラッシュさせてしまい、モデルが成功したと幻覚を起こして誤った確認結果を報告してしまうことすらあり得ます。複雑なエンタープライズアーキテクチャには、確率論的エンジンが本質的に知り得ない、文書化されていないビジネス上の意図が含まれているのです。

的を絞った導入と人的リソースへの影響

脆弱性発見にLLMを採用する組織は、大きな人員配置上の課題に直面します。LLMは、人間のエンジニアがトリアージできる速度をはるかに上回るペースで発見結果を生成できるからです。LLMが生成するすべてのアラートを手作業でレビューしなければならないとすれば、セキュリティチームはたちまち燃え尽きたり、アラート疲れに陥ったりすることになります。

利用可能なすべてのコードベースに無差別にエージェントを投入し、検証されていない出力の氾濫を招くリスクを冒すのではなく、セキュリティチームには選択的な導入戦略が必要です。成熟したプログラムでは、基本的な衛生管理と決定論的なルール適用のためにSASTとDASTを維持しつつ、明確な二値判定オラクルを持つ影響度の高いコンポーネントに対してのみ、集中的なエージェント監査を確保しておくべきです。

組織は、この技術の強みが全体的なリスクプロファイルと合致するシステムに、エージェント監査の優先順位を置くことができます。

• メモリ安全でないコードベース: C、C++、Assemblyといったメモリ安全でない言語で書かれたレガシーコンポーネントや高性能コンポーネントは、LLM監査の有力な候補です。これらの言語は、バッファオーバーフローやuse-after-freeといったメモリ破壊系の欠陥の影響を受けやすい傾向があります。こうした脆弱性はセグメンテーション違反のような明確な失敗状態を引き起こすため、エージェントがメモリサニタイザーでコードをコンパイルしPoC入力を作成できる自動化されたサンドボックスとの相性が良好です。このアプローチは、Python C拡張やJava Native Interface(JNI)のように、安全な言語が安全でない内部ライブラリを呼び出すネイティブ拡張の監査にも有効です。

• 外部コンテンツへの露出度が高いシステム: 自社製のデータ取り込みパイプラインやカスタムAPIゲートウェイ、独自のエッジプロキシなどです。ここでの前提条件はソースコードへの直接アクセスであり、この戦略は組織がロジックを検査できる、内製あるいは完全にオープンソースのコードベースにのみ厳格に適用されます。こうしたシステムは信頼できないインターネットトラフィックを直接パースするため、そのソースコードをLLM主導の監査対象とすることで、リスク低減の投資対効果を最大化できます。

• 社内で共有されているライブラリとユーティリティ: コアとなるシリアライズ/デシリアライズ用パッケージや共通ユーティリティ関数、社内メッセージキューパーサーのような自社開発のカスタムミドルウェアラッパーなどです。企業はこうした共有の構成要素のソースコードを自ら所有しているため、エージェントツールを自動化テストハーネス内に容易に組み込み、入力をファジングして低レベルのロジックやパース処理のバグを高い精度で捕捉できます。

• 基盤的なセキュリティ境界: 社内開発された一元的な認証サービス、独自のOAuthプロバイダー、社内の認証情報ブローカーなどです。複雑なID境界のテストはロジックベースのノイズを増やしがちですが、ソースコードに完全にアクセスできることで、チームはエージェントを決定論的なチェックと組み合わせ、発見結果を安全にトリアージできます。認証障害の被害範囲の大きさを考えれば、こうした人的労力を投じる価値は十分にあります。

LLMが生成するノイズを絞り込むため、組織はルーティングルールを整備すべきです。エージェントには、エクスプロイトの証明を試みる、完全に再現可能で決定論的なテストハーネス(コンパイル済みバイナリやPythonのテストスクリプトなど)の生成を義務付けます。このハーネスは、隔離・監視されたサンドボックス内で自動的に実行されなければなりません。サンドボックスでの実行が(構文エラーやエクスプロイトの失敗により)失敗した場合、そのチケットは破棄され、人的リソースを消耗せずに済みます。ただし、組織はこうしたテストハーネスに対して実行タイムアウトと反復回数の上限を設けるべきです。厳格な上限がなければ、脆弱性の証明を試みる自律型エージェントが無限ループに陥りかねません。スクリプトを書いては失敗し、書き直してはまた失敗するというサイクルを繰り返し、行き詰まった単一の脆弱性に対してAPIトークンの予算と計算リソースを浪費し、セキュリティレビューを前進させることなく大幅なコスト超過を招く恐れがあります。こうしたコストを管理するため、組織はFinOpsの原則を取り入れ、LLM監査にかかる計算・API費用と、従来型の手作業によるトリアージ費用とを比較検討すべきです。

とはいえ、サンドボックス内での実行成功が、対応すべき優先度の高いリスクであることを保証するわけではありません。実際には、自律型エージェントが本物の技術的欠陥に対して動作するPoCを生成しても、それが最終的には無関係であったり、システムの脅威モデルの文脈の中では修復の優先度が低いと判断されたりするケースが頻繁にあります。たとえば、エージェントが到達不能なデッドコードの経路をうまく突いてしまったり、実行に管理者権限を要し、それ以上の権限昇格につながらないバグを引き当ててしまったりする可能性があります。したがって、人間のエンジニアは、サンドボックスが実行成功を記録した場合に限ってチケットのレビューと優先順位付けを担当し、レビューの一環として環境コンテキストや到達可能性、真のビジネスへの影響を検証すべきです。

このワークフローによってアラートの量は減りますが、セキュリティチームの作業負荷そのものがなくなるわけではないという点を理解しておくことが重要です。エンジニアの主な役割は、初期の脆弱性を手作業で探すことから、LLMが生成した証明をレビューし、それが悪用不可能あるいは文脈上無関係な発見結果ではなく、有意なリスクを表しているかを確認することへとシフトします。経営層は、この新しい現実に合わせてチームの人員配置と教育を適切に行うべきです。LLMエージェントの導入によって熟練した実務者の必要性がなくなるわけではなく、彼らの作業負荷が複雑な検証作業へと振り向けられるだけです。同様に重要なのが、偽陰性のリスクをチームに認識させる教育です。AIが生成したノイズの除去に過度に集中すると、誤った安心感を生み出しかねません。エクスプロイトが、モデルの学習データにおいて十分な重み付けがなされていなかった新規の手法やゼロデイ脆弱性に依拠している場合、エージェントはそれを見過ごしたまま静かに素通りしてしまう可能性が高くなります。LLMは発見作業を強化してくれますが、網羅的なカバレッジを保証するものではありません。

LLMをSASTのトリアージパイプラインに組み込む際には、人間のエンジニアが、より広範なアーキテクチャの健全性についても検証すべきです。特定のSAST警告をLLMに提示すると、コンテキストの狭窄化を引き起こすことがあります。これは、エージェントが局所的な構文エラーの解消に過度に集中してしまい、同じファイル内に存在するより広範なアーキテクチャ上の欠陥を見逃してしまう現象です。さらに、エージェントの任務が発見にとどまらず自動修復(コード修正の記述と提案など)にまで及ぶ場合、LLMが意図せず新たな回帰(リグレッション)を持ち込んだり、想定されていたビジネスロジックを回避してしまったりしないよう、人間を介在させた検証が極めて重要になります。

修復と強化

LLM支援によるコード修復

大規模言語モデル(LLM)をソフトウェア開発ライフサイクルに組み込む主な目的の1つが、修復作業の自動化です。これを実現するため、組織は主に2つの実行方式を通じてこの機能を展開しています。統合開発環境(IDE)内で直接動作させる方式と、一元的なパイプラインランナーとして動作させる方式です。その例としてCodeMenderが挙げられますが、本稿執筆時点では一般公開されていません。

IDE統合方式

この方式は、能動的なペアプログラマーとして機能することで、修復作業をできる限り上流(左側)へとシフトさせます。IDEのバックグラウンドで継続的な静的解析を実行するツールが、インラインの表示やホバー時のツールチップといったエディタ上の診断情報を通じて、脆弱性を開発者へ直接提示します。

• 局所的なスコープ: 開発者は、局所的なデータフローを解析させ、狙いを定めたパッチ(パラメータ化されたSQLクエリの実装など)を生成させるようLLMエージェントをトリガーできます。LLMを局所的で構文レベルの修正に限定することで、変更のスコープが限定的な範囲に留められます。これにより、複雑なアーキテクチャロジックを頻繁に壊してしまうような、広範囲にわたる複数ファイルのリファクタリングをエージェントが試みることを防げます。

• 人間の介在: 開発者は、コードがコミットされる前にAIが生成したパッチをレビューします。

• 誤検知の管理: ローカルのIDEエージェントを使うことで、開発者は誤検知を動的に管理できます。特定の行のテキストに紐付けてアラートを抑制することで、アラート疲れを軽減し、開発者の信頼を維持できます。

CI/CDランナー方式

ランナー方式は、CI/CDパイプライン内で非同期に実行され、LLMを用いてコミットされたコードをレビューし、修復案を自動的に提案します。

• 実行の制限と決定論的な検証: 複雑な複数ファイルにまたがる認可の欠陥を、メインブランチ上で直接自動的に書き換えるよう一元的なランナーに指示すると、ロジックエラーを引き起こしてしまう高いリスクが生じます。これを緩和するため、エージェントはプルリクエスト(PR)の生成に限定されるべきです。PRが生成されたら、決定論的なテストハーネスと合わせて、標準的な回帰テストスイートを自動的に実行しなければなりません。修正済みのコードに対して当初のPoCを再実行することで、このワークフローはそのエクスプロイトスクリプトを検証用オラクルとして再利用し、脆弱性が修復されたことを証明します。その後、人間のエンジニアがマージ前にアーキテクチャ上のロジックを検証するため、そのPRをレビューします。

いずれの場合も、セキュリティチームは単一のアプローチに頼るのではなく、この2つの方式の間に明確な境界線を定めるべきです。IDEエージェントは、即時的で構文レベルの支援を提供し、開発者がコードをコミットする前にローカルで低複雑度のエラーを捕捉・解消します。一元的なCI/CDランナーは、より広範な組織全体のベースラインを扱い、ローカル環境をすり抜けてしまう脆弱性に対して、リポジトリ全体にわたる複雑な修正案を提示します。

デプロイ後の管理策

人間によるレビューや決定論的なテストハーネスがあってもなお、AIが生成したパッチは本番環境にロジックの回帰を持ち込んでしまう可能性があります。組織は、以下のような厳格なデプロイ後の管理策を実装すべきです。

• 自動ロールバック: LLMが生成したコードを、他の主要なアーキテクチャ変更と同様のデプロイ後の精査対象として扱うことで、予期せぬ回帰がCI/CDパイプラインをすり抜けてしまった場合でも、環境を既知の健全な状態へ戻せるようにします。

• モデルドリフトの緩和: マネージド型のAIサービスに依拠することは、モデルドリフトという継続的なリスクをもたらします。目に見えない重みの更新によってテストハーネスが壊れてしまうのを防ぐため、組織は特定のモデルAPIバージョンを固定リリースに固定しておく必要があります。固定したバージョンがサポート終了(EOL)を迎えると、組織は強制的な移行に直面することになります。このパイプラインの脆さを緩和するには、モデルの固定と決定論的な回帰テストスイートの組み合わせが必要です。

• コンプライアンスと監査可能性: AIエージェントがセキュリティチケットを自動的にクローズしたり、CI/CDパイプライン内でパッチを生成したりする場合、組織はSOC 2、PCI-DSS、FedRAMP、CMMCといったフレームワークを満たすため、改ざん不能な監査ログを維持すべきです。国家安全保障に関わる導入では、データ主権要件についても考慮する必要があります。このログには、修正案を提示した特定のモデルバージョン、その修正を検証した決定論的なテスト結果、そしてマージを承認した人間のエンジニアを記録すべきです。さらに、EU AI Actのような新興の法規制が高リスクの用途における人間の監督を重視していることを踏まえ、セキュリティチームは自律的な修復ワークフローがこうした進化するグローバルな規制基準とどう整合するかを慎重に評価すべきです。

結論

脆弱性管理におけるLLMの活用は、多層的なソリューションです。これを組み込むには、レイヤーごとにワークフローを切り分ける必要があります。エンタープライズインフラのレベルでは、検出結果の量や構成のドリフトを処理するために、リスクベース脆弱性管理(RBVM)とエクスポージャー管理が不可欠です。プロダクト・コードセキュリティのレベルでは、独自コードやオープンソース、サードパーティ製コードを監査するため、LLMを活用した脆弱性評価と修復が、SASTやDASTといった基盤的な決定論的管理策と並行して機能する必要があります。

LLMは技術的負債の管理や脆弱性発見の加速に役立ちますが、セキュア・バイ・デザインの原則に取って代わるものではありません。LLMエージェントが、他の主要な攻撃経路とともに、メモリ安全でないコードベースにおける局所的なメモリ破壊の特定と悪用において、卓越した能力を発揮しつつあるという事実は、警鐘として受け止めるべきです。

ソフトウェアのメモリ安全性に関するNSAのガイダンスに沿った長期戦略として、組織は新規の社内開発において、メモリセーフな言語を段階的に導入していく必要があります。LLMは、コード移行に必要な手作業を減らすことで、この領域で実現可能な範囲を広げ始めています。既存のCやC++のコードベースをRustへ変換する作業は、これまで必要となるエンジニアリング工数の多さから現実的ではありませんでした。完全に自動化された変換がそのまま使える解決策というわけではありませんが、LLMを使ってエンジニアの変換作業の大部分を支援することで、こうした長期的な移行を運用上実現可能なものにできます。社内での取り組みにとどまらず、組織は調達要件を活用して、ベンダーがメモリ安全でない言語への依存を減らし、時間をかけて安全な設定をデフォルトとするよう促すべきです。AIのスピードとエンタープライズ防御との間のギャップを埋めるということは、現在の未処理案件を管理するための自動化パイプラインを構築すると同時に、脆弱性や設定不備の種類そのものを設計段階で排除するシステムを構築していくことを意味します。

謝辞

本分析は、Google Threat Intelligence Group(GTIG)およびその他のより広範なGoogleチームの協力なしには実現しませんでした。