security-threat-model

ソースコードリポジトリの脅威モデリング

リポジトリまたはプロジェクトパスに固有の、実行可能な AppSec 水準の脅威モデルを作成してください。一般的なチェックリストではなく、対象に即したものにします。アーキテクチャに関する主張はすべてリポジトリ内の根拠に紐づけ、前提条件は明示してください。一般的なチェックリストよりも、現実的な攻撃者の目的と具体的な影響を優先します。

クイックスタート

1. 入力を収集する（または推定する）:

• リポジトリのルートパスと対象範囲のパス。
• 想定される用途、デプロイモデル、インターネットへの公開範囲、認証に関する想定（分かっている場合）。
• 既存のリポジトリ概要またはアーキテクチャ仕様があればそれ。
• references/prompt-template.md のプロンプトを使用して、リポジトリ概要を生成します。
• references/prompt-template.md に定められた出力仕様に従ってください。可能な限りそのまま使用します。

ワークフロー

1) 対象範囲を定め、システムモデルを抽出する

• リポジトリ概要から、主要なコンポーネント、データストア、外部連携を特定します。
• システムの実行方法（サーバー、CLI、ライブラリ、ワーカー）とそのエントリポイントを特定します。
• 実行時の動作を、CI/ビルド/開発ツールおよびテストやサンプルから分離します。
• 対象範囲の場所をそれらのコンポーネントに対応付け、対象外の項目は明示的に除外します。
• 根拠のないコンポーネント、フロー、統制策を主張しないでください。

2) 境界、資産、エントリポイントを導出する

• 信頼境界を、コンポーネント間の具体的な接点として列挙し、プロトコル、認証、暗号化、検証、レート制限を併記します。
• リスクを左右する資産を列挙します（データ、認証情報、モデル、設定、計算リソース、監査ログ）。
• エントリポイント（エンドポイント、アップロード箇所、パーサー/デコーダー、ジョブのトリガー、管理ツール、ログやエラーの出力先）を特定します。

3) 資産と攻撃者の能力を見積もる

• リスクを左右する資産を列挙します（認証情報、PII、整合性が重要な状態、可用性が重要なコンポーネント、ビルド成果物）。
• 公開範囲と想定される用途に基づき、現実的な攻撃者の能力を記述します。
• 重大度の過大評価を避けるため、攻撃者が持たない能力も明示的に記載します。

4) 脅威を悪用経路として列挙する

• 資産と境界に対応する攻撃者の目的（情報流出、権限昇格、整合性の侵害、サービス拒否）を優先します。
• 各脅威を分類し、影響を受ける資産に結び付けます。
• 脅威の数は少なく、質の高いものに絞ります。

5) 明示的な発生可能性と影響の根拠に基づいて優先度を決める

• 発生可能性と影響を定性的に（低/中/高）評価し、短い理由を添えます。
• 発生可能性 × 影響を用い、既存の統制策を考慮して総合優先度（重大/高/中/低）を設定します。
• 順位付けに最も影響する前提条件を明示します。

6) サービスの文脈と前提条件をユーザーと確認する

• 脅威の順位付けや対象範囲に大きく影響する主要な前提条件を要約し、ユーザーに確認または修正を求めます。
• 不足している文脈を解消するため、1～3 個の的を絞った質問をします（サービスの所有者と環境、規模/ユーザー数、デプロイモデル、認証/認可、インターネット公開、データの機微性、マルチテナンシー）。
• 最終レポートを作成する前に、ユーザーのフィードバックを待ってください。
• ユーザーが回答を拒否した、または回答できない場合は、残存する前提条件と、それらが優先度に与える影響を明記します。

7) 緩和策を推奨し、重点的に見るべきパスを示す

• 既存の緩和策（根拠付き）と、推奨する緩和策を区別します。
• 緩和策を具体的な場所（コンポーネント、境界、エントリポイント）と統制の種類（認可チェック、入力検証、スキーマ強制、サンドボックス化、レート制限、シークレットの分離、監査ログ）に結び付けます。
• 一般的な助言よりも、具体的な実装のヒントを優先します（例：「アップロードペイロードはゲートウェイでスキーマを強制する」であり、「入力を検証する」ではない）。
• 推奨事項は検証済みのユーザーの文脈に基づかせます。未解決の前提条件が残る場合は、推奨事項に条件を付記します。

8) 最終確定の前に品質を確認する

• 発見したすべてのエントリーポイントが網羅されていることを確認します。
• 各信頼境界が脅威に反映されていることを確認します。
• 実行時と CI／開発時が区別されていることを確認します。
• ユーザーからの確認事項（または明示的な未回答）が反映されていることを確認します。
• 前提と未解決の質問が明記されていることを確認します。
• バージョン管理、レビュー頻度、更新のきっかけ、担当者を含む保守計画が成果物に含まれていることを確認します。
• レポートの形式が、プロンプトテンプレートで定義されている必須の出力形式 references/prompt-template.md にできるだけ準拠していることを確認します。
• 最終的な Markdown を <repo-or-dir-name>-threat-model.md というファイル名で書き込みます（リポジトリルートのベース名、またはサブパスのモデリングを依頼された場合は対象ディレクトリのベース名を使用します）。

よくある落とし穴

以下は、脅威モデリングでよく見られる失敗です。これらを避けることで、実用的で信頼性の高い脅威モデルになります。

1. 脅威モデルが抽象的すぎる（具体的な攻撃経路がない）

問題： 脅威の説明が、実際のコード、設定、デプロイアーキテクチャに結び付いた具体的な悪用経路ではなく、一般的なセキュリティチェックリスト項目のようになっています。

悪い例： 「攻撃者が機密データへの不正アクセスを取得する」
良い例： 「ファイルシステムの権限設定により、プロセスが誰でも読み取れる状態でデプロイされている場合、認証されていない攻撃者が config.json から API キーを窃取し、AWS への権限昇格を可能にする」

回避方法： 脅威ごとに、次の点を確認します。どのコンポーネントか？ どのエントリーポイントか？ 攻撃者はどの具体的なコードパスまたは境界を悪用するのか？ 答えられない場合は、リポジトリに戻り、具体的な根拠（コード、設定テンプレート、デプロイに関するドキュメント）を見つけます。

2. 脅威アクターと動機が欠けている（敵対者の定義が一般的）

問題： 脅威モデルに脅威は列挙されているものの、攻撃者が誰で、何を狙い、どのようなリソースを持つかが定義されていません。そのため、可能性を評価できず、優先順位付けが意味をなしません。

悪い例： 「攻撃者がシステムを侵害する」
良い例： 「社内 API へのアクセス権を持つ不満を抱えた従業員が、PII を窃取し、ダークネット市場で売却する。可能性：中（アクセスできる従業員は限られており、監査ログも存在するが、リアルタイムでは監視されていない）」

回避方法： システムにとって現実的な攻撃者のプロファイルを3～4種類定義します。

• 外部の未認証の攻撃者
• 認証済みユーザー（社内ユーザー、顧客、またはパートナー）
• 特定の権限レベルを持つ悪意ある内部関係者
• サプライチェーンの関係者（依存関係やインフラストラクチャのプロバイダー）

脅威ごとに、どのアクターが、なぜそれを悪用できるのかを明記します。

3. 優先順位付けがない（すべてが「重大」）

問題： 理論上の影響が深刻であるという理由で、すべての脅威が「重大」とされています。その結果、脅威モデルは役に立たなくなります。何も優先されないため、チームは注力先を決められず、「脅威モデルはただの恐怖をあおる手段だ」という不信感が生じます。

悪い例： 25件すべての脅威を「重大」とする
良い例： 「依存関係を介したサプライチェーンの RCE：重大（悪用前にパッチが適用される可能性は高いが、影響は壊滅的）。弱いパスワードに対するユーザーの総当たり攻撃：中（レート制限と 2FA があれば可能性は低いが、成功した場合の完全性への影響は大きい）。」

回避方法： 可能性 × 影響度のグリッドを使用します。既存の制御を考慮して、最終的な優先度を調整します。次の点を確認します。

• 悪用はどの程度困難か？（コードの複雑さ、必要な前提条件、攻撃者のリソース）
• 攻撃者が試みる可能性はどの程度か？（明白な攻撃経路か？ 継続的なアクセスや内部情報が必要か？）
• すでにリスクを軽減する制御があるか？（レート制限、暗号化、監査ログ）

優先度が、まだ確認されていないユーザーの前提に左右される場合は、「条件付き高」とします。

4. 実装の詳細がない緩和策（曖昧な推奨事項）

問題： 推奨事項が、具体的なコードの場所や制御メカニズムではなく、「認証を追加する」「データを暗号化する」「ロギングを有効にする」といった、セキュリティに関する決まり文句になっています。チームは何から始めればよいかわかりません。

悪い例：「インジェクション攻撃を防ぐために入力検証を追加する」
良い例：「ドキュメントパーサーに渡す前に、/api/upload エンドポイントのハンドラー（src/handlers/upload.ts:42）で JSON スキーマ検証を強制します。Zod または Ajv を使用して、10MB を超えるペイロードや許可されていない MIME タイプを拒否します。」

回避方法： すべての緩和策について、次の点を明示します。

1. コンポーネントまたはコードの場所（ファイル、関数、境界）を示す
2. 制御の種類を指定する：スキーマの強制、レート制限、サンドボックス化、シークレットのローテーション、監査ログ、署名検証など
3. 緩和対象の脅威と結び付ける
4. 具体的な場所が見つからない場合は、ユーザーにアーキテクチャを明確にするよう尋ねる

5. 脅威モデルのメンテナンス計画がない（一度きりの作業）

問題： 脅威モデルがある時点のスナップショットとして納品されますが、システムは進化します。新しいエントリーポイントが追加され、依存関係がアップグレードされ、チームも変わります。数週間でモデルは古くなり、信頼性を失います。

悪い例：「これが脅威モデルです。あとは頑張ってください！」
良い例：「脅威モデルは Git でバージョン管理します。レビューのスケジュール：主要なデプロイのたび、四半期ごとのチームレビュー、新しい依存関係や統合の追加時。更新を開始するためのチェックリスト：新しいユーザーロール、新しい API、新しいデータソース、インフラストラクチャの変更。」

回避方法： 最終確定する前に、次の点について合意します。

• バージョン管理： 脅威モデルは Git で管理しますか？ アーキテクチャの変更と関連付けられていますか？
• レビューの頻度： 四半期ごとですか？ リリースごとですか？ インシデント発生時ですか？
• 更新のトリガー： どのようなコードやデプロイの変更が、脅威モデルの更新を必要としますか？
• 担当者： 脅威モデルの責任者は誰ですか？ 誰が更新しますか？

これらの点を成果物に記載します。

6. STRIDE／PASTA 固有の失敗モード

STRIDE（手法として使用する場合）

• なりすまし： 脅威モデルに「攻撃者が身元を偽装する」と記載されていても、どの認証メカニズムを、どのように回避できるのか（暗号の弱さ、不適切なトークン検証、リプレイ攻撃）が明示されていない
• 改ざん： 転送中のデータは特定していても、具体的な境界と転送方式が記載されていない（API は TLS を使用していますか？ オフラインデータにはメッセージ署名がありますか？）
• 否認： 監査ログが存在する場合の可能性を過大評価し、ログの保持期間や監視範囲を考慮していない
• 情報漏えい： 「保存データが暗号化されていない」（よくあること）と「攻撃者がデータを持ち出す」（アクセス制御とネットワークへの露出状況による）を混同している
• サービス拒否： すべての DoS を同じように扱っている。プロセス内のクラッシュと外部からのレート制限の枯渇は異なるため、コンポーネントごとに分ける
• 権限昇格： 最初の侵入経路を見落としがち。「そもそも、攻撃者はどのようにしてこのコンポーネントにたどり着くのか？」と尋ねる

PASTA（手法として使用する場合）

• 資産の列挙： 技術的な資産は列挙していても、論理的な資産（データパイプライン、評判、可用性）を見落としている。「このシステムで、ビジネスが最も重視するものは何か？」と尋ねる
• 脅威分析： アプリケーション固有の不正利用経路ではなく、CVE の文献調査になりがちです。このシステムに焦点を当てます。
• 脆弱性分析： 「コードに SQL インジェクションのパターンがある」と「攻撃者がそこに到達できる」を混同している。実際にどのエントリーポイントからアクセスできるのかを尋ねる
• リスク分析： この状況における可能性を分析せず、重大度評価にテンプレートを使用している。内部管理ツール上の RCE は、インターネットに公開された API 上の同じ RCE よりもリスクが低い

リスク優先度付けのガイダンス（例示であり、網羅的ではありません）

• 高：認証前の RCE、認証の回避、テナント間アクセス、機密データの流出、キーやトークンの窃取、モデルや設定の完全性の侵害、サンドボックスからの脱出。
• 中：重要なコンポーネントを標的とする DoS、一部データの漏えい、測定可能な影響を伴うレート制限の回避、検知に影響するログ／メトリクスの汚染。
• 低：機密性の低い情報の漏えい、容易に緩和できるノイズの多い DoS、発生しそうにない前提条件を必要とする問題。

AI/ML システムの脅威モデリング

AI/ML コンポーネント（LLM、埋め込み、RAG パイプライン）を含むシステムでは、次の脅威カテゴリを追加します。

AI 固有の脅威

脅威	説明	典型的な影響
プロンプトインジェクション	ユーザー入力内の悪意あるコンテンツがシステム指示を上書きします	権限昇格、データ流出
間接プロンプトインジェクション	外部データ（ドキュメント、ウェブページ）内の悪意あるコンテンツがエージェントのアクションを乗っ取ります	不正なツール呼び出し、データ窃取
学習データのポイズニング	ファインチューニングデータ内の敵対的サンプルがバックドアを埋め込みます	モデルの動作の操作
モデルの流出	モデルの重みの窃取、または独自モデルの蒸留	知的財産の窃取、安全対策の回避
埋め込みの反転	ベクターデータベースに保存された埋め込みベクトルから PII を再構築します	プライバシー侵害
RAG の操作	ナレッジベースに敵対的なドキュメントを注入します	誤情報の拡散
ジェイルブレイク	敵対的なプロンプトによって安全フィルターを回避します	ポリシー違反、有害な出力
コンテキストウィンドウ攻撃	コンテキストを大量に送り込み、安全指示を押し出します	安全対策の回避

AI 脅威モデルのチェックリスト

• システムプロンプトはユーザーによる上書きから保護されていますか？
• 外部データ（ドキュメント、ウェブ検索）はコンテキストに含める前にサニタイズされていますか？
• エージェントのツール呼び出しはユーザーの権限に照らして認可されていますか？
• ベクターデータベースへのアクセスは制御されていますか（テナント間アクセスが発生しないこと）？
• モデルの出力はアクションの実行前（例：コード実行）に検証されていますか？
• LLM API キーはユーザーごとにスコープが設定され、レート制限されていますか？
• プロンプトインジェクションの試みを検知するためのログ記録が行われていますか？

サプライチェーンの脅威モデリング

最新のアプリケーションはサードパーティパッケージに大きく依存しています。次の項目を含めてください。

脅威	例	緩和策
タイポスクワッティング	requests の代わりに reqursts を使う	ロックファイル、パッケージ署名
依存関係の混同	内部パッケージ名が公開レジストリで乗っ取られる	スコープ付きパッケージ、レジストリ設定
メンテナーの侵害	event-stream npm インシデント	SBOM + CVE の監視、VCS の完全性
ビルドシステムの侵害	SolarWinds 型	再現可能なビルド、SLSA Level 3
CI/CD の乗っ取り	Actions ワークフローのインジェクション	Actions はタグではなくコミットハッシュで固定する

クラウドネイティブなデプロイの脅威

コンテナ化／Kubernetes／サーバーレスのデプロイでは、次の項目を考慮します。

• コンテナからの脱出：特権コンテナ、またはホストパスのマウント
• メタデータサービスへの SSRF：AWS IMDSv1 により、コンテナ内から認証情報を窃取される可能性があります
• Kubernetes RBAC の過剰な権限：クラスタ全体へのアクセス権を持つ ServiceAccount トークン
• 環境変数内のシークレット：コンテナの検査やログから閲覧可能
• サービスメッシュを介したラテラルムーブメント：暗号化されていない東西トラフィック

参考資料

• 出力仕様と完全なプロンプトテンプレート：references/prompt-template.md
• オプションのコントロール／アセット一覧：references/security-controls-and-assets.md
• OWASP Top 10：https://owasp.org/Top10/
• OWASP LLM Top 10：https://owasp.org/www-project-top-10-for-large-language-model-applications/
• MITRE ATT&CK：https://attack.mitre.org/
• STRIDE 手法：Microsoft SDL Threat Modeling

必要な参照ファイルのみを読み込んでください。最終結果は簡潔で、根拠が明確で、レビューしやすいものにしてください。