differential-review

差异安全审查

针对 PR、提交和差异进行以安全为重点的代码审查。

核心原则

1. 风险优先：重点关注身份验证、加密、价值转移、外部调用
2. 基于证据：每项发现都有 Git 历史、行号和攻击场景作为依据
3. 自适应：根据代码库规模（SMALL/MEDIUM/LARGE）调整
4. 诚实：明确说明覆盖范围限制和置信度
5. 以输出为导向：始终生成完整的 Markdown 报告文件

---

合理化借口（切勿跳过）

借口	错误所在	必须采取的行动
“PR 很小，快速审查一下就行”	Heartbleed 只涉及 2 行代码	按风险分类，而不是按规模分类
“我了解这个代码库”	熟悉容易导致盲点	明确构建基线背景
“查 Git 历史太耗时”	历史记录能揭示回归问题	绝不跳过阶段 1
“影响范围一目了然”	你会漏掉间接调用方	定量计算
“没有测试不关我的事”	缺少测试会提高风险评级	在报告中标记并提高严重程度
“只是重构，不影响安全”	重构会破坏不变量	证明风险较低之前，按高风险分析
“我口头解释就行”	没有记录就会丢失发现	始终编写报告

---

快速参考

代码库规模策略

代码库规模	策略	方法
SMALL（<20 个文件）	深入	阅读所有依赖项，完整执行 Git blame
MEDIUM（20-200 个文件）	聚焦	检查 1 跳依赖项和优先级文件
LARGE（200+ 个文件）	精准	仅检查关键路径

风险等级触发条件

风险等级	触发条件
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 skill：

• 分析前：构建基线背景
• 阶段 4：深入分析 HIGH RISK 变更的背景

issue-writer skill：

• 将发现事项转换为正式审计报告
• 命令：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

---

不适用此技能的情况

• 全新项目代码（没有可供比较的基线）
• 仅修改文档（不影响安全）
• 格式调整／lint（外观变更）
• 用户明确只要求快速摘要（用户愿意承担风险）

此类情况请改用标准代码审查。

---

危险信号（立即停止并调查）

需要立即升级处理的触发条件：

• 从“security”、“CVE”或“fix”提交中移除了代码
• 移除了访问控制修饰符（onlyOwner、internal → external）
• 移除了验证且未作替代
• 新增外部调用但未进行检查
• 影响范围大（50+ 个调用方），且变更风险为 HIGH

即使是快速初筛，出现这些模式也必须进行对抗性分析。

---

获得最佳效果的提示

建议：

• 从对已移除代码执行 Git blame 开始
• 尽早计算影响范围，以便确定优先级
• 生成具体的攻击场景
• 引用具体行号和提交
• 诚实说明覆盖范围的限制
• 始终生成输出文件

避免：

• 跳过 Git 历史分析
• 在没有证据的情况下给出笼统的发现
• 时间有限时声称已完成全面分析
• 忘记检查测试覆盖率
• 漏掉影响范围大的变更
• 只在聊天中输出报告（必须生成文件）

---

支持文档

• methodology.md - 各阶段的详细工作流（阶段 0-4）
• adversarial.md - 攻击者建模与漏洞利用场景（阶段 5）
• reporting.md - 报告结构与格式（阶段 6）
• patterns.md - 常见漏洞模式参考

---

首次使用者： 请从 methodology.md 开始，了解完整工作流。

有经验的使用者： 使用本页的快速参考和决策树，直接查找所需内容。