AWS Continuumの脅威モデリング（プレビュー）に設計書だけを渡して、仕込んだ弱点をどこまで見つけるか試してみた

こんにちは。

ゲームソリューション部/業務効率化ソリューション部の西川です。

今回はAWS Continuumの脅威モデリング（プレビュー）に、架空のWebサービスの設計書を1本だけ渡して、仕込んでおいた弱点をどこまで脅威として挙げるかを試してみました。

はじめに

背景

脅威モデリングは、設計の段階で「どこが、どう攻撃されうるか」を洗い出す作業です。実装前に穴を見つけられる一方で、セキュリティに詳しい人が設計書を読み込んで時間をかける必要があり、後回しにされやすい作業でもあります。

AWS Security Agent（現在はAWS Continuumの一部）には、この作業をAIエージェントに任せる脅威モデリングの機能が、2026年6月にパブリックプレビューとして追加されました。入力にはソースコードと設計書の両方を使えますが、設計の段階ではまだコードがありません。そこで、設計書だけを渡したときにどこまで脅威を挙げられるかを確認することにしました。

AWS Continuumの脅威モデリングとは

公式ドキュメント（Create a threat model）によると、脅威モデルは設計書やAPI仕様などの「スコープドキュメント」と、接続したリポジトリのソースコードのどちらか、または両方を入力に取ります。出力は次の2つです。

• システムの構成と振る舞いをまとめたシステム概要
• 攻撃のされ方を、重大度、STRIDEの分類、推奨される対策とともに挙げた脅威の一覧

STRIDEは、なりすまし（Spoofing）、改ざん（Tampering）、否認（Repudiation）、情報漏えい（Information disclosure）、サービス妨害（Denial of service）、権限昇格（Elevation of privilege）の頭文字で、脅威を漏れなく考えるための分類です。

執筆時点（2026年11月）の公式の発表（AWS Security Agent announces support for Threat Modeling）では、プレビュー期間中の脅威モデリングに追加費用はかかりません。

試した環境

• AWSアカウント：検証用アカウント、東京リージョン（ap-northeast-1）
• AWSマネジメントコンソールとAWS Security Agentのウェブアプリケーションは日本語表示、2026年11月時点
• ブラウザから操作（AWS CLIやAPIは使っていません）
• 入力：架空のファイル共有サービス「FileDrop」の基本設計書（Markdown、約7KB）を1本
• 画像に写るアカウントIDとリソースIDは、ダミーの値に置き換えて掲載しています

入力に使う設計書

FileDropの構成

FileDropは、社員が社外の取引先とファイルを受け渡すための架空のWebサービスです。本検証のために書きました。構成は次のとおりです。

• 社員はAmazon Cognitoでサインインし、S3の署名付きURLでファイルを直接アップロードする
• 社員が共有リンクを発行すると、Amazon SESで取引先にメールが届く
• 取引先はアカウントを持たず、共有リンクを開くとS3の署名付きURLにリダイレクトされてダウンロードする
• APIはAmazon API GatewayとAWS Lambda、メタデータはAmazon DynamoDBに置く

仕込んだ弱点

設計書には、答え合わせのために弱点を16個書き込みました。設計書には「これは弱点です」とは書かず、仕様として淡々と書いています。

やってみた

AWS Continuumのセットアップ

AWSマネジメントコンソールでAWS Security Agentを開き、「AWS Continuumのセットアップ」を選びます。

エージェントスペース名を入力し、ユーザーアクセス設定は「IAM専用アクセス」のままにしました。エージェントスペースは、レビューや検出結果の範囲を1つのアプリケーションに区切るためのワークスペースです。

サービスアクセスを開くと、アカウントに使えるロールがないため、新しいサービスロールを作る案内が出ました。ロール名は既定値のまま進めました。

画面の下部には、推論リクエストが「リクエストが行われたリージョン以外で処理される場合がある」という注意書きがあります。データの保存先はリクエストしたリージョンと書かれていますが、入力した設計書の内容がリージョン外で処理されうる点は、社内の規程と照らして確認しておく必要があります。

「AWS Continuumのセットアップ」を押すと、本検証環境では10秒ほどでエージェントスペースの一覧が表示されました。

脅威モデルを有効にする

エージェントスペースを開くと、ペネトレーションテスト、設計レビュー、脅威モデル、コードレビューの4つの機能が並んでいます。作成直後の状態では、脅威モデルは「セットアップが必要です」でした。

「脅威モデルを有効にする」を押すと、2段階の設定画面になります。ステップ1はソースコードリポジトリの接続ですが、今回は設計書だけを使うので何も接続せずに進めました。

ステップ2では、CloudWatchのロググループとサービスロールを選べます。サービスロールは「デフォルトロールを作成」のままにしました。セットアップのときに作ったロールとは別に、もう1つロールが作られます。

保存すると、脅威モデルが「準備完了」になりました。

設計書を渡して脅威モデルを実行する

脅威モデルの作成と実行は、コンソールではなくウェブアプリケーションで行います。エージェントスペースの「ウェブアプリを起動」から開き、左のメニューの「脅威モデル」を選びます。

「脅威モデルを作成する」を押し、タイトルを入力します。入力の欄は「リポジトリ」と「機能仕様書」の2つで、設計書は機能仕様書のほうに入れます。

「ファイルをアップロード」から設計書のMarkdownを選び、「追加」を押しました。対応している形式はDOC、DOCX、JPEG、JSON、MD、PDF、PNG、TXT、YAMLと表示されていました。

最後に、ステップ2で作られたサービスロールを選び、「脅威モデルを作成する」を押します。

作成しただけでは実行されないので、詳細画面の「実行を開始する」を押しました。

実行にかかった時間

本検証環境では、実行の開始から完了まで16分24秒かかり、画面上のタスク時間は26分でした。1回だけの観測なので、設計書の分量や時期によって異なる可能性があります。

途中経過を見ると、開始から約4分の時点では何も表示されておらず、約11分の時点ではシステム概要だけが表示されていました。脅威の一覧は、その後の完了時に表示されました。「ログ」タブには27個のタスクが並び、設計書の読み込み、構成の抽出、データの流れの特定、流れごとのリスク評価、という順に進んだことが分かります。

結果

システム概要

システム概要は英語で出力されました。目的、機能、構成、コンポーネントの一覧、信頼の境界、データの流れ、セキュリティの状態、重要な資産、前提が順に並びます。

設計書の内容はおおむね正しく読み取れていました。信頼の境界を「インターネット側」「Cognitoの認証」「AWSの内部」の3つに分け、データの流れをアップロード、共有リンクの発行、取引先のダウンロード、管理者の一覧、削除に分けて、それぞれで権限がどこで入れ替わるかを書いています。たとえば、API Gatewayを過ぎたあとは社員のIDトークンではなくLambdaの実行ロールが操作の主体になる、という点を明記していました。

一方で、設計書と食い違う記述が2か所ありました。

• 冒頭の要約で、取引先が使うリンクを「有効期限付き（time-limited）」と書いている。設計書では、共有リンクそのものには有効期限がなく、期限があるのはリダイレクト先の署名付きURL（7日）だけ
• セキュリティの状態の節で、API Gatewayのオーソライザーが管理者のグループを確認すると書いている。設計書では、API側では確認しないと書いている（同じ概要の「前提」の欄では、フロントエンドに頼っていると正しく書いている）

脅威の一覧

脅威は16件で、重大度の内訳は「高」が11件、「中」が5件でした。

各脅威には、ステートメント、攻撃の発生源、前提条件、攻撃の内容、影響などが英語で書かれています。

挙がった16件は次のとおりです。

分かったこと

仕込んだ弱点との突き合わせ

仕込んだ16個の弱点を、挙がった脅威と突き合わせました。判定は、各脅威のステートメント、前提条件、緩和策などの記述を筆者が読んで行っています。

本検証環境では、16個のうち12個が脅威として挙がりました。1回だけの観測なので、同じ設計書でも実行のたびに結果が変わる可能性があります。

認可の抜け（1から3）は、ばらばらの脅威ではなく、「呼び出し元ごとの認可がない」という1件（#4）にまとめて挙がりました。共有の実行ロールで操作するため、APIの手前で利用者を確認しないと、どの操作でも他人のデータに届いてしまう、という原因でくくっています。

論点がずれた3個は、次のとおりです。

• 5（共有リンクに有効期限がない）：#6は「取り消したあとも使える」という観点で、有効期限を設けない設計そのものは主題にしていない
• 10（IDトークンをlocalStorageに保存）：#2はトークンの窃取を挙げているが、localStorageとXSSには触れていない
• 11（任意の宛先にメールを送れる）：#5は共有リンクが意図しない宛先に流れる点を挙げているが、スパムやフィッシングの送信元として悪用される観点はない

8（アップロードしたファイルを検査しない）に当たる脅威は見当たりませんでした。取引先がダウンロードするファイルがマルウェアの配布経路になる、という観点です。

仕込んでいないのに挙がった脅威

仕込んでいない脅威も5件挙がりました（#9、#11、#13、#15、#16）。このうち#11（SPAを置いたバケットの書き換え）と#13（削除が一括でない）は、設計書の構成と処理の順序から導いたもので、設計書だけを読んだ人が見落としやすい観点だと感じました。

ここからは筆者の見解です

設計書だけを入力にしても、データの流れごとに権限の入れ替わりを追った脅威の一覧が出てきました。設計レビューの叩き台として使えば、レビューする人は一から洗い出すのではなく、挙がった脅威の取捨と抜けの確認に時間を使えると考えています。

ただし、システム概要に設計書と食い違う記述があり、仕込んだ弱点のうち4個は挙がらないか論点がずれていました。そのため、出力をそのまま設計レビューの結果として扱うのではなく、設計書と見比べて誤りを直し、抜けを足す前提で使うのがよいと考えています。

さいごに

AWS Continuumの脅威モデリング（プレビュー）に、設計書を1本だけ渡して試してみました。コードがまだない設計の段階でも、設計書から脅威の一覧を作れるのは便利だと感じました。

今回のポイントをまとめると次の通りです。

• 入力は設計書（Markdown）1本だけで、リポジトリを接続しなくても実行できた
• 本検証環境では、実行に16分24秒（タスク時間26分）かかった
• 出力のシステム概要と脅威は英語で、脅威は16件（高11件、中5件）だった
• 仕込んだ16個の弱点のうち12個が脅威として挙がり、3個は論点がずれ、1個（アップロードしたファイルを検査しない）は挙がらなかった
• システム概要には、設計書と食い違う記述が2か所あった

導入するときは、推論リクエストがリージョン外で処理される場合がある点を、社内の規程と照らして先に確認しておくと安心です。また、出力は英語なので、日本語の設計レビューに載せるときは訳す手間も見込んでおく必要があります。

もう1点、本検証環境では、実行時にCloudWatchのロググループを指定しなかったところ、保持期間が「失効しない」のロググループが自動で作られていました。検証が終わったら削除するか、保持期間を設定しておく必要があります。

本記事がAWS Continuumの脅威モデリングを検討中の方のご参考になっていれば幸いです。