security-threat-model

Threat Model Source Code Repo

汎用的なチェックリストではなく、リポジトリまたはプロジェクトのパスに特化した、実行可能な 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

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