【AWS re:Invent 2025】ThreatForestを使用した脅威モデリング実行編

こんにちはセキュリティエンジニアリングの西川です。本記事は前回の続きで、実際に ThreatForest を実行する方法や実行した結果についてシェアしていきますので、ThreatForest って何？という方は前回の記事をご覧いただければと思います。

初回ステップ

クレデンシャルの設定をします。様々な LLM を選択できはするのですが、実際は初期リリース（AWS re:Invent 2025 時点）では AWS の Bedrock しか対応していません。そのため Bedrock を利用するためのクレデンシャルの設定がまずは必要です。

モデル選択については、

• Haiku（高速）
• Sonnet 4.5（バランス）
• Opus（構造化に強いがやや遅い）

などを推奨していましたがデモでは時間の都合で Haiku を選択していました。早いからという理由だけです。実際は色々と試してみると良さそうです。

コンテキストの準備と Threat Composer

ThreatForest のドキュメントでも強調していますが、プロジェクトの準備が非常に重要です。

• アプリケーションの目的
• どんな機能を提供しているか
• どのような業種か（ヘルスケア、静的サイトなど）
• データフローやアーキテクチャ図

などの情報があればあるほど、ThreatForest はより精度の高い結果を出せるとのことですが、ドキュメントが少なくても動きはするものの、その場合はどうしても「汎用的で抽象度の高い」結果になってしまうらしいです。デモでは、GitHub に用意されたサンプルアプリケーションを使っていました。

ここでは Threat Composer のファイルを利用しています。

• アプリケーション情報
• アーキテクチャ図
• データフロー
• 前提条件（Assumptions）
• Threat Statement

などを含む JSON ファイルを VS Code などの IDE 上で編集することができ、そのファイルを GitHub にコミットすれば、「生きた脅威モデル」としてリポジトリに残しておけるので良いと話をしていました。

CLI は次に、

Do you have existing threat statements? [y/n] (n):

と尋ねてきますが、Yes の場合はそのファイルから Threat Statement をパースし、No の場合はThreatForest が Threat Statement を自動生成します。デモでは Threat Composer ファイルがありましたので YES を選び、そのファイルパスを指定していました。

実行中の挙動とログ

実行中は、コンソールとログで内部の進捗が確認できます。

• Threat Composer ファイルから Threat Statement を抽出
  • 例：合計 11 件（High 6、Medium/Low 5）
• Repository Analysis Agent が下記を特定
  • 使用技術（Lambda, API Gateway, DynamoDB など）
  • データ資産（S3 バケット、EBS ボリュームなど）
  • Entry Point
• それらをもとに Attack Steps を生成
• Embedding モデルを使って各ノードを MITRE TTP にマッピング

※これは私が OWASP Juice Shop というやられアプリに対して実行した様子です。

最終的に下記の画像のように HTML のダッシュボードが生成されブラウザで開かれます。

出力されるダッシュボードと Attack Tree

ダッシュボードには次のような情報が表示されます。

• Threat のサマリ
  • 合計件数
  • High の件数
• Attack Tree の数
• ノード総数
• プロジェクトの概要
  • Connected Vehicle Solution
  • サーバーレスアーキテクチャ
  • 業種情報
  • 技術スタック

High Severity Threat の例として、次のような Threat Statement が表示されます。

「AWS アカウントにアクセスできる内部アクターが、既存の実行ロールを利用する Lambda 関数をデプロイし、不正に機密データへアクセスしてしまい、登録状態（registration status）の機密性が低下する。」

OWASP Juice Shop では下記の画像のようなものが表示されています。

各 Threat について「View Attack Tree」をクリックすると、Attack Tree が表示されます。

ルートノード（青）とゴールノード（オレンジ）攻撃経路（赤）のノードがあり、ルートノードとゴールノードの間に複数の攻撃経路があるという感じです。

セッションの例では、

• 既存の Lambda 実行ロールの Recon
• IAM ロールの列挙
• 過剰権限を持つロールの特定
• 機密データを扱うロールの悪用

などのノードが並んでいました。

各ノードをクリックすると、

• 対応する MITRE ATT&CK のテクニック
• 類似度スコア（例：42%）
  • 私が実行した感じではスコアは見られなかったですが、話はありました。
• 推奨される緩和策（mitigation）

が表示されます。

緩和策は ATT&CK から得られる情報に基づいていて、

• なぜその対策が必要なのか
• どのようにリスクを下げられるのか

を開発者目線でも理解しやすいようになっています。と話がありましたが、実際見てみるとちょっと難しいかなーという想いもあります。個人的には。

また、共通する緩和策が複数の Attack Step に繰り返し現れることも多く、

「この対策を優先的に実装すれば、複数の経路のリスクを一気に下げられる」

といった優先順位付けにも役立たせることができ、これは実際ありそうです。

出力ファイルと内部構造

ThreatForest の出力は HTML ダッシュボードだけではなく、下記のようなものもあります。

• Markdown (.md) のレポート
  • 概要
  • 技術スタック
  • 業種・目的
  • 分析結果
  • 高リスク Threat の一覧
  • 各 Attack Tree の概要と推奨緩和策
• Mermaid 形式の Attack Tree
• 状態管理用の JSON（新たな Threat が追加されたときだけ再生成するなど）
• グラフ構造と Embedding データ（ローカルファイル）
• config.yaml（設定ファイル）

コードの観点では、

• graph モジュール
  • Sentence Transformers（Hugging Face ベース）を使い、任意の Embedding モデルを利用可能
  • MITRE ATT&CK のテクニック・緩和策をノードとしてグラフ化
  • グラフ探索は線形時間で、ベクトル検索に NumPy などを利用
• agents モジュール
  • Strands Agent Framework をベースとした複数エージェント
    • Content Extractor Agent：リポジトリ構造理解、ファイル分類（アーキ図、README、ソースコードなど）
    • Parser Agent：Threat Statement / Threat Composer ファイルの解析
    • Threat Generation Agent：Threat Statement の自動生成
  • これらはマルチモーダルで、画像（アーキテクチャ図など）も扱える
• Editor Agent のラッパ
  • リポジトリ内で
    • ディレクトリ構造の取得
    • テキスト検索 / ファジー検索
    • ファイルのインライン閲覧
  • 読み取り専用に制限し、誤ってファイルを書き換えないようにしている
• CLI モジュール
  • 対話的な CLI インターフェースを提供

といった構成になっています。

他のユースケースと今後

ThreatForest は、前回の記事でお伝えした 4 つの質問フレームワークのうち、次の部分を幅広くカバーします。

• Threat Intelligence の取り込み
• Threat Statement 作成
• Attack Tree 作成
• 緩和策候補の抽出

一方で、

• コントロールの有効性検証（実際のテスト）
• 正式なリスク分析（ビジネス判断を含む）

は、まだ人間や他のプロセスの役割です。

Attack Tree には、他にも興味深いユースケースがあると言う話がありました。

• 侵入テスト（手動・自動）のシナリオ設計
• Security Agent（自動ペネトレーションテスト）の入力として活用
• Blue Team / SOC の「検知力の棚卸し」
  • 各 Attack Step に対して下記を確認する
    • ログは取れているか？
    • 検知ロジックはあるか？
    • アラートは上がるか？

Threat Intelligence の情報と組み合わせることで、

• 自社の業種・ポジションに特有のリスク
• その攻撃者グループが好んで使うテクニック

を踏まえたシナリオをシミュレーションすることができるという話がありました。

また、AWS の Threat Technique Catalog（AWS 環境に特化した TTP カタログ）も今後のバージョンで取り込む予定で、これは AWS のインシデント対応チームが実際に観測した攻撃手法に基づく、とても有用なリソースとのことです。

感想

OWASP Juice Shop はもっと脆弱性があるはずなのに脅威インテリジェンスから見るとこれぐらいしか出てこず、今のところは正直厳しい印象です。もちろん構成図だったりのコンテキストを十分に与えられていないのでその辺が影響している可能性はあります。ただ、他にも High 以外の情報が出ていなかったり、これをみた人がアクショナブルに対処ができるかというと今現在は難しく思います。

一方で、将来的にこの結果を AWS Security Agent にインポートして、Security Agent 側でペネトレーションテストが実行できるようになると、より精度が高いものが生まれそうですし、まだ公開されたばかりの OSS なので、コントリビューターが増えて成長していくのを期待したいと思います！（他力本願）

最後までご覧いただきありがとうございました。