fix-review Skill 多维度简评

综合评分:8.7 / 10 ⭐⭐⭐⭐⭐ 类别:安全审计 / 修复验证 仓库:trailofbits/skills 维护者:Trail of Bits 引用:trailofbits/skills README · tencent 极道详解

一、核心定位与价值

fix-review 是 Trail of Bits skills 中**“审计闭环”**的关键一环——修一个 bug,引三个新 bug 是安全开发最常见的灾难。fix-review 强制验证:

1. 原漏洞真的被修了(不是表面修复)
2. 没引入新漏洞(没破坏其他功能)
3. 新代码符合安全规范

关键洞见:“修一个 bug,引三个新 bug” 的风险极大降低。

适用场景

• 提交任何安全相关 PR 后
• 修复 CVE 后
• 修复 supply chain 漏洞后
• 修复 RLS / 权限问题后
• 任何”高风险”修复后

不适用场景

• 功能 bug 修复(用 superpowers systematic-debugging)
• 纯前端样式调整
• 一次性脚本

二、核心工作流

2.1 三步验证

[1] 验证原漏洞
  - 修复前: 漏洞存在 (POC)
  - 修复后: 漏洞消失 (POC 不再触发)
  - 测试: 回归测试覆盖

[2] 验证新代码
  - 静态分析(semgrep / codeql)对 diff 跑
  - 是否有新的反模式引入
  - 是否修复了 root cause,而非 symptom

[3] 验证其他功能
  - 全量测试跑过
  - 没破坏其他功能
  - 性能没退化

2.2 工具配合

三、完整流程详解

3.1 准备阶段

# 1. 获取 PR / 修复 diff
git diff main..feature-fix
git log main..feature-fix

# 2. 收集原始漏洞信息
# - CVE 编号
# - POC 链接
# - 严重度评级
# - 受影响版本

3.2 Step 1:验证原漏洞

# 1. 用原 POC 复现(修复前)
# 假设漏洞: SQL 注入 in /api/users
import requests
r = requests.get("https://target.com/api/users?id=1' OR 1=1--")
assert "all users" in r.text  # 漏洞存在

# 2. 应用修复后,再跑 POC
# 期望: POC 不再触发

3.3 Step 2:静态分析 diff

# 用 Semgrep 扫 diff
semgrep --config=p/security-audit $(git diff --name-only main..feature-fix)

# 用 CodeQL 扫
codeql database create fix-db --language=python --source-root=.
codeql database analyze fix-db codeql/python-queries:codeql-suites/python-security-extended.qls

关注:

• 新引入的危险 API(eval / exec / dangerous deserialize)
• 新引入的反模式
• 没修复 root cause(只补 surface)

3.4 Step 3:回归测试

# 全量测试
pytest --tb=short

# 性能测试
wrk -t4 -c100 -d30s https://target.com/api/users

# 安全测试
# 用 OWASP ZAP / Burp Suite 跑 baseline

四、5 大修复反模式

4.1 表面修复(Surface Fix)

# ❌ BAD: 加 try-catch 吞异常
try:
    result = dangerous_call(user_input)
except:
    return None  # ❌ 漏洞还在,只是不再 crash

# ✅ GOOD: 真正的修复
if not is_valid_input(user_input):
    return error("Invalid input")
result = safe_call(user_input)

4.2 拒绝服务式修复(DoS the Fix)

# ❌ BAD: 加个 if 就完事
if user_input in WHITELIST:
    process(user_input)
# 但没考虑 case sensitivity,空字符串,None...

# ✅ GOOD: 完整输入验证
def is_valid_user_id(s):
    if not isinstance(s, str):
        return False
    if not s.strip():
        return False
    return bool(re.match(r"^[a-zA-Z0-9_-]{1,64}$", s))

4.3 修复引入新漏洞

# 修复前
def get_user(name):
    return db.query("SELECT * FROM users WHERE name = ?", name)
# 漏洞: SQL 注入(拼接)

# ❌ 错误的修复
def get_user(name):
    name = name.replace("'", "''")  # 表面修复
    return db.query(f"SELECT * FROM users WHERE name = '{name}'")
# 仍然注入

# ✅ 正确的修复
def get_user(name):
    if not is_valid_username(name):
        raise ValueError
    return db.query("SELECT * FROM users WHERE name = ?", (name,))

4.4 没修 root cause

# 漏洞: 用户密码硬编码
DB_PASSWORD = "password123"

# ❌ BAD: 只改一处
DB_PASSWORD = "password456"  # 改个值 = 没修

# ✅ GOOD: 改用环境变量
DB_PASSWORD = os.environ["DB_PASSWORD"]
if not DB_PASSWORD:
    raise ValueError("DB_PASSWORD must be set")

4.5 修复 + 引入依赖漏洞

# 修复前: 用了有漏洞的库
import yaml  # 5.1 版本有 RCE
yaml.load(user_input)

# ❌ BAD 修复: 升级但不验证
import yaml
yaml.safe_load(user_input)  # 改用 safe_load

# ❌ 同样糟糕: 升到 5.4 但没检查
import yaml
yaml.load(user_input, Loader=yaml.SafeLoader)
# 5.4 仍有 RCE!

五、Skill 触发条件详解

来源:trailofbits/skills README

Use when:
- Submitting a PR that fixes a security issue
- After applying patches for CVEs
- After updating dependencies to fix vulnerabilities
- After fixing hardcoded secrets
- After fixing insecure configurations
- After any "high-risk" code change

翻译:提交修复安全问题的 PR 时;应用 CVE patch 后;升级依赖修漏洞后;修硬编码密钥后;修不安全配置后;任何”高风险”代码变更后。

六、与其他 Trail of Bits Skills 配合

完整工作流:

[1] 漏洞发现 (static-analysis / bug bounty)
  ↓
[2] 根因分析 (systematic-debugging)
  ↓
[3] 写修复代码 + 测试 (TDD)
  ↓
[4] fix-review (验证修复 + 不破坏 + 不引新)
  ↓
[5] merge / PR

七、Prompt 模板

模板 1:基础 fix-review

请用 fix-review 验证我刚修复的 SQL 注入:
- PR: #1234
- 文件: src/api/users.py
- 原漏洞: GET /api/users?id=<SQL>
- 修复方式: 用参数化查询

请:
1. 用原 POC 复现(应用修复前)
2. 应用修复后 POC 失效
3. Semgrep / CodeQL 扫 diff
4. 跑全量测试
5. 输出报告

模板 2:CVE 修复验证

请用 fix-review 验证 CVE-2024-XXXX 修复:
- 受影响: 我们的 v1.2.3
- 修复: 升级 library X 到 2.0.0
- 请:
  1. 检查 changelog / commit
  2. 静态分析新版本
  3. 跑 regression test
  4. POC 验证漏洞不再可触发

模板 3:依赖升级

请用 fix-review 验证依赖升级:
- 从: requests 2.25.0
- 到: requests 2.32.0
- 修复漏洞: CVE-2024-35195
- 请:
  1. 跑全量测试
  2. 静态分析
  3. 检查 API breaking changes
  4. 验证无新漏洞

八、真实踩坑案例

案例 1:表面修复

漏洞:XSS in 用户评论 错误修复:text.replace("<", "&lt;") 替换一个字符 结果:绕过:<<script>> → <script> 但 HTML 解析器仍执行 正确修复:用 DOMPurify 库白名单过滤

案例 2:修了 SQL 注入,加了 XSS

漏洞:SQL 注入 修复:参数化查询 新 bug:错误信息中包含原始输入 → XSS fix-review 捕获:静态分析发现 dangerouslySetInnerHTML 反模式

案例 3:升级依赖,引入新漏洞

升级前:lodash 4.17.20(CVE-2021-23337) 升级到:lodash 4.17.21 新发现:lodash 原作者转让维护权,新维护者发布含恶意代码的 4.17.22 fix-review 捕获:检查维护者 + diff

案例 4:修复 RLS,破坏功能

漏洞:RLS 缺失 修复:auth.uid() = user_id 新 bug:所有用户的 count(*) 查询都变慢 100x fix-review 捕获:性能测试

案例 5:CORS 修复,引入 CSRF

漏洞:CORS 反射 修复:显式 origin 白名单 新 bug:POST /api/transfer 无 CSRF token → CSRF fix-review 捕获:differential-review 查安全模式

案例 6:fix 了一个,引入 3 个

现象:修了 1 个,引入 3 个新 bug 根因:修复 PR 没经过 fix-review 解决:强制所有安全 PR 走 fix-review

案例 7:依赖升级打破 API

升级前:axios 0.x 升级到:axios 1.x 新 bug:response interceptor 签名变了 fix-review 捕获:跑全量测试

案例 8:fix-review 自己写错

现象:fix-review 写”修复成功”,实际没跑测试 根因:跟 systematic-debugging 同样的”伪成功” 解决:verification-before-completion + fix-review

九、9 步完整清单

## Fix-Review 完整清单

### 1. 漏洞信息
- [ ] CVE 编号 / 漏洞报告
- [ ] 严重度评级
- [ ] 受影响范围
- [ ] POC 链接

### 2. 修复信息
- [ ] PR 链接
- [ ] 修复方式
- [ ] 是否修 root cause

### 3. 静态分析
- [ ] Semgrep / CodeQL 跑过 diff
- [ ] 无新增反模式
- [ ] 无新增危险 API

### 4. POC 复现
- [ ] 修复前 POC 触发漏洞
- [ ] 修复后 POC 不再触发

### 5. 回归测试
- [ ] 单元测试全过
- [ ] 集成测试全过
- [ ] 性能不退化

### 6. 依赖检查
- [ ] 没引入新漏洞依赖
- [ ] 升级有 changelog
- [ ] 维护者可信

### 7. 文档
- [ ] CHANGELOG 更新
- [ ] SECURITY.md 更新
- [ ] 修复说明公开

### 8. 部署
- [ ] CI 跑过
- [ ] Staging 验证
- [ ] Canary 监控

### 9. 经验沉淀
- [ ] 团队分享会
- [ ] Goto 写"为什么这样修"
- [ ] 避免下次犯同样错

十、真实战绩

来源:trailofbits 社区统计

十一、Q&A

Q: 跟 systematic-debugging 区别? A: systematic-debugging 找根因 + 修;fix-review 验证修复有效 + 无新 bug。

Q: 必须用 Trail of Bits skills 吗? A: 不。流程可借鉴;工具用 Semgrep / CodeQL / 自家 CI。

Q: 跟 differential-review 区别? A: differential-review 在 PR 时跑;fix-review 在安全 PR 提交后跑。

Q: 跟 superpowers/verification-before-completion 区别? A: verification-before-completion 是一般验证;fix-review 是安全专项验证。

Q: 必须用 Claude Opus 吗? A: 不必须。但 Opus 推理能力更强,适合复杂 fix-review。

Q: 跟 Snyk fix 区别? A: Snyk 自动建议 fix;fix-review Skill 引导 Claude 验证 fix 有效性。

Q: 中文支持? A: 完美。

Q: 学习曲线? A: 1 周内化。

十二、与其他工具对比

十三、安装

# Claude Code
/plugin marketplace add trailofbits/skills
/plugin install fix-review@trailofbits

# 通用
npx skills add trailofbits/skills --skill fix-review

# 工具链
pip install semgrep
brew install codeql

十四、总结

核心价值:

• 强制”修一个 + 验证一个”
• 防止”修一引三”事故
• 完整 9 步清单
• 与 Trail of Bits 14 个 Skill 形成闭环
• 实战验证流程

适用人群:

• 甲方安全团队
• 应急响应小组
• 智能合约审计
• DevSecOps

投入产出比:⭐⭐⭐⭐⭐(5/5)—— 安全团队必装。

何时不要用:

• 功能 bug(用 systematic-debugging)
• 纯样式调整
• 一次性脚本

参考链接:

• trailofbits/skills 官方仓库
• Trail of Bits 公司官网
• tencent 极道详解
• Semgrep 官方文档
• OWASP Top 10
• 配套:static-analysis | variant-analysis | insecure-defaults | systematic-debugging