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 という名前のファイルに書き出す（リポジトリルートのベース名を使用する。サブパスのモデリングを求められた場合は対象のディレクトリ名を使用する）。

リスクの優先順位付けのガイダンス（例示であり、網羅的ではない）

• 高: 認証前の RCE、認証バイパス、テナント間アクセス、機密データの流出、鍵またはトークンの窃取、モデルまたは設定の整合性の侵害、サンドボックスからの脱出。
• 中: 重要なコンポーネントへの標的型 DoS、部分的なデータ露出、測定可能な影響を伴うレート制限のバイパス、検知に影響するログ/メトリクスの汚染。
• 低: 機密性の低い情報の漏えい、対策が容易なノイズの多い DoS、発生の前提条件がまれな問題。

参考資料

• 出力の規約と完全なプロンプトテンプレート: references/prompt-template.md
• 任意のコントロール/資産一覧: references/security-controls-and-assets.md

必要な参考ファイルのみを読み込むこと。最終的な結果は簡潔かつ根拠に基づき、レビューしやすい内容にすること。