differential-review

差分セキュリティレビュー

PR、コミット、差分を対象とした、セキュリティ重視のコードレビューです。

基本原則

1. リスク優先：認証、暗号処理、価値の移転、外部呼び出しに注目します
2. 証拠に基づく：すべての指摘を、Git の履歴、行番号、攻撃シナリオで裏付けます
3. 適応的：コードベースの規模に合わせて対応します（SMALL／MEDIUM／LARGE）
4. 誠実：分析範囲の限界と確信度を明示します
5. 成果物を重視：必ず包括的な Markdown レポートファイルを生成します

---

よくある正当化（省略しないでください）

正当化	それが誤りである理由	必須の対応
「小さな PR だから、すぐにレビューできる」	Heartbleed の修正箇所は 2 行でした	規模ではなくリスクで分類します
「このコードベースのことは把握している」	慣れは見落としを生みます	明示的にベースラインのコンテキストを構築します
「Git の履歴を見るには時間がかかりすぎる」	履歴からリグレッションが見つかります	フェーズ 1 を決して省略しません
「影響範囲は明らかだ」	間接的な呼び出し元を見落とします	定量的に算出します
「テストがないのは自分の問題ではない」	テストの欠如はリスク評価を引き上げます	レポートに記載し、深刻度を引き上げます
「単なるリファクタリングで、セキュリティへの影響はない」	リファクタリングは不変条件を壊す可能性があります	低リスクと判明するまでは、高リスクとして分析します
「口頭で説明する」	成果物がなければ、指摘は失われます	必ずレポートを作成します

---

クイックリファレンス

コードベースの規模に応じた戦略

コードベースの規模	戦略	アプローチ
SMALL（20 ファイル未満）	DEEP	すべての依存関係を読み、Git blame を完全に確認します
MEDIUM（20～200 ファイル）	FOCUSED	1 ホップの依存関係と優先度の高いファイルを確認します
LARGE（200 ファイル以上）	SURGICAL	重要な経路のみを確認します

リスクレベルの判断基準

リスクレベル	判断基準
HIGH	認証、暗号処理、外部呼び出し、価値の移転、検証の削除
MEDIUM	ビジネスロジック、状態の変更、新しいパブリック API
LOW	コメント、テスト、UI、ログ記録

---

ワークフローの概要

Pre-Analysis → Phase 0: Triage → Phase 1: Code Analysis → Phase 2: Test Coverage
    ↓              ↓                    ↓                        ↓
Phase 3: Blast Radius → Phase 4: Deep Context → Phase 5: Adversarial → Phase 6: Report

---

判断ツリー

レビューを開始しますか？

├─ Need detailed phase-by-phase methodology?
│  └─ Read: methodology.md
│     (Pre-Analysis + Phases 0-4: triage, code analysis, test coverage, blast radius)
│
├─ Analyzing HIGH RISK change?
│  ├─ Read: adversarial.md
│  │  (Phase 5: Attacker modeling, exploit scenarios, exploitability rating)
│  └─ Or delegate to: differential-review:adversarial-modeler agent
│     (Autonomous attacker modeling with concrete exploit scenarios)
│
├─ Writing the final report?
│  └─ Read: reporting.md
│     (Phase 6: Report structure, templates, formatting guidelines)
│
├─ Looking for specific vulnerability patterns?
│  └─ Read: patterns.md
│     (Regressions, reentrancy, access control, overflow, etc.)
│
└─ Quick triage only?
   └─ Use Quick Reference above, skip detailed docs

---

エージェント

differential-review:adversarial-modeler — 攻撃者の視点をモデル化し、リスクの高いコード変更に対するエクスプロイトシナリオを作成します。5 段階の敵対的分析手法（攻撃者モデル、攻撃ベクトル、悪用可能性の評価、エクスプロイトシナリオ、ベースラインとの相互参照）に従い、構造化された脆弱性レポートを作成します。高リスクの変更についてフェーズ 5 の分析が必要な場合は、このエージェントに委任し、完全な名前空間付きの名前を subagent_type として渡してください。adversarial-modeler のみを指定すると登録されていないため、実行時にディスパッチが失敗します。

---

品質チェックリスト

提出前に確認してください。

• 変更されたファイルをすべて分析した
• 削除されたセキュリティコードに対して Git blame を確認した
• 高リスクの場合、影響範囲を算出した
• 攻撃シナリオが具体的である（一般論ではない）
• 指摘に具体的な行番号とコミットを記載した
• レポートファイルを生成した
• ユーザーに概要を伝えた

---

連携

audit-context-building スキル：

• 事前分析：ベースラインのコンテキストを構築します
• フェーズ 4：高リスクの変更について、詳細なコンテキストを確認します

issue-writer スキル：

• 指摘を正式な監査レポートにまとめます
• コマンド：issue-writer --input DIFFERENTIAL_REVIEW_REPORT.md --format audit-report

---

使用例

クイックトリアージ（小規模な PR）

Input: 5 file PR, 2 HIGH RISK files
Strategy: Use Quick Reference
1. Classify risk level per file (2 HIGH, 3 LOW)
2. Focus on 2 HIGH files only
3. Git blame removed code
4. Generate minimal report
Time: ~30 minutes

標準レビュー（中規模のコードベース）

Input: 80 files, 12 HIGH RISK changes
Strategy: FOCUSED (see methodology.md)
1. Full workflow on HIGH RISK files
2. Surface scan on MEDIUM
3. Skip LOW risk files
4. Complete report with all sections
Time: ~3-4 hours

詳細監査（大規模な重要変更）

Input: 450 files, auth system rewrite
Strategy: SURGICAL + audit-context-building
1. Baseline context with audit-context-building
2. Deep analysis on auth changes only
3. Blast radius analysis
4. Adversarial modeling
5. Comprehensive report
Time: ~6-8 hours

---

このスキルを使用しない場合

• グリーンフィールドのコード（比較対象となるベースラインがない）
• ドキュメントのみの変更（セキュリティへの影響がない）
• フォーマット／リンティング（見た目上の変更）
• ユーザーが簡潔な概要のみを明示的に求めている場合（リスクを許容している）

このような場合は、標準的なコードレビューを使用してください。

---

危険信号（中断して調査）

直ちにエスカレーションすべき判断基準：

• 「security」、「CVE」、「fix」を含むコミットでコードが削除されている
• アクセス制御の修飾子が削除されている（onlyOwner、internal → external）
• 検証が代替手段なしに削除されている
• チェックを行わずに外部呼び出しが追加されている
• 影響範囲が広い（呼び出し元が 50 以上）うえに、高リスクの変更である

このようなパターンには、クイックトリアージでも敵対的分析が必要です。

---

最良の結果を得るためのヒント

実施すること：

• 削除されたコードについては、まず git blame を確認します
• 影響範囲を早めに算出して、優先順位を決めます
• 具体的な攻撃シナリオを作成します
• 具体的な行番号とコミットを参照します
• カバレッジの限界について正直に伝えます
• 必ず出力ファイルを生成します

実施しないこと：

• git 履歴の分析を省略します
• 根拠のない一般的な指摘を行います
• 時間が限られているのに、分析を完全に行ったと主張します
• テストカバレッジの確認を忘れます
• 影響範囲の大きな変更を見落とします
• レポートをチャットにのみ出力します（ファイルが必須です）

---

関連ドキュメント

• methodology.md - フェーズごとの詳細なワークフロー（フェーズ 0～4）
• adversarial.md - 攻撃者のモデル化とエクスプロイトシナリオ（フェーズ 5）
• reporting.md - レポートの構成と書式（フェーズ 6）
• patterns.md - よくある脆弱性パターンのリファレンス

---

初めて利用する方へ： まず methodology.md を読み、ワークフロー全体を理解してください。

経験豊富な方へ： このページのクイックリファレンスと意思決定ツリーを使って、必要な情報に直接移動してください。