[アップデート] AWS Security Agent に脅威モデリング機能が追加され、設計ドキュメントやソースコードから STRIDE ベースの脅威分析を自動生成できるようになりました

いわさです。

AWS Security Agent（現在は AWS Continuum の一部）は、アプリケーションの開発ライフサイクル全体を通じてセキュリティを担保する AI エージェントサービスです。
re:Invent 2025 でプレビューとして発表され、その後オンデマンドのペネトレーションテストが GA になったほか、フルリポジトリのコードレビュー機能もプレビュー提供されています。

https://dev.classmethod.jp/articles/aws-security-agent-cognito-auth-bypass/

上記はペネトレーションテスト機能の検証記事です。

先日のアップデートで、この AWS Security Agent に脅威モデリング機能がパブリックプレビューとして追加されました。

https://aws.amazon.com/about-aws/whats-new/2026/06/aws-security-agent-threat-modeling/

脅威モデリングは、アプリケーションに対するセキュリティ上の脅威を特定・評価するプロセスです。

今回のアップデートで、Security Agent に設計ドキュメントやソースコードを入力として渡すと、アーキテクチャやデータフローを自動で分析し、脅威モデルを生成してくれるみたいです。

なお、同時に Kiro Power や Claude Code プラグイン、MCP 連携も発表されていますが、今回は脅威モデリング機能に絞って確認してみたので紹介します。

脅威モデリング機能を使ってみる

では早速 Security Agent のウェブアプリから脅威モデリング機能を確認してみましょう。

入力ソースについて

公式ドキュメントによると、脅威モデリングへの入力は「スコープドキュメント」と「ソースコード」の 2 種類があるみたいです。

A threat model accepts two kinds of inputs, and you can provide either or both:
Scope docs – Technical design documents, API specifications, or architecture documentation that define what the threat model focuses on.
Sources – Source code from connected repositories (GitHub, GitHub Enterprise Server, GitLab, GitLab Self-Managed, or Bitbucket) or from S3 locations.

https://docs.aws.amazon.com/securityagent/latest/userguide/perform-threat-model.html

スコープドキュメントは設計書や API 仕様書などです。
ソースコードはリポジトリ連携か S3 経由で接続します。
両方渡すとスコープドキュメントで範囲を絞りつつソースコードで実装のコンテキストを補完してくれるとのこと。
どちらか片方だけでも実行可能なので、コードが存在しない設計フェーズでも使えるのは便利そうです。

今回はスコープドキュメントのみで脅威モデルを実行してみました。

ウェブアプリでの操作

なお、Security Agent にはウェブアプリ（脅威モデルの作成・実行画面）と、マネジメントコンソール（エージェントスペースの管理画面）の 2 つの UI があります。
マネジメントコンソール側のエージェントスペースでは「脅威モデル」タブが用意されていて、ここから有効化の状態を確認できます。

実際に脅威モデルの作成・実行はウェブアプリ側で行います。
ウェブアプリにアクセスすると、Threat models のメニューが用意されています。

「Create threat model」を選択すると、脅威モデルの作成画面が表示されます。
ウェブアプリ上では「Feature documents」というセクション名でスコープドキュメントをアップロードできます。

今回は簡単なサーバーレス REST API の設計ドキュメント（マークダウンファイル、1.15KB）をアップロードしてみました。
API Gateway + Lambda + DynamoDB + Cognito + S3 で構成されたタスク管理 API の設計書です。

アップロードダイアログに表示されている通り、対応ファイル形式は DOC、DOCX、JPEG、JSON、MD、PDF、PNG、TXT、YAML です。

Service role を設定して「Create threat model」を選択し、「Start run」で分析を開始します。

実行結果

実行を開始すると Overview タブでリアルタイムに状況を確認できます。
Threat categories のチャートには STRIDE フレームワークの 6 カテゴリが並んでいます。
STRIDE は脅威を Spoofing（なりすまし）・Tampering（改ざん）・Repudiation（否認）・Information Disclosure（情報漏洩）・Denial of Service（サービス拒否）・Elevation of Privilege（権限昇格）に分類する手法で、今回の脅威モデリング機能ではこのフレームワークに基づいて分析が行われます。

https://dev.classmethod.jp/articles/202512-reinvent2025-sec335-chalktalk/

27 分 41 秒で分析が完了しました。
この短い設計ドキュメントで 30 分近くかかったのは思ったより時間がかかる印象です。

結果は 15 件の脅威が検出され、High が 11 件（73%）、Medium が 4 件（27%）でした。
今回はサンプルとして用意した簡易的な設計ドキュメントに対する結果なので、件数や重要度の分布自体に深い意味はありませんが、STRIDE の 6 カテゴリすべてに脅威が分散して検出されていることが確認できます。

System Overview の生成

Overview タブの下部には「System overview」セクションが自動生成されています。
渡した設計ドキュメントから、以下のような詳細な分析結果が生成されていました。

• Purpose / Design Intent（システムの目的と設計意図）
• Architecture（アーキテクチャの詳細な説明）
• Components テーブル（各コンポーネントの役割と相互作用）
• Trust Boundaries（Public Internet / AWS Public-Facing Services / AWS Private Backend の 3 ゾーン）
• Data Flows（認証フロー、タスク CRUD、Pre-signed URL 生成、S3 直接アップロードなど）
• Security Posture（現在のセキュリティ態勢）
• Sensitive Assets（機密資産の洗い出し）
• Key Assumptions（前提条件の列挙）

ちょっと Overview のテキスト部分を全乗せしますね。

1.15KB のマークダウンファイルからここまで詳細に分析してくるのはなかなかです。
たとえば Data Flows では、Cognito 認証から API Gateway での JWT 検証、Lambda での DynamoDB 操作まで、各ステップでどのゾーンを越えるか、どの認証情報が流れるかが具体的に記述されていました。

Threats タブ

Threats タブでは検出された 15 件の脅威を一覧で確認できます。

個別の脅威を選択すると、以下の構造化された情報が確認できます。

• Severity（High / Medium / Low）
• STRIDE カテゴリ
• Description（Statement、Source、Prerequisites、Action、Impact）
• References（Affected assets、Evidence のファイルパス、Anchor）
• Recommendation（緩和策）

たとえば最初の脅威では、DynamoDB テーブルにバックアップ（PITR）が設定されておらず、かつ CDK の削除ポリシーが DESTROY になっているため、データを消したら二度と復旧できないリスクが指摘されています。
推奨事項として「PITR を有効にして削除ポリシーを RETAIN か SNAPSHOT に変更すること」と出ていました。

もう 1 つの例として、API Gateway の認証設定が外れてしまった場合に、Lambda 関数に渡されるユーザー情報を攻撃者が自由に差し替えられてしまうリスクも検出されていました。
こちらは Elevation of privilege（権限昇格）に分類されています。
なお、Evidence としてソースコードのファイルパスが示されていますが、今回はスコープドキュメントのみで実行したのでエージェントが推測したパスのようです。

Logs タブ

Logs タブではエージェントの処理パイプラインを追跡できます。

タスクの実行順序を見ると、以下のように段階的に分析が進んでいることがわかります。

1. document_ingestor — ドキュメントの読み込み（1 秒）
2. document_analyzer — アーキテクチャの抽出
3. architecture_merge — コードとドキュメントのアーキテクチャをマージ
4. trace_identify — エンドツーエンドのデータフロー特定
5. scope_resolver — スコープ内のトレースをフィルタリング（21 秒）
6. posture_prioritizer — リスクによるトレースのランク付け
7. 各 Posture * タスク — データフローごとのセキュリティ姿勢評価
8. system_context — システムコンテキストドキュメントの生成
9. 各 Trace Threats * タスク — トレースごとの STRIDE 脅威列挙
10. threats_summarizer — 脅威の重複排除とランク付け

scope_resolver では各データフロー（ユーザー認証、タスク作成、タスク参照等）が分析対象に含まれるかどうかを 1 つずつ判定している様子が確認できます。
エージェントが何をやっているのかをログで追えるのは良いですね。前回別の記事で書きましたが、ログから独自のレポート作成も出来そうな気がします。

レポートの生成

「Generate report」ボタンから PDF レポートを生成できます。

45 ページの PDF レポートが生成されました。
Introduction、System Overview、Configuration、Threats（15 件分の詳細）が構造化されてまとまっています。

レポート内では各脅威に対して Threat Source、Prerequisites、Threat Action、Impact、Evidence、Recommendation が整理されているので、チームへの共有やレビュー会議の資料としてそのまま使えそうな形式です。
なお、レポートは英語のみの出力でした。日本語対応は今後に期待したいところ。

さいごに

本日は AWS Security Agent に脅威モデリング機能が追加されたので確認してみました。

1.15KB の簡単な設計ドキュメント 1 枚からここまでの分析が自動生成されました。
今回はサンプルとして用意した簡易的な設計書での検証なので脅威の件数や重要度そのものに意味はありませんが、機能として入力ドキュメントから何を読み取ってどのレベルの分析を出力してくれるかは確認できました。

脅威モデリングよくわからないけどとりあえずやってみるかーみたいな感じで、セキュリティレビューの出発点として使えそうだなと感じます。
レポートが英語のみなのは今後の日本語対応に期待したいところですが、パブリックプレビュー期間中は追加料金なしで利用できるとのことなので、気軽に試してみると良さそうです。