补丁验证

确认补丁真修漏洞、不破坏任何东西、达生产 — "完成"前三检查。

为什么

过 CI 但不修漏洞的补丁比无补丁更糟 — 你声明漏洞修了、降其优先级、走了，而利用仍工作。验证是防此的三部分检查：(1) 回归测试修复前复现漏洞、修复后过（证修复工作），(2) 完整测试套件 + e2e 过（证修复不破坏），(3) 生产部署版本匹配补丁版本（证修复达生产）。跳任一是漏洞"修了"然后数月后再被利用的方式。验证便宜（分钟）且防昂贵失败（再利用 + 第二事件 + 失信任）。

何时使用

声明任何安全补丁"完成"前。三检查须全过才能发公告。

如何做

1. 修复工作检查：在未修代码跑回归测试（应失败），然后在补丁代码跑（应过）
2. 无破坏检查：在补丁代码跑完整单元 + 集成 + e2e 套件；须全过
3. 达生产检查：部署后查运行版本（GET /api/version）确认匹配补丁发布
4. 依赖补丁：验证锁文件有新版本（npm ls <依赖>）且新版本实加载（未被去重去）
5. 配置修复：验证配置已部署（curl 端点确认行为变）
6. 在公告记验证："已验证：回归测试过、全套件绿、生产版本 = v1.2.3"
7. 设 30 天跟进：复查修复仍在生产（回退可能已回退它）

示例

# 1. 修复工作检查（回归测试前后）
git checkout v1.2.2  # 未修
npm test -- --grep "CVE-2024-9999"  # 失败（复现漏洞）✓
git checkout hotfix/cve-2024-9999
npm test -- --grep "CVE-2024-9999"  # 过（修复工作）✓

# 2. 无破坏检查（全套件）
npm test && npm run e2e  # 全绿 ✓

# 3. 达生产检查（部署后）
curl https://api.ez4code.com/api/version
# { "version": "1.2.3", "commit": "abc1234" }
git rev-parse v1.2.3  # abc1234  # 匹配 ✓

# 4. 依赖补丁验证
npm ls lodash  # -> 4.17.21（已修）✓
# 确认实加载（未被去重到旧副本）：
node -e "console.log(require('lodash/package.json').version)"  # 4.17.21 ✓

# 在公告记
# "已验证：回归测试在 v1.2.3 过、全套件绿、
#  生产 /api/version 返 1.2.3、[email protected] 确认加载。"

# 30 天跟进（计划检查）
# curl /api/version — 仍 1.2.3？（回退会回退修复）

常见问题

⚠未验证修复达生产即发公告 — 补丁在发布但部署失败，漏洞仍可利用。
⚠依赖补丁锁文件有新版本但旧副本去重入包 — 修复在 node_modules 但不在运行的。
⚠无跟进检查 — 2 周后回退悄悄回退修复，漏洞再被利用。

最佳实践

✓在未修（须失败）和补丁（须过）代码都跑回归测试 — 这证修复工作非仅测试过。
✓通过 /api/version 验证部署生产版本匹配补丁发布 — 未部署的补丁是未修的补丁。
✓设 30 天跟进复查修复仍在生产 — 回退发生且回退的修复是待再利用。