重大な脆弱性の大半は、コーディングではなく設計フェーズで生まれます。軽量な脅威モデリングを早期に行い、オーナーを明確にする方が、本番リリース後の100ページのペンテストレポートよりはるかに価値があります。
脅威モデリングとは？
脅威モデリングはAdam Shostackの4つの問いに答えるプロセスです：
- What are we working on?——データフローダイアグラム（DFD）を描く。
- What can go wrong?——STRIDEを適用して脅威を列挙する。
- What are we going to do about it?——緩和策、または責任者を明確にしたうえでのリスク受容。
- Did we do a good job?——実装後にレビューする。
STRIDEを1分で理解する
| 脅威 | 違反する性質 | 例 |
|---|---|---|
| Spoofing（なりすまし） | 認証 | ユーザーのなりすまし、トークンの再利用 |
| Tampering（改ざん） | 完全性 | リクエストの改変、DB上のデータ改ざん |
| Repudiation（否認） | 否認防止 | 行為を証明できる十分な監査ログがない |
| Information disclosure（情報漏洩） | 機密性 | PIIの漏洩、ログ経由でのキー漏洩 |
| Denial of service（サービス拒否） | 可用性 | ブルートフォース、Slowloris、高コストクエリ |
| Elevation of privilege（権限昇格） | 認可 | IDOR、サンドボックス脱出、コンテナブレイクアウト |
適切な粒度でDFDを描く
DFDに必要な4種類の要素：
- 外部エンティティ：ユーザー、サードパーティAPI。
- プロセス：サービス、関数。
- データストア：DB、S3、キュー。
- データフロー：要素間の矢印。
最も重要なのが信頼境界（trust boundary）です：信頼レベルが異なる領域の境界（インターネット ↔ Webティア、アプリ ↔ DB、テナントA ↔ テナントB）。信頼境界をまたぐ各矢印は、認証・検証・暗号化が必要な地点です。
DFDレベル1（1サービス + 直接的な依存関係）から始めましょう。漠然としたレベル0や、深すぎるレベル3には踏み込まないでください——時間を浪費するわりに意思決定に役立つ情報は増えません。
各要素にSTRIDEを適用する
実用的なコツ：DFD上の各要素に対してSTRIDEの6つの問いを投げかけます。すべてのセルに脅威を埋める必要はなく、合理的でなければスキップで構いません。下記の表に記録します：
| 要素 | 脅威 | 説明 | 緩和策 | オーナー | 重要度 |
| ----------------- | ---- | ------------------------------------------ | ----------------------- | -------- | ------ |
| ログインエンドポイント | S | アカウントへのブルートフォース | レート制限 + MFA | @team | High |
| ログインエンドポイント | I | エラーメッセージ経由のユーザー列挙 | 汎用エラーメッセージ | @team | Medium |
| アップロードサービス | T | ストレージ上のファイル置換レース | バージョニング + チェックサム | @team | Medium |
| 注文DB | E | /orders/{id} クエリでのIDOR | オーナー単位の認可チェック | @team | High |
リスクのスコアリング
一般的な2つの方法：
- CVSS v3.1/v4：業界標準で、特定の脆弱性に適しており、共有用の標準ベクトルを持つ。
- OWASP Risk Rating：シンプル（発生可能性 × 影響度）で、技術以外のステークホルダーにも説明しやすい。
組織内で1つの方法を統一し、ハンドブックに明記しましょう。チームごとに独自のスケールを作らせると、比較ができなくなります。
リスクレジスタは生きた資産
脅威モデリングは1回限りのドキュメントではありません。リスクレジスタには次が必要です：
- 各リスクに対するオーナー。
- 緩和策の期限、または受容理由。
- 四半期ごと、または大きなアーキテクチャ変更のタイミングでのレビュー。
- イシュートラッカーとの紐付け（緩和策が実際のチケットになっていること）。
LINDDUNやPASTAはいつ必要か？
デフォルトはSTRIDEで十分です。次のケースでは追加を検討します：
- LINDDUN：サービスが多くのPII/PHIを扱い、プライバシー観点の脅威モデリングが必要な場合（Linkability、Identifiability、Non-repudiation、Detectability、Disclosure、Unawareness、Non-compliance）。
- PASTA：ビジネスリスクと深く結びついた脅威モデリングが必要で、7段階の正式プロセスが適しているクリティカルシステム（銀行、ヘルスケア）向け。
結論
脅威モデリングは魔法ではありません。DFDレベル1、STRIDEチェックリスト、リスクレジスタを使う60分のセッションだけで、サービスは設計上の欠陥の大半を回避できます。定期的に繰り返し、オーナーを明確にし、ADRに紐付ける——これが脅威モデリングを年次イベントではなく技術的な習慣に変える方法です。