threat-patch

Threat Patch

セキュリティ上の検出事項を読み込み、構造化されたドキュメントとともに、最小限かつ的確なコードパッチを作成します。修正はコードに基づいており、各パッチは検出事項で特定されたファイルと関数を対象にします。出力には概要、検証手順、コード変更が含まれます。

適用する場面

• ユーザーが findings.json（threat-model の出力）を提供し、修正を求めている
• ユーザーが Codex のセキュリティ検出事項 CSV を提供し、修正を求めている
• ユーザーが THREAT-MODEL.md を持っており、特定されたリスクの修正を求めている
• ユーザーが特定の脆弱性について説明し、パッチを求めている
• セキュリティスキャナーの出力を確認し、実行可能な修正が必要である
• セキュリティ監査後に、検出事項をコード変更に反映する

入力ソース（優先順位順）

ソース	提供される内容	使用方法
findings.json（threat-model の出力）	データフロートレース、体系的なグループ分け、エクスプロイトチェーン、重大度評価を含む構造化された検出事項	そのまま読み込みます。トリアージとグループ分けが済んだ最も充実した入力です
Codex CSV	各検出事項のタイトル、説明、重大度、relevant_paths	scripts/parse-findings.sh <csv-path> を実行して構造化された出力を抽出します
THREAT-MODEL.md	人が読める形式の脅威モデル	Criticality Calibration セクションから検出事項を抽出します
インラインの説明	ユーザーが説明する特定の脆弱性	会話の文脈から解析します

findings.json が利用可能な場合は、これを優先入力として使用します。修正箇所を直接判断するのに役立つデータフロートレース（entry → chain → sink）と、個別のパッチより一元的な修正を促す体系的なグループ分けが含まれているためです。

ワークフローの概要

1. Ingest Findings   → Read findings.json / CSV / descriptions
2. Triage & Group    → Sort by severity, use systemic groupings if available
3. For each finding:
   a. Read Code      → Open relevant_paths, understand the pattern
   b. Confirm        → Verify issue is still present in HEAD
   c. Design Fix     → Determine minimal fix approach
   d. Implement      → Write the code changes
   e. Document       → Summary + Validation + Attack-path (if needed)
   f. Test           → Run relevant tests
4. Output            → Per-patch deliverable with summary and diff
5. Update State      → Mark patched findings in findings.json (if present)

使用方法

1. 各ステップの詳細なパッチ適用方法については、workflow を読みます
2. 修正を設計する際は、脆弱性の種類ごとの一般的なパターンについて fix patterns を読みます
3. パッチごとのドキュメントテンプレートについては、output format を読みます
4. 入力が findings.json の場合は、そのまま読み込みます。すでに構造化されています
5. 入力が Codex CSV の場合は、scripts/parse-findings.sh <csv-path> を実行して構造化された出力を抽出します

主な原則

• 差分を最小限にする：脆弱性を修正し、周辺のコードはリファクタリングしません。正しい修正のうち、最小のものが最善のパッチです
• 重複より一元化を優先する：複数のコードパスに同じ脆弱性のパターンがある場合は、各箇所を個別に修正するのではなく、共通のヘルパーに切り出します
• エラー経路を明示する：入力を拒否する場合は、サイレントな失敗や汎用エラーではなく、オペレーターに明確なフィードバックを返す具体的なエラー型を追加します
• 修正前に確認する：検出事項が HEAD にまだ存在することを必ず確認します。検出後にコードが移動またはリファクタリングされている可能性があります
• 編集前にユーザーの承認を得る：修正設計（変更するファイル、アプローチ）を提示し、ソースコードを変更する前に承認を待ちます。フックによって Edit/Write ツールの呼び出しにも追加の安全策を設けます
• 失敗も記録する：環境上の制約により修正をテストできない場合は、テストコマンドと制約を記録します

ガードレール

このスキルはソースコードを変更します。安全対策は次のとおりです。

• Edit と Write ツールの PreToolUse フックは、ファイルを変更するたびに確認を求めます
• ワークフローでは、修正設計と実装の間に 確認ゲートを設けます
• 元に戻す方法：コミットがない場合（デフォルト）は、git checkout -- <files> を使用して取り消します。コミットがある場合は、git revert を使用します

出力モード

コードパッチ — 修正を実装する場合：

• 確認した内容と修正の概要
• ビルド／テストコマンドを含むテストセクション
• 実際のコード変更

分析のみ — ユーザーの判断またはアーキテクチャの変更が必要な場合：

• 確認した内容の概要
• 検証チェックリスト
• 攻撃経路の分析（経路、可能性、影響、前提条件、対策、見落とし）

参考資料

ファイル	読むタイミング
references/workflow.md	作業を始める前 — 各修正フェーズの詳細な進め方
references/fix-patterns.md	修正を設計するとき — 脆弱性の種類ごとのパターン
references/output-format.md	ドキュメントを作成するとき — 2つの出力モード用のテンプレート