让 Agent 做安全审计，最常见的失败不是漏了漏洞，而是报了一堆假漏洞。人得逐条去否，几次之后就不再信它了。
Cloudflare 开源的 security-audit 技能，把大部分设计力气花在了这件事上：没被独立证明过的线索，不许写成漏洞。
先说时间线，避免误会：这个仓库最后一次提交是 2026 年 9 月 14 日，约 7.2 万星，不是刚发布的新项目。它是 Cloudflare 那套漏洞挖掘 harness 的种子版本——他们写过博客讲这套 harness 怎么长成全公司规模的多阶段系统，而这个技能是它演化之前的单仓库起点。
六个阶段，一环扣一环
| 阶段 | 做什么 | 留下什么文件 |
|---|---|---|
| 1. 侦察 | 画架构、找信任边界、列输入面、翻历史证据、标出确定性覆盖范围 | architecture.md、coverage-ledger.json |
| 2. 按账本狩猎 | 从账本条目派独立的"猎手"，记录各自查过什么，再用"覆盖评审员"找缺口 | 覆盖账本持续更新 |
| 3. 候选验证 | 每个候选交给全新的验证者，任务是证伪它 | — |
| 4. 结构化输出 | 按三种判定写记录，并对 report-schema.json 校验 | findings.json |
| 5. 独立复核 | 新 Agent 复核最终的事实陈述；结论被替换的要再过一遍验证 | findings 更新 |
| 6. 中立报告 | 从已核实的记录和覆盖账本推导报告，不带目标倾向 | REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md |
账本建好之后、以及之后每次更新，父流程都要跑一次 validate-coverage-ledger.cjs；第 4 阶段跑 validate-findings.cjs，第 5 阶段每次替换后再跑一次。两个校验器都是零依赖的 Node 脚本，还各自带测试。
用脚本卡格式这件事看着琐碎，其实是这套流程可信的前提：模型可以编一段漂亮的结论，但编不过 schema 校验。
三种判定，语义完全不同
这是全文最值得抄的设计：
confirmed：有完整的来源链，加上有界的、被观察到的结果。两条都要，缺一条就不算。needs_validation：写清一个具体的、尚未解决的事实，并且不给严重度。没定级，就不会被当成漏洞用。rejected：被证伪的候选，留着备查。
很多安全 Agent 的问题就出在没有中间态：要么说"是漏洞"，要么不提。有了 needs_validation 这一层，模型不必为了给结论而夸大，人也能看到"哪里还不确定、不确定的是哪件事"。
两条硬规矩
第一，验证者不是发现者。找到问题的 Agent 和判断它是否成立的 Agent 必须是两个，上下文也隔开。这是流程层面的对抗性验证，不靠模型自觉。
第二，严重度必须有影响。按可能性 × 影响算，而不是"偏离了检查清单"就算漏洞。官方还给了一条明确的边界：如果 A 层已经挡住了攻击，那么缺 B 层只是加固建议，不是漏洞。这条能砍掉大量"理论上不安全"的报告。
另外它承认覆盖是累积的：官方在自家测试里说，单次运行大约只能发现重复运行总量的二分之一。所以这个技能被设计成可叠加的——多次跑同一个仓库，会复用之前的账本和结论，把力气放在缺口和改动过的源码上，而不是从零重来。
十个攻击面文件，才是真正的资产
除了流程，仓库里有一批按目标类型分的狩猎提示：内存安全与二进制内核、AI 与 LLM（提示注入、Agent 与工具调用、输出处理）、Web 协议与认证（请求分帧、缓存、认证协议）、客户端（DOM 注入、消息信任、UI 重定向、原型污染）、供应链与发布、云与部署（IAM、IaC、容器、无服务器、入口、运行时配置）、RPC 与消息、资源耗尽与可用性、数据隔离与生命周期、桌面/移动与本地 IPC。
换句话说，它不是"通用安全提示词"，而是先把目标归类，再调对应的攻击面清单。这套分类本身，就是从真实漏洞挖掘里攒出来的经验。
一条容易被忽略的硬要求
README 里写得很明确：要跑目标代码（构建、测试、起进程、开浏览器、模拟器、fuzzer），必须有操作系统级沙箱——禁外网、用白名单清洗过的环境、限资源、只允许写指定的临时目录。
没有这些控制呢？流程不会硬着头皮跑，而是把线索保持在 needs_validation，不去执行目标代码。
这条规定其实是在说：审计工具要跑别人的代码，跑之前得先有个笼子。做这类工具时，这往往是最容易省掉、也最不该省的一步。
怎么装
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit加 --global 是用户级安装。装好后在目标仓库里直接说要审计：security audit this codebase、find security vulnerabilities in ./src 这类请求会触发它。默认输出到 ~/security-audit-skill/<repo>/run-<N>，只有你明确指定一个被版本控制忽略的目录时才会写进仓库。MIT 许可。
该信多少
- 本文读的是仓库 README，没有安装、没有对任何代码库跑过审计。
- 六个阶段是流程设计，不是效果数据；仓库没给"发现了多少真实漏洞"的公开统计。
- "单次跑约为重复跑总量的一半"是官方自家测试的说法，没有给样本和方法。
- 它对模型的工具调用和并行子 Agent 能力有要求；沙箱要求不满足时，效果会打折而不是报错。
一句话判断
这个仓库真正的贡献不是"让 Agent 会找漏洞"，而是给 Agent 的结论定了三种不同的可信度，并且要求换一个人来验。安全审计这件事，人做的时候靠的是评审文化和怀疑习惯；它把这些习惯写成了流程和校验脚本。至于它在你自己的代码库上能挖出什么，得跑了才知道——而且第一次跑的数字，按它自己的说法，大概只有一半。
来源
- cloudflare/security-audit-skill（README、文件清单；72,002 星，最后提交 2026-09-14，MIT）
- Cloudflare 博客：Build your own vulnerability harness（该技能的来源系统）
说明：星数与最后提交时间由 GitHub API 于 2026-11-14 读取；本文未运行该技能，内容为官方文档解读。