ソースコードから攻撃経路を描く「ThreatForest」——6つのAIエージェントが変える脅威モデリング｜2026年8月16日版
2026年8月16日時点で注目したいのは、AWSの研究者らが公開したオープンソースの脅威モデリングシステム「ThreatForest」です。
ThreatForestは、ソースコードを読み、攻撃者が目的を達成するまでの経路を攻撃ツリーとして整理します。重要なのは、単一のLLMに分析を丸投げせず、役割を分けたAIエージェントと決定論的な検証処理を組み合わせていることです。
- ソースコードからシステム構成と脅威候補を抽出
- 攻撃経路をツリー形式で可視化
- MITRE ATT&CKやCAPECなどの分類体系に対応付け
- 対策案を生成し、人間が3段階で確認
開発者にとっては、設計時に作った脅威モデルが実装変更で古くなる問題を減らせる可能性があります。ただし、生成結果はそのまま監査結果になるものではありません。
ThreatForestは何を自動化するのか
脅威モデリングでは、守る対象や入口を洗い出し、「どの条件が重なると攻撃が成立するか」を整理します。クラウドネイティブなシステムでは、サービス、API、認証設定、権限、外部依存関係が増え、手作業だけで追い続けることが難しくなります。
ThreatForestの論文によると、このシステムはソースコードリポジトリを入力として、次の処理を段階的に進めます。
- リポジトリを解析する
- アプリケーションの文脈を補う
- 脅威候補を生成する
- 脅威ごとに攻撃ツリーを並列作成する
- 攻撃手順をTTPへ対応付け、緩和策を作る
- 人が確認できるレポートにまとめる
攻撃ツリーは、攻撃者の最終目標を根に置き、そこへ到達するための条件や手順を枝として表すものです。単に「認証に注意」「権限を見直す」と列挙するのではなく、どの弱点が、どの順番で悪用され得るかを追える点に意味があります。
6つの役割が単一LLMの弱点を補う
ThreatForestの中核は、分析作業を複数の専門エージェントへ分ける構成です。AWSのプロジェクトページでは、スキャナー、脅威識別、攻撃ツリー生成、TTPマッピング、対策助言などの役割が順番に動き、脅威ごとの処理は並列化されると説明されています。
コードを読む役割と脅威を考える役割を分離
最初の役割は、リポジトリから構成要素や依存関係を拾います。その情報を受け取った別の役割が脅威を考えるため、「コードの把握」と「攻撃シナリオの推論」が一つの長い応答に混ざりません。
この分離は実務上重要です。入力が大きいシステムでは、単一のプロンプトにコード、設計、脅威分類、対策生成を詰め込むほど、根拠の追跡が難しくなるからです。
攻撃経路ごとに並列処理
候補となる脅威が複数見つかると、攻撃ツリーの構築や対策案の作成を脅威ごとに進めます。これにより、認証回避、権限昇格、情報流出といった異なるシナリオを、それぞれ独立した経路として確認できます。
共通語彙へ変換する
生成した攻撃手順は、MITRE ATT&CK、CAPEC、クラウド向け脅威マトリクスなどへ対応付けられます。
これはラベルを付けるだけの処理ではありません。開発チームが見つけた問題を、セキュリティ担当者が使う分類、検知ルール、対策管理へ接続しやすくします。独自表現のレポートで終わらず、既存のセキュリティ運用へ渡せることが利点です。
ここがポイント: ThreatForestの新しさは、AIに脅威を自由回答させることではありません。専門エージェント、検証ゲート、再試行回数の制限、人間の承認点を一つの処理フローに組み込んだ点にあります。
検証ゲートと人間の確認を残した理由
LLMは、もっともらしいもののコード上の根拠がない攻撃経路を生成することがあります。ThreatForestは、この問題をモデルの性能だけで解決しようとしていません。
論文では、ワークフローを有向グラフとして制御し、次の仕組みを組み込んだとしています。
- 条件を機械的に確認する決定論的な検証ゲート
- 処理が循環し続けないための再試行回数制限
- 途中結果を人が確認する3つの検証ポイント
この設計から分かるのは、セキュリティ分野のAIエージェントでは「自律性をどこまで高めるか」だけでなく、どこで止め、何を人が承認するかが製品品質を左右するということです。
生成された攻撃ツリーにコード上の裏付けがあるか、対象システムの前提が正しいか、提案された対策で別の機能が壊れないか。これらは依然として、開発者やセキュリティ担当者が判断する必要があります。
開発現場ではどう使えるか
ThreatForestは、完成したシステムを一度だけ診断する用途より、開発工程へ継続的に組み込む使い方が重要になります。
設計レビューのたたき台にする
新しいAPIや認証フローを追加した際、変更後のリポジトリから攻撃経路を再生成すれば、レビュー時に確認すべき論点を早くそろえられます。
ただし、出力された脅威の件数を安全性の点数として扱うべきではありません。重要なのは、実装に対応する経路と根拠を人が確認できることです。
CI/CDで差分を確認する
将来的には、プルリクエストやリリース単位で脅威モデルの差分を見る運用が考えられます。たとえば次の変化を検出できれば、レビュー対象を絞りやすくなります。
- 新しい外部公開エンドポイントが追加された
- サービスアカウントの権限が広がった
- 認証方式やデータフローが変わった
- 新しい依存サービスが攻撃経路に加わった
一方、毎回LLMを動かすコスト、機密コードの取り扱い、モデルやプロンプトの更新による出力差は、運用前に決める必要があります。
セキュリティ担当者との共通資料にする
MITRE ATT&CKなどへ対応付けた攻撃ツリーは、開発者とセキュリティ担当者の会話を具体化します。「危険そう」という指摘ではなく、攻撃の前提、経路、影響、対策を一つずつ検討できるからです。
導入前に確認すべき限界
ThreatForestはAWS Samplesとして公開されたサンプルです。AWS Samplesは一般に、実装例として提供されるものであり、そのまま本番環境へ投入する前に、利用者側でテスト、安全性確認、最適化を行う必要があります。
特に確認したいのは次の点です。
- 解析範囲：実行時設定、クラウド側の権限、外部SaaSなど、リポジトリ外の情報をどこまで補えるか
- 根拠追跡：各攻撃ステップを具体的なファイルや設定へ結び付けられるか
- 誤検知と見逃し：生成結果を誰が、どの基準で採否判断するか
- 機密管理：コードや設計情報をモデルへ送る際の保存先、ログ、アクセス権
- 再現性：同じコードを解析した際に、比較可能な結果を維持できるか
また、ThreatForestが作るのは脅威モデルであり、侵入テストやコード監査そのものではありません。実際に脆弱性が存在するかを確定するには、静的解析、動的テスト、設定監査など別の検証が必要です。
日本の開発者と企業が見るべきポイント
日本の開発現場でも、AIエージェントを導入する際の判断軸は明確です。
- 開発者：生成された攻撃経路から、修正対象となるコードや設定まで戻れるか
- セキュリティ担当者：既存のリスク台帳、MITRE ATT&CK、検知・対応手順へ接続できるか
- 管理者：機密コードの送信先と、利用モデルのデータ保持条件を管理できるか
- 事業責任者：AIの出力を最終判定にせず、承認者と責任範囲を定めているか
導入の第一歩は、全リポジトリを自動判定させることではありません。機密度が低く、構成を把握している小規模なサービスで試し、人間が作った既存の脅威モデルと比較する方法が現実的です。
継続ウォッチ
ThreatForestの価値を判断するには、公開された構成だけでなく、実際の精度と運用負荷を追う必要があります。
- 異なる言語やクラウド構成で、攻撃経路の根拠をどこまで正確に示せるか
- 手作業の脅威モデリングと比べ、見逃しや誤検知がどの程度あるか
- コード変更時に、安定した差分レポートを生成できるか
- MITRE ATT&CKなどの更新を継続的に反映できるか
次に見るべきなのは、生成速度の派手さではありません。実際のプルリクエストで、追加された攻撃経路と根拠コードを再現可能な形で示せるかです。そこまで確認できて初めて、脅威モデリングを継続的な開発工程へ移す道具になります。