mcpField
D
differential-review

differential-review

github.com/waybarriosセキュリティ54651 回インストール2 日前に更新
リポジトリ

differential-review について

PR、コミット、差分をコードベースの基準と照合するセキュリティレビュー用スキルです。リスクに応じて分析の深さを調整し、根拠を示したMarkdownレポートを作成します。

主な機能

  1. 01リスクに基づく変更の分類
  2. 02Git履歴とblameの分析
  3. 03テストカバレッジの確認
  4. 04影響範囲の評価
  5. 05攻撃シナリオの検討
  6. 06Markdownレポートの生成

活用シーン

  1. 01セキュリティ関連PRのレビュー
  2. 02削除された検証やアクセス制御の追跡
  3. 03高リスク変更の影響評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/waybarrios/opencode-power-pack --skill differential-review

インストール後、Claude Code で/differential-reviewを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

adversarial.md
methodology.md
patterns.md
reporting.md

詳細

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

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

基本原則

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

よくある正当化（省略しないこと）

正当化誤りである理由必須の対応
「小さな PR だから、さっとレビューすればよい」Heartbleed は 2 行のコードが原因でした規模ではなくリスクで分類します
「このコードベースのことは分かっている」慣れは見落としにつながります明示的にベースラインのコンテキストを構築します
「Git 履歴を調べるのは時間がかかりすぎる」履歴から回帰を発見できますフェーズ 1 を省略しないでください
「影響範囲は明らかだ」推移的な呼び出し元を見落とします定量的に算出します
「テストがないのは自分の問題ではない」テスト不足はリスク評価を引き上げますレポートに記載し、重大度を引き上げます
「単なるリファクタリングで、セキュリティへの影響はない」リファクタリングは不変条件を壊すことがありますリスクが低いと証明されるまでは高リスクとして分析します
「口頭で説明すればよい」成果物がなければ指摘が失われます必ずレポートを作成します

クイックリファレンス

コードベースの規模に応じた戦略
コードベースの規模戦略アプローチ
SMALL（20 ファイル未満）DEEPすべての依存関係を読み、git blame を完全に確認します
MEDIUM（20～200 ファイル）FOCUSED1 ホップの依存関係と優先度の高いファイルを確認します
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)
│
├─ 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

品質チェックリスト

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

  • 変更されたすべてのファイルを分析した
  • 削除されたセキュリティ関連コードに対して git blame を実行した
  • HIGH リスクについて影響範囲を算出した
  • 具体的な攻撃シナリオを記載した（一般論ではない）
  • 指摘に特定の行番号とコミットを記載した
  • レポートファイルを生成した
  • 要約を添えてユーザーに通知した

インテグレーション

audit-context-building スキル：

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

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 から始めてください。

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

コメント

Markdown 対応