GitHub 今日 +2,375 星：Cloudflare 把 AI 安全审计做成了可复核的流水线

GitHub 今日 Trending 里，Cloudflare 的 security-audit-skill 出现了 +2,375 stars today。同一观察窗口里，这个 6 月才创建的仓库累计 17,939 stars、994 forks。GitHub Trending 的数字说的是一天内新增关注，不是累计 star，更不是一次产品发布的下载量。

不过，值得看的并不是这个数字本身。把“帮我审计代码”的提示交给一个 Agent，通常只能换来一份很长、很自信、却难以判断真假的报告。Cloudflare 开源的 security-audit 想解决的是后半段：怎样让一个可疑发现有边界、有来源、有反证，并且能被另一个 Agent 或工程师重新检查。

我会顺着这份 Skill 和它背后的官方漏洞发现系统，把这件事拆开。期望对大家有所帮助。

热度背后有一套完整材料

这个仓库并不是临时拼出的“安全提示词合集”。README 明确说明，security-audit 是 Cloudflare 漏洞发现 harness 的单仓库起点；后者已经演变成持续运行、跨仓库的多阶段系统。官方技术文章 也把两者的关系讲得很直白：先在单个仓库里反复调整 Skill，找到真正的漏洞；再把其中稳定的阶段、状态与验证规则搬进更大的编排系统。

仓库最近一次提交在 9 月 14 日，主题是澄清“指导模式”和“完整审计模式”；9 月 10 日的一组提交则重做了审计工作流、finding contract 与验证器。提交记录 和完整 SKILL.md 都是公开的。它没有发布版号，这一点也需要如实说：今天的传播信号来自 Trending，而不是新 Release。

更重要的是，Cloudflare 没把“模型会找漏洞”当作结论。官方文章记录了一个很朴素的教训：同一代码库跑一次只能找到多次运行最终发现问题的大约一半，而且第一次更容易碰到简单问题。于是，系统的目标不再是制造更多候选，而是维护覆盖范围、保留证据，并尽量把不可靠候选挡在人类审阅之前。

它先要求一个真正的安全边界

security-audit 的第一条原则很像安全工程师会问的那句话：谁在攻击谁，跨过了什么边界，结果具体伤害了哪个主体或资源？

这会排除大量看似“有问题”但实际上只是代码风格或加固建议的内容。例如，少一层额外防护不自动等于漏洞；如果前一层控制已经阻断攻击，后者应当作为 hardening note，而不是高危发现。一个候选还必须说明低信任输入、原本应执行的控制、受影响资源和可观察结果。缺少其中任一环，就不能被写成已确认漏洞。

这也是它和一般代码 review Prompt 最不一样的地方。它不要求 Agent 列出“风险点”，而是要求每条结论带着可被推翻的主张前进。没有实际边界，就没有 finding。

六个阶段，核心是让发现者不能给自己打分

README 把工作拆成六段：

1. 侦察：画出架构、信任边界、输入面和既有证据，并写入 architecture.md 与 coverage-ledger.json
2. 按覆盖面搜索：根据账本把不同的攻击面和攻击类别交给隔离的 hunter，再用 coverage critic 找遗漏
3. 候选验证：把每一个独特候选交给全新的 verifier，由它尝试证伪
4. 结构化输出：把记录写入 findings.json，再由零依赖验证器检查 schema
5. 独立记录复核：另一批新 Agent 复查最终引用的源代码和结论
6. 生成报告：从已经核过的记录与覆盖账本导出面向人的报告

flowchart LR
  A[侦察与覆盖账本] --> B[按攻击面搜寻]
  B --> C[新 Agent 尝试证伪]
  C --> D{记录状态}
  D -->|confirmed| E[独立复核]
  D -->|needs_validation| F[标明缺失事实]
  D -->|rejected| G[保留反证]
  E --> H[报告与工程分流]

这里真正有价值的安排是独立性。发现问题的 Agent 不能验证自己的问题，最终记录又要再过一次新 Agent 的复查。Cloudflare 在官方文章中写得更尖锐：如果 hunter 可以“批改自己的作业”，它会把几乎所有输出都确认下来。

这条工作流还有三个互斥状态：confirmed 是有完整来源轨迹与受限、已观察结果的发现；needs_validation 指向一个具体但无法从代码或隔离本地环境确认的事实；rejected 则保留已被推翻的候选。needs_validation 没有严重等级，避免“没证实但先报高危”的常见错误。

账本比一份报告更接近可靠性

AI 审计很容易在一份漂亮报告里制造一种错觉：看起来检查了很多东西，所以应该覆盖得很全。这个 Skill 的做法恰好相反，它把覆盖写成可更新的 coverage-ledger.json，按“攻击面 × 信任边界 × 攻击类别”记录工作是否完成、缺什么证据、哪些路径因预算或环境条件被推迟。

这样做有两个实际好处。

第一，多次运行不是覆盖旧结果的重来，而是读取已有账本，优先补空白、复验改动过的代码；之前被拒绝的主张只能抑制同一份未变证据，不能让整个区域从覆盖范围里消失。第二，无法安全执行目标代码时，流程不会假装验证成功。Skill 要求在没有外网、受限环境、受控写入路径和资源限制的 OS 级沙箱中运行目标控制的测试或构建；做不到，就把关键事实留在 needs_validation，而不是执行未知代码。

这是一种很实际的取舍：少一点“自动跑完”的爽感，换取发现不被环境污染、报告不把猜测包装成证据。

为什么它能从 Skill 长成漏洞发现 harness

Cloudflare 的公开版本止步于单仓库起点，而内部的 harness 继续把这些约束外化为任务队列、数据库、去重和跨仓库追踪。官方文章 介绍的系统把侦察、搜索、验证、补缺、去重、依赖追踪和反馈拆成独立阶段，并刻意用不同模型做发现与判断。

原因不难理解。面对一两个仓库，重复运行、人工对照报告还勉强可行；面对很多代码库后，候选数、重复问题和中断恢复就会先压垮人。Cloudflare 给出的路线也并不鼓励一开始就复制整套系统：先用一个 Skill 跑通 Recon、Hunt、Validate；只有当手工比较结果已经成为具体瓶颈时，再把状态、队列和跨仓库追踪加上去。

所以它最有参考价值的地方不是“安全 Agent 应该并发多少个”，而是状态机先于规模。先定义什么算发现、什么只是待验证、谁有资格确认；模型和编排框架以后都可以替换。

适合谁试，试之前先确认什么

适合试用的是有明确源码边界、能提供隔离测试环境的团队，尤其是想把安全 review 从一次性人工清单变成可重复流程的项目。安装命令来自 README：

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

但不要把它当成扫描器一键替代品。开始前至少要确认三件事：目标代码是否允许在没有外网、受限资源的沙箱里执行；输出目录是否在受控位置而不是写进业务源码；团队是否能处理 needs_validation，而不是把它们自动升级为漏洞。Skill 本身也要求有支持工具调用与并行子任务的 coding agent，以及 Node.js 来运行两个零依赖验证器。

如果这些条件满足，security-audit 给出的不是一个“更会找 bug”的人格，而是一套承认不确定性、又知道怎样收敛不确定性的工作过程。今天的 +2,375 更像是开发者开始注意到这件事：AI 安全审计的难点，从来不只是让模型提出怀疑。

---

• 仓库：cloudflare/security-audit-skill
• 官方文章：Build your own vulnerability harness