Cloudflare代码审计技能新增中文译本

给 coding agent 装上安全审计 skill，并不等于仓库就完成了安全检查。Cloudflare 的 security-audit-skill 把查找、反证、复核拆成六个阶段，中文文档想解决的，则是使用者容易跳过的执行前提：沙箱、并行子代理，以及多次运行。

这篇原文值得读的地方，是把「装上就能用」拆成了几个必须确认的问题。流程确实有设计，但它依赖什么环境、报告能证明什么、哪些结论还没有证据，都要分开看。

为什么找到漏洞的代理不能自己确认

这个 skill 的关键，并不是把「帮我找漏洞」写得更详细，而是限制代理怎样得出结论。它要求不同角色分工，发现候选问题的代理不能直接把自己的发现盖章为漏洞。

六个阶段可以沿着证据流理解：

1. 先侦察架构、信任边界、输入入口、已有证据和确定性检查的覆盖情况，生成 architecture.md 与 coverage-ledger.json。
2. 按覆盖台账分配独立的搜寻代理，记录检查内容，再由覆盖审查代理寻找遗漏。
3. 每个独立候选交给新的验证代理，任务是尝试推翻它。
4. 把结果写入 findings.json，并通过 report-schema.json 校验。
5. 再由独立代理检查最终记录中的源码依据；实质性替换需要另一名独立验证者确认。
6. 根据核验后的记录和覆盖台账，生成 REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md。

这里的覆盖台账，可以理解成一份「查过哪里、怎么查的、还缺什么」的账本。它让后续工作有据可循，也给复核者一个寻找缺口的入口。

结果分成三类，不能混用。confirmed 要求完整源码追踪和有边界的观察验证；needs_validation 必须指出某个尚未解决的具体事实，而且不分配严重程度；rejected 则保存被证伪的候选。

没有验证完的问题，不该靠措辞升级成已确认漏洞。

保留 rejected 也有实际用途：后续运行能知道哪些方向已被推翻，减少重复搜寻。

两个 Node 脚本负责约束输出形状。主代理创建台账后、每次更新台账后，都要运行 validate-coverage-ledger.cjs；validate-findings.cjs 在第四阶段执行，第五阶段每次替换记录后还要再次执行。不过，格式校验通过，并不能单独证明漏洞判断正确。

为什么没有沙箱，报告可能一直停在待验证

原文最容易被忽略的条件，是执行目标代码之前必须具备操作系统强制隔离的沙箱。

构建、测试、进程、浏览器、模拟器、模糊测试和测试夹具，都可能执行仓库里的代码。要求包括：关闭外部网络、使用经过清理的白名单环境变量、强制资源上限，以及只允许写入指定临时路径。

缺少这些控制时，流程会把相关线索留在 needs_validation，而不会继续执行目标代码。这能解释一种使用落差：安装成功了，也生成报告了，但很多问题没有得到确认。限制可能来自运行环境。

另一项硬要求是 coding agent 和模型支持工具调用、并行子代理。搜寻者、覆盖审查者、新验证者、独立记录核验者之间的隔离，是整个流程的一部分。原文没有给出不能创建并行子代理时的降级方案。

已明确的依赖还包括 Node.js，用来运行零依赖的发现记录与覆盖台账校验脚本。支持哪些操作系统、硬件要求如何、具体需要哪个 Node.js 版本，原文都没说清。中文版保留了「原文未说明」，没有自行补齐。

适用范围也不只限于 Web 应用。MEMORY-SAFETY-AND-BINARY.md 表明项目包含面向原生目标的指导，但仅凭这个文件，不能判断它对某类目标的实际审计效果。

中文版帮你读懂边界，安装的仍是上游代码

据原文所述，上游 cloudflare/security-audit-skill 有 45,592 个 GitHub stars，中文仓库发布时为零。这个对比能说明传播差距，却不能作为审计效果的证据。

中文仓库是 yangshun2005/security-audit-skill-cn，翻译日期为 2026-10-25。原文标注项目采用 MIT 许可证，原始语言为 JavaScript。英文 README 保存在 README_en.md，方便对照。

它做得比较清楚的一点，是把「中文快速上手」标为补充说明，再提供忠实翻译。读者因此能区分哪些来自原项目，哪些是译者增加的使用提醒。

安装时仍然从上游获取 skill：

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

要留意仓库地址：这里没有安装中文仓库的另一套实现。用户级安装是在命令末尾添加 --global；代理选择和非交互选项可查看 npx skills --help。GitHub 拉取较慢时，中文文档提醒可能需要 npm 镜像或代理，但没有给出完整网络配置方案。

随后可以向 coding agent 发出：

do a security review, output to ~/audits/my-project

要留意这里显式指定了输出目录。原文还提供 security audit this codebase、find security vulnerabilities in ./src，并列出 security audit、find vulnerabilities、pen-test the code 等触发短语。

完整审计不指定目录时，原文把默认路径写作 ~/security-audit-skill/ /run-，并特别说明空格来自源文。这个写法不够清楚，不宜自行猜测。工作流只有在明确选择被版本控制忽略的目录时，才会向目标仓库内部写入结果。

还有一个使用预期必须调整：原 README 声称，单次运行发现的漏洞，约占重复运行累计发现总量的一半，因此建议对同一仓库运行多次。它描述的是重复运行的累积收益，并没有证明多跑几次就能覆盖全部漏洞。

我的判断

我认同它把「搜寻」和「确认」拆开的做法。相比直接让同一个代理读代码、列问题、写报告，这套流程更便于追问：结论依据是什么，反证尝试过没有，还有哪些地方没查。

但角色分开，不自动等于判断相互独立。原文没有给出模型组合、误报率、漏报率，也没有展示与单代理审计或常规扫描的对照数据。「单次约发现一半」同样缺少样本范围、漏洞类型和运行条件。现阶段适合把它当成项目提供的经验描述，不能照搬成一般团队的效果承诺。

运行时间和成本也没有交代。多角色、多次运行值得尝试，但普通团队能否持续采用，需要自己验证。

还要分清项目规模：这里安装的是 Cloudflare 漏洞发现框架面向单仓库的起点版本，不是后来扩展出的多阶段、大规模系统。不能把后者的规模表现直接算到这个 skill 头上。

中文版的价值在于减少误读。读英文文档顺畅的人可以优先看上游；依赖中文版的团队，则需要记住 2026-10-25 这个翻译日期，后续行为仍应与上游核对。

能拿来做什么

• 审计前端或 Node 仓库前，先确认 coding agent 支持并行子代理，并核对构建、测试所需的沙箱条件；缺失条件时，应预期部分线索只能待验证。
• 首次试用可以用 find security vulnerabilities in ./src 明确范围，再显式指定输出目录，方便检查台账是否清楚记录了已查内容和遗漏。
• 阅读报告时，把 confirmed、needs_validation、rejected 分开处理，尤其要追问待验证记录究竟缺哪个事实，不要只统计候选数量。
• 按项目建议安排重复审计，同时保留覆盖台账和被证伪记录，用后续运行新增的有效发现判断收益，不把一次报告当成审计终点。