threat-model

脅威モデル

あらゆるコードベースを対象に、構造化された、根拠に基づくセキュリティ脅威モデルを作成します。表面的な列挙にとどまらず、実際のコードパスを通じて信頼できないデータを追跡し、根本原因ごとに検出事項をグループ化するとともに、個々の検出事項を組み合わせて深刻度の高い攻撃経路を構成します。

適用するタイミング

• ユーザーがコードベースの脅威モデル作成、セキュリティレビュー、攻撃対象領域のマッピングを依頼した場合
• セキュリティ上重要な機能（認証、暗号、ファイル I/O、ネットワーク、ネイティブブリッジ）の作業を開始するとき
• 新しいコードベースや大規模なアーキテクチャ変更がセキュリティに及ぼす影響を評価するとき
• PR や最近のコミットをレビューして、セキュリティ上のリグレッションを確認するとき（差分モード）
• セキュリティインシデント後に脅威の状況を再評価するとき

ワークフローの概要

Phase 0 (conditional): Diff Analysis — if git range provided, scope to changed code
Phase 1:  Codebase Survey        → Understand what the project is and does
Phase 2:  Component Mapping      → Identify components, data flows, and language bridges
Phase 3:  Asset Identification   → Determine what needs protecting
Phase 4:  Trust Boundaries       → Classify inputs by trust level, inventory entry points
Phase 5:  Data Flow Tracing      → Follow untrusted values from entry to sink ← key technique
Phase 6:  Attack Surface Enum    → Document surfaces with traced evidence
Phase 7:  Pattern Clustering     → Group 3+ similar findings by root cause
Phase 8:  Exploit Chains         → Combine findings into multi-step attack paths
Phase 9:  Calibration            → Rate with chain-adjusted and systemic severity
Phase 10: Output                 → Write structured THREAT-MODEL.md

使用方法

1. 各フェーズの詳細な手法について、手法を読みます
2. ドキュメントの構成（6 セクション）について、出力形式を読みます
3. 技術固有のパターンについて、攻撃パターンを参照します
4. scripts/trace-data-flows.sh <project-root> を実行し、エントリーポイントとシンクを一覧化します
5. 必要に応じて scripts/scan-patterns.sh <project-root> を実行し、セキュリティ関連のコードパターンを調べます

分析手法

これらの手法は、このスキルの中核的な価値です。一般知識だけではモデルが生成できない検出事項を生み出す分析方法が組み込まれています。

手法	読むタイミング	追加される内容
データフローの追跡	フェーズ 5 — 常に	実際のコードを通じて、エントリーからシンクまで信頼できない入力を追跡します。理論上のリスクではなく、根拠に基づく検出事項を作成します
パターンのクラスタリング	フェーズ 7 — 列挙後	関連する検出事項を根本原因ごとにグループ化します。個別のパッチではなく、システム全体に適用できる修正を推奨します
攻撃チェーン	フェーズ 8 — クラスタリング後	検出事項を組み合わせて、最終的な影響度で評価した複数ステップの攻撃経路を構成します
ブリッジ分析	フェーズ 6 — FFI／ブリッジが見つかったとき	言語間の境界（Swift↔C、Rust↔C、Rails↔NGINX）を体系的に確認するチェックリストです
差分分析	フェーズ 0 — 段階的なレビューの場合	分析対象を変更されたコードに絞り、リグレッションを特定します

主な原則

• 推測より根拠：すべての検出事項に、信頼できない入力がどのように脆弱な操作へ到達するかを示すデータフローの追跡結果を含めます。「XSS が起きる可能性がある」は推測です。「RFC の Markdown → marked.parse() → 917 行目の innerHTML（サニタイザーなし）」は根拠です。
• 個別の問題よりシステム全体：3 件以上の検出事項に根本原因が共通する場合、システム全体に関わる検出事項は個々の検出事項より重要です。症状ではなく根本原因を修正します。
• 単独の検出事項より攻撃チェーン：組み合わされた攻撃経路を、最終的な影響度で評価します。中程度の検出事項が 3 件連鎖して重大な影響につながる場合、それは重大な検出事項です。
• 既存の緩和策も重要：不足しているものだけでなく、すでに保護されているものも記録します。
• 状況に応じた評価：深刻度はデプロイ環境によって異なります。必ず適用範囲に関する注記を含めます。

出力

2 つのファイルを作成します（config.json で設定可能）。

• findings.json — 構造化された機械可読な検出事項です。情報源として扱います。threat-patch が自動修正に使用します。実行ごとに検出事項の状態（open → patched → verified → closed）を追跡します。
• THREAT-MODEL.md — findings.json から生成される、人が読みやすい形式です。6 つのセクションで構成されます：概要、信頼境界、攻撃対象領域、システム上の検出事項、攻撃チェーン、重大度の調整。

パイプラインとの統合

threat-model → findings.json → threat-patch (consumes findings, generates fixes)
     ↑                                          ↓
     └── threat-model --diff (re-analyzes, updates finding status) ←── git commits

以前の実行で作成された findings.json が存在する場合、このスキルはそれを読み込み、次の処理を行います。

• 未解決の検出事項と修正済みの検出事項を追跡する
• 以前の評価を基準に深刻度を調整する
• リグレッションを検出する（修正済みの検出事項が再発した場合）

2 つのモード

モード	トリガー	実行内容
フル分析	「このコードベースの脅威モデルを作成して」	コードベース全体を分析し、新しい findings.json と THREAT-MODEL.md を生成します
差分分析	「前回のレビュー以降に何が変わった？」／git の範囲が指定された場合	変更されたコードを対象にし、新規・解決済み・再発した検出結果を含むよう既存の findings.json を更新します

差分モードは、継続中のプロジェクトで日常的に使用します。フルモードは一度（または定期的に）実行します。

参考資料

ファイル	読むタイミング
references/methodology.md	開始前 — 10 フェーズのワークフロー
references/output-format.md	出力の作成時 — 6 セクションのテンプレート
references/findings-schema.md	findings.json の作成時 — 構造化スキーマ
references/attack-patterns.md	対象領域の列挙時 — テクノロジーのパターン
references/techniques/	特定のフェーズ中 — 分析手法