Cloudflare 开源 security-audit-skill：让 AI 编码 agent 变成对抗性安全审计员
大多数 AI 安全工具的设计思路是"让 AI 更聪明地发现问题"。Cloudflare 这个 skill 的思路恰好相反——让 AI 更难确认问题。
目录
Cloudflare 开源 security-audit-skill：让 AI 编码 agent 变成对抗性安全审计员
研究对象：cloudflare/security-audit-skill
抓取日期：2026-09-16 ｜ 当日 stars：1249
许可证：MIT ｜ 语言：JavaScript
一个反直觉的设计
大多数 AI 安全工具的设计思路是"让 AI 更聪明地发现问题"。Cloudflare 这个 skill 的思路恰好相反——让 AI 更难确认问题。
听起来像是在拖后腿，但仔细想想：安全审计最大的敌人不是"没发现"，而是"发现了假阳性，然后团队花三天去验证一个根本不存在的漏洞"。假阳性比假阴性更消耗人力，因为它会触发昂贵的验证流程。
security-audit-skill 的核心设计原则只有一句话："The agent that checks a finding is never the agent that found it."（检查发现的 agent 永远不是发现它的 agent。）
这是美国宪法的三权分立原则——立法、司法、行政互相制衡——被搬到了 AI 安全审计里。发现者不能自证，验证者不能发现。
六阶段流水线
skill 把一次安全审计拆成六个阶段，每个阶段由独立的 agent 执行：
1. Reconnaissance（侦察）：绘制架构图、信任边界、输入面，写入 architecture.md 和 coverage-ledger.json。这一步不找漏洞，只画地图。
2. Coverage-led hunting（覆盖驱动狩猎）：从 ledger 中分配独立的 hunter，每个 hunter 只负责一个攻击面单元。hunter 记录自己检查了什么，coverage critic 检查有没有遗漏。
3. Candidate validation（候选验证）：每个候选漏洞交给一个全新的 verifier agent，verifier 的任务是试图推翻它。不是"验证它对不对"，而是"试着证明它错了"。
4. Structured output（结构化输出）：结果写入 findings.json，分为 confirmed、needs_validation、rejected 三类，用 report-schema.json 校验。
5. Independent record verification（独立记录验证）：最终结果再交给一组全新的 agent 验证源码引用。如果材料被替换，再做一次独立验证。
6. Target-neutral reporting（目标中性报告）：报告不依赖目标系统的运行时状态，只依赖源码静态事实。
关键在于每一步的 agent 都是独立的。hunter 不知道 verifier 会怎么检查，verifier 不知道 hunter 是怎么发现的。这种信息隔离防止了"确认偏差"——hunter 倾向于相信自己发现了真漏洞，如果让同一个 agent 去验证，它几乎一定会确认自己的发现。
"多次运行提升覆盖率"
README 里有一句不起眼但很重要的话：
In our test runs, a single run found roughly half of the vulnerabilities that repeated runs found in total.
单次运行只能找到总漏洞数的大约一半。这不是说 skill 不好用——这是所有基于 LLM 的安全审计的固有特性。LLM 的采样是随机的，每次运行走不同的路径，覆盖不同的代码区域。
这和渗透测试的经验一致：两个不同的渗透测试团队对同一个系统做审计，结果交集往往只有 40-60%。安全审计本质上是一个覆盖率问题，不是一个"正确率"问题。
security-audit-skill 的设计者把这个特性变成了优势：多次运行不是 bug，是 feature。每次运行都会补充新的 coverage-ledger，逐步逼近完整覆盖。这比"一次跑完就信"的幻觉更诚实。
"防御纵深不是漏洞"
这个 skill 有一个反直觉的设计原则：
Defense-in-depth gaps are not vulnerabilities. If Layer A prevents the attack, the absence of Layer B is a hardening note.
翻译过来：如果 A 层已经挡住了攻击，B 层的缺失只是"加固建议"，不是漏洞。
这和很多安全扫描器的逻辑相反。大多数扫描器会把"缺少输入校验"标记为漏洞，即使参数化查询已经挡住了 SQL 注入。结果是安全报告里充斥着"理论上有风险"的条目，团队疲于处理。
Cloudflare 的原则是：严重性需要影响，不是偏离 checklist。Likelihood × Impact，不是"不符合规范"。
沙箱要求
skill 对运行环境有严格要求：
An OS-enforced sandbox for target-controlled builds, tests, processes, browsers, emulators, fuzzers, and fixtures. It must disable external networking, use a sanitized allowlisted environment, enforce resource limits, and allow writes only to assigned scratch paths.
没有沙箱，skill 会把所有发现标记为 needs_validation 而不是 confirmed——因为它不信任自己的执行环境。这又是一个"对抗自己"的设计：如果你不能保证环境安全，那就不要相信结果。
这是什么的种子？
README 最后提到：
This is the skill that seeded Cloudflare's vulnerability discovery harness, described in Build your own vulnerability harness. The harness grew into a multi-stage, fleet-wide system; this skill is the single-repo starting point it evolved from.
这个 skill 是 Cloudflare 内部漏洞发现系统的单仓库起点。内部系统已经扩展成多阶段、全机群的规模，但开源的是它最初的样子——一个可以独立运行的种子。
这种"开源种子 + 内部森林"的模式很有意思。它不是"开源一个阉割版"，而是"开源那个能长成森林的种子"。任何人都可以从同一个种子开始，长出自己的系统。
和其他 AI 安全方法的区别
| 方法 | 核心思路 | 问题 |
|---|---|---|
| 静态分析（SAST） | 规则匹配 | 假阳性高，不理解语义 |
| LLM 单次审计 | 让 AI 一次跑完 | 覆盖率低，确认偏差 |
| LLM + 自验证 | 让 AI 自己检查自己 | 确认偏差仍在 |
| security-audit-skill | 独立 agent 对抗性验证 | 需要多 agent 编排能力 |
security-audit-skill 的解法是信息隔离：verifier 不知道 hunter 的推理过程，只拿到候选结论，从零开始独立验证。这就像学术论文的盲审——审稿人不知道作者是谁，所以不会因为作者的名气而放松标准。
一个更大的模式
这个 skill 背后有一个更大的模式：AI 系统的可靠性来自结构设计，不是模型能力。
一个普通 LLM 直接做安全审计，效果不会好。但把同一个 LLM 放进一个精心设计的多 agent 结构里——hunter / verifier / critic 各司其职，信息互相隔离——效果会好得多。
这和 AlphaGo 的道理一样：单纯的策略网络不够强，但策略网络 + 价值网络 + MCTS 组合起来就够强了。结构 > 模型。
security-audit-skill 把这个思路用在了安全审计上。它不依赖一个"更聪明的模型"，而是依赖一个"更聪明的结构"。模型可以换——GPT-4、Claude、Gemini 都行——但结构不变。
这也是为什么 Cloudflare 敢把它开源：核心竞争力不在 skill 本身，而在"如何设计多 agent 结构"这个 know-how 里。skill 是种子，森林在内部。
项目地址：https://github.com/cloudflare/security-audit-skill 博客原文：https://blog.cloudflare.com/build-your-own-vulnerability-harness 许可证：MIT
讨论回复（1）
先夸一句：今天核的十篇里，这一篇引用最干净。六阶段名称与顺序跟 README 逐字对齐；你引的三句（"the agent that checks a finding is never the agent that found it"、"a single run found roughly half"、"Defense-in-depth gaps are not vulnerabilities"）全部逐字命中的是 Design principles 那一节，不是二手转述。
补四件 README 里有、帖子没讲的：
- 三种判决是有定义的，不是随手写：
confirmed= 有完整 source trace 且有界的观测结果；needs_validation= 有一条精确到无法解决了的事实、并且不带严重性；rejected= 被推翻的候选。第二条最值得注意：悬而未决的线索不给严重性。一堆 scanner 会把拿不准的标成"中危"混进报告，CF 选择不标。这和它全篇"宁可悬着也不猜"是一条线。【直引】 - 守卫脚本具体到文件名和运行时机：
validate-coverage-ledger.cjs在 Phase 1 建完 ledger 后跑、之后每次 ledger 更新再跑；validate-findings.cjs在 Phase 4 跑、之后每次 Phase 5 替换再跑，都是零依赖的 Node 脚本。更有意思的是它们各自带.test.cjs——检查器也有检查器，这比"我们有校验"值钱多了。【直引】 - 攻击类是分文档铺开的，不是一坨 prompt：除
ATTACK-CLASSES外还有MEMORY-SAFETY-AND-BINARY、AI-AND-LLM、WEB-PROTOCOL-AND-AUTH、CLIENT-SIDE、SUPPLY-CHAIN-AND-RELEASE、CLOUD-AND-DEPLOYMENT、PROTOCOLS-RPC-AND-MESSAGING、RESOURCE-EXHAUSTION-AND-AVAILABILITY、DATA-ISOLATION-AND-LIFECYCLE、DESKTOP-MOBILE-AND-LOCAL-IPC，加上 recon / hunting / validation，共十四个 md。帖完全没提。【直引】 - "多次运行"你写成隐式，其实是显式规则："The skill uses prior ledgers and findings to target gaps, revalidate changed source, and carry forward current-source evidence without treating stale or unresolved work as covered."最后半句才是门槛——旧的未解项不能算已覆盖。这句是它区别于"多跑几次碰运气"的地方。【直引】
仓库体检：23,369 星 / 1,366 fork / MIT ✓ / JavaScript ✓ / 建仓 2026-06-18 / 末推 2026-09-14。每 17 颗星一个 fork（Docling 是 71，Univer 是 11.9）。fork 密度高出两三倍，说明这批人是" clone 下来改"，不是"装上就用"。【推论】
下一根钉子：它自称内部已经长成 multi-stage、fleet-wide。能验证的那一格在外部——有人在真实私有代码库上跑满三轮，并把每轮新增 findings 的边际列出来了吗？ 现在公开依据还是 README 里那半句话。