脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説

脅威モデリングは、コードを書く前にシステムの構造を図へ起こし、どこがどう壊されうるかを先に列挙する作業です。動いているシステムを外から叩く脆弱性診断とは、実施する時期も見つかるものも違います。この記事では、DFDと信頼境界の引き方、STRIDEを要素ごとに当てる進め方、LINDDUNやPASTAとの適用範囲の差、OWASP Threat Dragon・pytm・MicrosoftのSDL系ツールの機能差、抽出した脅威をチケットに落として回すところまでを実装目線でまとめました。初回の工数と、着手を見送ってよい規模の線引きも示します。

まとめ｜脅威モデリングを設計工程に組み込む条件と見送る場面の結論

結論から置きます。受託開発の一般的なWebシステムなら、手法はSTRIDE、図はDFD、記録はリポジトリ内のMarkdownかThreat Dragonのjson。この3点を既定にして構いません。手法選定で迷う間に設計が固まる方が、損失として大きいからです。

組み込む条件は2つ。外部と接する境界が複数あること（認証・決済・外部API連携のいずれかを持つ）と、設計変更のたびに図を更新する担当者を1人決められることです。担当が空席のまま始めた脅威モデルは、3か月で実装と乖離した紙になります。

見送ってよい場面も明確です。外部連携を持たない社内向けCRUDアプリや検証用のプロトタイプは、セキュアコーディングの原則と自動検査で足ります。分かれ目は規模ではなく、信頼境界の本数。

脅威モデリングの定義と脆弱性診断・ペネトレーションテストとの実施時期の違い

同じ「セキュリティを確かめる作業」でも、対象がコードか設計かで別物になります。まず守備範囲を揃えます。

設計段階で脅威を洗い出す手法という定義と対象になる成果物の範囲

脅威モデリングとは、システムの構成要素とデータの流れを図として表現し、その図の上で「誰が、どこに、何をしうるか」を体系的に列挙して、対策の要否を決める設計技法です。Microsoft Learn は Threat Modeling Tool の説明で、この手法を「要件分析ではなく設計分析の技法」と位置づけています。対象になるのは動くコードではなく、アーキテクチャ図・API仕様・認証方式の決定といった設計の成果物。

だから、実装が1行も存在しない時点で実施できます。実装前に着手するからこそ、対策が「設計の変更」で済む。費用対効果が最も高いのは、要件定義の終盤から基本設計の中盤までの区間です。

脆弱性診断・ペネトレーションテストとの検出対象と実施時期の違い

脆弱性診断は、稼働中のシステムに既知の攻撃パターンを当てて反応を見る検査です。SQLインジェクションやXSSといった実装起因の欠陥は高い精度で見つかりますが、「権限設計が甘く、正規の操作だけで他人のデータへ到達できる」問題は検出されにくい。ツールから見れば正常なレスポンスだからです。逆に脅威モデリングでは、実装のミスは見つかりません。

両者は代替関係ではなく、時間軸の前後で補完する関係にあります。設計時に脅威モデリング、実装後に脆弱性診断で費用相場と進め方を確認したうえでの検査、リリース前後にペネトレーションテスト。3つめはさらに目的が違い、欠陥の網羅ではなく「特定の目標へ到達できるか」を攻撃者視点で試すものです。網羅性を期待して発注するとずれます。

4つの問いで到達点を測るThreat Modeling Manifestoの位置づけ

到達点の測り方を先に共有しておくと議論が短くなります。Threat Modeling Manifesto は、実務者が合意した4つの問いを軸に置いています。

1. What are we working on?（何を作っているのか）
2. What can go wrong?（何がうまくいかなくなりうるか）
3. What are we going to do about it?（それに対して何をするのか）
4. Did we do a good enough job?（十分な仕事ができたか）

この4問に答えられていれば、図の描き方が多少雑でも脅威モデリングとして成立します。アンチパターンも挙げられており、特定の1人だけが実施する hero modeler と、問題を眺めて対策を決めない problem admiration が代表格。図は複数枚に分かれて構いません。

DFDと信頼境界から始める脅威モデリング4ステップと成果物の粒度

実務の手順は4段階に整理できます。所要時間の目安と、書き込む粒度を合わせて示します。

DFDへ落とす対象範囲の決め方と信頼境界を引く位置の判断基準

最初に描くのはデータフロー図（DFD）です。要素は4種類だけ。外部エンティティ（利用者・外部サービス）、プロセス（アプリ・バッチ）、データストア（DB・S3・ログ）、データフロー（要素間の矢印）。UMLのような厳密さは不要で、手書きを写真に撮った程度でも分析は回ります。

肝心なのは信頼境界の線です。判断基準はひとつ、「線の両側で、データを検証し直す必要があるか」。インターネットとロードバランサの間、自社システムと外部SaaSの間、同じサーバ上でも権限の違うプロセス間。ここに線が入ります。境界が1本もない図が描けたなら、その時点で脅威モデリングは不要と判断して構いません。

要素ごとに脅威を列挙する作業の進め方と1回あたりの所要時間の目安

図が描けたら、要素を1つずつ指差しながら脅威を当てます。参加者は設計者・実装者・可能ならインフラ担当の3〜4人。5人を超えると発言が減ります。

1. DFDの要素に通し番号を振る（E1、P1、D1のように種別＋連番）
2. 信頼境界をまたぐデータフローに印を付け、そこから着手する
3. 要素1つにつきSTRIDEの6分類を順に当て、成立しうるものだけ書き出す
4. 成立しないものは「対象外」と理由を1行残す
5. 1件ごとに「攻撃者は何を得るか」を書き、得るものが無ければ落とす

要素15個・境界4本程度のサブシステムで、所要は90分から120分。抽出される脅威は30〜60件です。ここで対策を議論すると時間が倍以上に膨らむため、列挙と評価は分けてください。

対策の決定とリスク受容の判断を記録する脅威モデル文書の最小構成

文書は薄くて構いません。厚いと更新されなくなります。最小構成は次の5点。

• 対象範囲と前提（どのサブシステムの、いつ時点の設計か）
• DFD本体（画像またはツールのファイル）
• 脅威一覧（ID・要素・STRIDE分類・想定被害・対策または受容の別）
• 受容した脅威の理由と、受容の判断者名
• 次回の見直しトリガー

受容した脅威の記録を省く例をよく見かけますが、これは後で必ず問題になります。半年後に同じ脅威が指摘されたとき、検討済みだと示せないと議論をやり直すためです。保管先はリポジトリ内、設計書と同じディレクトリ。共有ドライブに置くと更新が止まります。

設計変更時に脅威モデルを更新するトリガー条件とレビューの回し方

定期更新は形骸化します。トリガー方式に切り替えてください。条件は、新しい信頼境界が増えたとき、認証や認可の方式を変えたとき、扱うデータの機密区分が上がったとき、外部サービス連携を追加したときの4つ。プルリクエストのテンプレートにチェック項目として置くと、当事者が自分で気づきます。

レビューは30分の枠で足ります。前回からの差分だけを見て、増えた要素にSTRIDEを当て直す。全体の再実施は不要です。

STRIDE・LINDDUN・PASTAなど5手法の適用範囲と選び分けの基準

手法は複数ありますが、実務で選ぶ場面は限られます。STRIDEの中身と、他手法との住み分けを見ます。

STRIDEの6分類と要素単位で当てるSTRIDE-per-Elementの手順

STRIDEはMicrosoftが体系化した分類で、頭文字が6つの脅威カテゴリを表します。DFDの要素種別ごとに成立しやすいカテゴリが決まっているため、全要素に6分類を機械的に当てる必要はありません。

この対応表を使う進め方がSTRIDE-per-Elementです。もうひとつ STRIDE-per-Interaction があり、信頼境界をまたぐ相互作用に絞って当てるもの。要素数が多い大規模システムでは後者が現実的です。

LINDDUN・PASTA・アタックツリーを含む5手法の適用範囲の比較

手法ごとに、答えを出したい問いが違います。同じ図を使い回せるものと、専用の入力が要るものが混在します。

DREADは抽出手法ではなく採点手法なので、STRIDEと並列に比較するものではありません。PASTAは7段階のプロセスを持ち、脅威情報の収集や攻撃シミュレーションまで含むため、専任のセキュリティ担当がいない体制で回すのは無理があります。LINDDUNは同じDFDを流用でき、追加負荷は1時間程度。

受託開発のWebシステムでSTRIDEを既定に置いてよい判断根拠

受託案件でSTRIDEを既定にしてよい理由は3つ。入力がDFD1枚で済むこと、対応表があるためセキュリティ専門家でなくても進行できること、主要ツールが揃ってSTRIDEを前提に作られていることです。

言い切ります。手法の比較検討に工数を割くのは初回だけで、2案件目以降にPASTAやTrikeを再検討する価値はほぼありません。判断が変わるのは、個人情報の大量保管に及ぶとき（LINDDUNを足す）と、単一の重大シナリオを詰めるとき（アタックツリーを足す）の2ケースです。

脅威モデリングツール3種の機能差とCI/CD組み込み可否での選定基準

ツールの選択肢は絞られています。版と要件を確認し、体制に合うものを1つ決めてください。

OWASP Threat Dragon 2.6系のテンプレートとリポジトリ連携

OWASP Threat Dragon は、ブラウザとデスクトップの両方で動く作図型のツールです。最新安定版は v2.6.2 で、2026年5月10日にリリース。v2.6.0（2026年3月30日）で OWASP Cornucopia との連携と脅威モデルテンプレートが加わり、ゼロから描き始める負担が下がりました。Windows・macOS・Linux・Docker で配布されています。

脅威モデルはjson形式で保存され、GitHubやGitLabのリポジトリに直接読み書きできます。設計書と同じ場所で版管理でき、プルリクエストのレビュー対象に含められる点が実務では効きます。

pytm 1.4系でコード定義した脅威モデルをCIへ組み込む手順

OWASP pytm は、脅威モデルをPythonのコードとして書く方式です。最新版は 1.4.0 で2026年7月6日にリリース、要件は Python 3.11 以上（3.14まで対応）。図は入力ではなく出力で、コードからDFDとシーケンス図、脅威一覧のレポートが生成されます。

1. pip install pytm でインストールし、Python 3.11以上の環境を用意する
2. Boundary・Actor・Process・Datastore・Dataflow をPythonオブジェクトとして定義する
3. 各Dataflowに認証やプロトコルの属性を設定し、モデルを組み立てる
4. スクリプトを実行してDFDとレポートを生成し、生成物をリポジトリへ保存する
5. CIのジョブに実行を追加し、モデル定義の変更時にレポート差分を検出する

この方式が向くのは、設計もコードで管理する文化が定着しているチーム。非エンジニアを含む合議で脅威を洗い出す場面には不向きです。画面共有しながらオブジェクト定義を編集する会議は成立しません。

MicrosoftのSDL系ツールが持つ自動列挙の強みとWindows前提の制約

Microsoft Threat Modeling Tool は Microsoft SDL の中核要素として提供されており、Microsoft Learn では STRIDE per Element によるガイド付き分析、作図中のフィードバック、検証フェーズ向けのレポート出力を機能として挙げています。図を描いた時点で候補脅威が自動列挙されるため、初回の学習コストが最も低いツール。2026年8月時点で提供終了の告知は同ページに出ていません。

制約はWindowsのデスクトップアプリである点です。macOS中心のチームや、CIで回したい用途には合いません。テンプレートの拡張もAzure寄り。学習用に初回だけ使い、運用は Threat Dragon へ移す進め方が現実的です。

ツール未導入でも成立する作図とスプレッドシートだけの運用条件

ツールを入れないという選択も成立します。条件は、対象が1サブシステムに収まり、脅威が50件を超えないこと。この規模なら、図はdraw.io、脅威一覧はスプレッドシート1枚で管理できます。導入承認を待つ間に設計が終わる方が、損失として大きい。移行の目安は、対象システムが3つを超えたときか脅威の総数が100件を超えたときです。

抽出した脅威の優先度付けとチケット化までの運用設計と再実施の頻度

洗い出しただけの一覧は、放置すれば単なる不安リスト。開発チケットへ落とすまでを設計に含めます。

CVSS v4.0とDREADの使い分けと設計段階でスコアが割れる原因

CVSS は現行版が v4.0 で、公表済み脆弱性の深刻度を共通尺度で表すために設計されたものです。設計段階の脅威に当てると、攻撃条件や影響範囲が「まだ決まっていない」ため、評価者によってスコアが2ポイント以上ぶれます。原因は技量ではなく、入力すべき事実が存在しないこと。

設計段階ではDREADのような粗い相対評価か、被害の大きさと発生しやすさの2軸を各3段階に切った9マスで十分です。目的は絶対値ではなく着手順を決めること。攻撃条件が確定した実装後に、残った脅威をCVSS v4.0で採点し直せば整合が取れます。

脅威1件をチケット化する際の記載項目とリスク受容の判断の記録方法

脅威一覧のIDとチケットを1対1で紐づけます。書く項目は次の5点。

• 脅威ID（脅威モデル文書と一致させる）
• 対象要素とSTRIDE分類
• 攻撃者が得るもの（データ・権限・可用性の低下）
• 合意した対策と、対策後に残るリスク
• 検証方法（テストコード・診断項目・設定レビューのどれで確認するか）

検証方法の欄を空のまま閉じるチケットが増えると、脅威モデリングは実施記録だけを残す作業に退化します。受容する場合はチケットを閉じずに「受容」ステータスへ移し、判断者と期限を書いてください。期限超過で再検討へ自動で戻る仕組みにすれば、暫定の受容が恒久化しません。

SASTやDASTの検出結果と脅威モデルを突き合わせる運用の作り方

脅威モデルの精度は、自動検査の結果と突き合わせて上げます。SASTによる静的解析の検出結果に、想定していなかった種類の欠陥が繰り返し現れるなら、DFDの粒度が粗いか、分析から漏れた要素があります。逆に対策済みとした箇所から同種の指摘が出続けるなら、対策が設計だけで終わり実装に届いていません。

四半期に1度、検出結果と脅威一覧の分類を並べるだけで、このずれは見えます。作業時間は1時間程度。

脅威モデリングが形骸化する条件と着手を見送るべきプロジェクト規模

導入して定着しなかった場面には、共通の条件があります。

初回3〜5人日という工数の実態と2回目以降に所要が逓減する条件

初回の工数は、対象1サブシステムあたり3〜5人日を見込んでください。内訳は、手法とツールの学習に1〜2人日、DFD作成に0.5人日、抽出セッションに3〜4人時間×3〜4人、対策の合意とチケット化に1人日、文書化に0.5人日。学習分が過半を占めます。

2回目以降は1〜1.5人日まで落ちます。学習が不要になり、DFDのテンプレートと対応表を再利用できるためです。ただし逓減の条件は、同じメンバーが継続して担当すること。担当が毎回入れ替わる体制では、3回目でも初回と同じ工数がかかります。

形骸化を招く3つの失敗パターンと図を書いて終わらせない歯止め

ひとつめは、抽出セッションで対策まで議論し、時間切れで後半の要素が未分析のまま終わるパターン。列挙と評価を別枠に分ければ避けられます。ふたつめは、脅威をチケット化せず文書内の表に留めるパターンで、開発の作業一覧に載らない項目は着手されません。

3つめが最も多い。セキュリティ担当が1人で図を描き、実装者がレビューに参加しない構図です。Threat Modeling Manifesto が hero modeler をアンチパターンに挙げているのはこの型を指しています。歯止めは、脅威モデルの更新を設計変更のプルリクエストの完了条件に組み込むこと。工程全体への置き方はDevSecOpsのライフサイクル設計と合わせて考えます。

着手を見送ってよいプロジェクト規模と代わりに置く最低限の統制

見送ってよい条件を具体的に示します。信頼境界が1本以下、画面数10未満、個人情報を保持しない、外部API連携なし。この4つをすべて満たすなら、枠組みを導入する価値は工数に見合いません。代わりに置くのは、フレームワークの既定のセキュリティ設定を無効化していないことの確認、依存パッケージの自動更新、リリース前の1回の検査です。

逆に、決済や認証基盤を含む、あるいは個人データを1万件以上保持する設計なら、規模が小さくても実施してください。設計段階で見落とした脅威が実装後の検査で見つかると、修正が設計の作り直しになります。設計レビューの経験者が社内にいない場合は、初回だけ外部の脆弱性診断・セキュリティ診断と組み合わせ、設計と実装の両側から確認する進め方が現実的です。

よくある質問

導入検討でよく挙がる質問をまとめました。

脅威モデリングとリスクアセスメントは何が違いますか？

対象と粒度が違います。リスクアセスメントは組織や情報資産の単位でリスクを洗い出して管理策を決める枠組みで、ISMSの運用に組み込まれるもの。脅威モデリングは特定システムの設計を対象に、技術的な攻撃経路を要素単位で列挙します。前者の結果が後者の前提になり、「この資産の機密区分は高」という結論が受容判断の基準になります。

STRIDEを覚えていなくても脅威モデリングを実施できますか？

できます。Microsoft Threat Modeling Tool は要素の種別に応じて候補となる脅威を自動で提示するため、6分類の暗記は前提になりません。OWASP Threat Dragon も v2.6.0 以降はテンプレートを備えています。ただし候補が自社の設計で成立するかを判断するのは人の作業なので、構造を理解している実装者の参加は必要です。

脅威モデリングは1回実施すれば済みますか？

済みません。設計が変わると脅威も変わるためです。新しい信頼境界が増えたとき、認証・認可の方式を変えたとき、扱うデータの機密区分が上がったとき、外部連携を追加したときの4条件をトリガーに、差分だけを見直す運用が回ります。定期実施を年2回で固定すると、変更の多い時期に追いつきません。

アジャイル開発でも脅威モデリングを組み込めますか？

組み込めます。スプリント単位で全体をやり直すのではなく、対象を1機能に絞って30〜60分で回す進め方が合う。バックログの受け入れ条件に「新しい信頼境界を追加する場合は脅威モデルを更新する」と1行入れておくと、実施判断が自動化されます。初回だけはシステム全体のDFDを作る時間を確保してください。全体像が無いまま機能単位で分析すると、要素間の相互作用に起因する脅威が抜けます。

脅威モデリングの結果は脆弱性診断の代わりになりますか？

なりません。脅威モデリングで見つかるのは設計起因の問題で、実装のミスや設定の漏れは対象外だからです。逆に脆弱性診断は実装と設定の欠陥を高い精度で検出しますが、権限設計の甘さは正常応答として素通りします。設計時に脅威モデリング、実装後に静的解析と動的解析、リリース前に脆弱性診断という順に重ねる構成が、抜けの少ない組み合わせです。

関連記事

• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：実装後の検査工程の費用感を外注前提で整理
• セキュアコーディングとは？10原則と主要脆弱性のコード対策を実装目線で解説：抽出した脅威をコード側で潰す原則
• SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説：静的解析の結果と突き合わせる前提知識
• DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説：稼働中のアプリへの動的検査の位置づけ
• DevSecOpsとは？DevOpsとの違い・ライフサイクル・導入判断を実装視点で解説：開発工程全体のどこに置くかの設計