openai-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

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

使用する場面

使用しない場面