はじめに
2026/6/17のAWS Summit New York Cityで、AWS Security Agent 脅威モデリング機能のパブリックプレビュー版公開が発表されました。
前回コードレビューをやってみましたので、脅威モデルもパブリックプレビュー版の間に色々試してみたいと思い、やってみました。
本記事は、筆者個人の見解です。個人利用の範囲で試した結果のため、参考程度に留めてください。
脅威モデリングとは？
そもそも「脅威モデリング」とは何なのか、ここから触れていきます。
脅威モデリングは、脅威を特定し、システムに対する脅威の影響を防止または軽減するための対策を定義することで、セキュリティを向上させるための一連の活動です。
※OWASPのサイトより引用
https://owasp.org/www-community/Threat_Modeling
AWS Security Agent 脅威モデリングについて
設計ドキュメントまたはアプリケーションのソースコードからアプリケーションアーキテクチャの全体像を把握して、STRIDEフレームワークを使用した脅威を特定及び推奨される対策を提示する機能です。
AWS Well-Architected フレームワークのセキュリティの柱のSEC01-BP07で、脅威モデルを使用して脅威を特定について記載されています。Security Agent 脅威モデリングは、Well-Architected フレームワークに沿った構築をする一助となるために公開された機能ではないかと、私は思いました。
STRIDEとは？
以下主要な脅威の頭文字を並べた言葉です。これらの観点で脅威を分析する脅威モデリングの分析手法の一つです。
| カテゴリ | 説明 |
|---|---|
| Spoofing | なりすまし |
| Tampering | 改ざん |
| Repudiation | 否認 |
| Information disclosure | 情報漏洩 |
| Denial of service | サービス拒否 |
| Elevation of privileg | 権限昇格 |
脅威モデルをやってみた
AWS Security Agent 脅威モデルを試します。
Security Agent を初回に起動する場合は、エージェントスペースを作る必要があります。エージェントスペースの作り方は、以前コードレビューを実施した時の記事に記載しています。
https://qiita.com/amarelo_n24/items/e196b74f718c750a0e18
① Security Agent の画面を開きます。
②「ウェブアプリで開始」をクリックします。
③「脅威モデルを作成する」をクリックします。
④ 脅威モデルを実行したいリポジトリ、機能仕様書（設計書等）、アクセス許可するサービスロールとCloudWatchロググループを選択して、脅威モデルを作成します。
⑤「実行を開始する」をクリックして、脅威モデルの実行を開始します。
※実行中は、脅威モデルの処理内容を見ることもできます。
⑥ステータスが「完了済み」になったら脅威モデル実行完了です。今回は１時間ほどかかりました。
脅威モデルの実行結果確認とレポート出力
実行完了した脅威モデルをクリックすると、検出結果の合計、カテゴリごとの脅威、実行対象のWebアプリケーションについての分析結果を参照できます。
「脅威」タグをクリックすると、検出された脅威の詳細を見ることができます。
画面右上の「レポートを生成」をクリックすると、PDFのレポート出力ができます。Security Agent を参照できない人にも情報共有することができます。
東京リージョンで実行しましたが、実行結果画面とレポートは英語表記でした。日本語対応は今後のアップデートに期待します。
（疑問）脆弱性診断ツール検証用として作られたWebアプリケーションだと判定しない？
躓きというほどではありませんが、脅威モデル実行しても脅威を確認しなかった（or できなかった）事例にあたりました。
最初、Security Agent の検証のために作成（生成AIにて作成しましたが、何を使ったかは割愛します）したWebアプリケーションを含むリポジトリに対して、脅威モデルを実施しました。しかし、Security Agentは脅威が無いと判断しました。
Security Agent が分析した実行対象の目的を読むと、「欠陥は、修正すべき不具合ではなく、評価の対象」と判断した記述がありました…
想定される原因
- 生成AIにテスト用アプリケーション作成の指示をした際に、「Security Agent 動作確認用」ということを含めたため、リポジトリ名がSecurity Agent のPoCを想像させるものだった
- READMEにも「セキュリティテスト専用のサイト」の旨書かれていた
※READMEの記載内容の一部
Security Agent が脅威モデル実行中にこの情報を知ってしまい、脅威があっても問題ないと判断した可能性があります。この２つを変更して実行していないため憶測の域を抜けませんが、リポジトリ内にセキュリティツール検証用と想像される痕跡が残っている場合、問題ないと判断される可能性があります。
この後、リポジトリを作り直しました。Security Agent 動作確認用、脆弱性診断ツールテスト用などという指示を一切含めず、生成AIにリポジトリの再作成指示をしました。そのリポジトリを脅威モデル実行対象として、脅威を検出できました。
感想：脅威モデルを人の能力だけで実施するのは大変
コードレビューを実施した時も思いましたが、どこに脆弱性があって、何の脅威があるかを、人の能力だけで洗い出すのは骨が折れます。知識がある人も決して多くないでしょうし、セキュアな環境を作るためのリソースが莫大に掛かることを実感しました。
Security Agent のような脆弱性や脅威を洗い出すエージェントを上手く使うことで、システムに及ぼす影響度の解像度を高めることができることも実感しました。
とはいえ、エージェントが出した結果すべて正解ではないと思っています。Webアプリケーションの構成によっては、過剰検知、リスクレベルが低くても早期対応が必要なものもあると思います。 出てきた結果に対する対応可否、対応する脅威の最終的なトリアージは、絶対に人が判断しなければならないところだと思いました。
最後に
「脅威モデリング」という言葉を知っていたものの、どのようなものか、何を知ることができるのかを深掘りできていませんでしたので、今回、Security Agent 脅威モデルを実施して、その一端を経験できたのは良かったです。
GAされたらそれなりの金額になることと思われますので、プレビュー版で費用発生しない間にSecurity Agent を使って、コードレビュー、脅威モデリングについてもっと学習してみようと思います。Security Agent が、脆弱性診断と脅威モデリングを身近に感じさせるいいきっかけになればと思いました。
この記事がどなたかの参考になれば幸いです。
最後まで読んでいただき、ありがとうございました！