Cloudflare security-audit-skill：单次只抓一半漏洞，但多次运行会累加

研究对象：cloudflare/security-audit-skill
抓取日期：2026-10-20 ｜ 当日 stars：1680
许可证：MIT ｜ 语言：JavaScript

一个反直觉的承诺

大多数安全工具的卖点是"一次跑完，全部找到"。Cloudflare 这个 skill 的 README 里有一句很诚实的话：

In our test runs, a single run found roughly half of the vulnerabilities that repeated runs found in total.

单次运行只能找到总漏洞数的大约一半。这不是 bug，是 feature。

听起来像是在推卸责任，但仔细想想：渗透测试行业几十年的经验早就证明，两个不同的团队对同一个系统做审计，结果交集往往只有 40-60%。安全审计本质上是一个覆盖率问题，不是一个"正确率"问题。任何声称"一次跑完就能全覆盖"的工具，要么在撒谎，要么没跑过足够大的代码库。

security-audit-skill 把这个特性变成了设计原则：多次运行是累加的。每次运行都会读取之前的 coverage-ledger.json，针对未覆盖的区域分配新的 hunter，同时重新验证源码已变更的部分。旧 finding 如果源码没变，直接 carry forward；如果源码变了，重新验证。

这比"一次跑完就信"的幻觉诚实得多。

从 skill 到 harness 的进化

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 内部安全系统的全部，而是它的起点。Cloudflare 的完整系统已经进化成多阶段、车队级别的架构，但这个开源版本保留了"单仓库起点"的形态。

这个进化路径值得注意：先写一个能跑的 skill，再让它长成系统。很多团队一上来就想设计一个完整的安全平台，结果设计文档写了三个月，一行能跑的代码都没有。Cloudflare 的路径反过来：先解决"一个仓库的安全审计"这个最小问题，在真实使用中发现瓶颈，再逐步扩展成 fleet-wide 系统。

这和创业的 MVP 逻辑一样，但应用在了内部工具上。

六阶段流水线：信息隔离是核心

skill 把一次安全审计拆成六个阶段：

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 三类。
5. Independent record verification（独立记录验证）：最终结果再交给一组全新的 agent 验证源码引用。
6. Target-neutral reporting（目标中性报告）：报告只依赖源码静态事实，不依赖运行时状态。

核心设计原则只有一句话："The agent that checks a finding is never the agent that found it."（检查发现的 agent 永远不是发现它的 agent。）

这是美国宪法的三权分立搬到了 AI 安全审计里。立法者不能执法，执法者不能司法。发现者不能自证，验证者不能发现。这种信息隔离防止了"确认偏差"——hunter 倾向于相信自己发现了真漏洞，如果让同一个 agent 去验证，它几乎一定会确认自己的发现。

三种 verdict，不是两种

大多数安全工具的输出是二元的：有漏洞 / 没漏洞。security-audit-skill 给了三种 verdict：

• confirmed：有完整的源码追踪和有界的观察结果。可以直接修。
• needs_validation：有一个精确的未解决事实，没有严重等级。需要人来看。
• rejected：被证伪的候选。记录下来，避免下次重复发现。

needs_validation 这个中间态很重要。大多数工具要么报"确认漏洞"要么不报，但安全审计的现实中大量候选是"看起来像漏洞但无法确认"——可能是因为代码路径不可达，可能是因为输入验证在其他地方做了，可能是因为运行时配置会阻止。直接报"确认"会产生假阳性，不报又会遗漏真问题。

needs_validation 把这个灰色地带显式化了。它不强迫 agent 做二元判断，而是说"我发现了 something，但需要人来确认"。这比假阳性泛滥的报告有用得多。

"防御纵深不是漏洞"

这个 skill 有一条容易被忽略的设计原则：

Defense-in-depth gaps are not vulnerabilities. If Layer A prevents the attack, the absence of Layer B is a hardening note.

如果 Layer A 已经阻止了攻击，Layer B 的缺失只是一个"加固建议"，不是漏洞。

这条原则解决了一个长期困扰安全审计的问题：很多工具把"缺少最佳实践"报成"漏洞"。比如一个系统已经在网关层做了输入验证，但在应用层没有重复验证——很多工具会报"应用层缺少输入验证，高危"。但实际上网关层已经挡住了，应用层的验证是 defense-in-depth，不是必需品。

把 defense-in-depth gap 和 vulnerability 分开，让报告的优先级更清晰。开发者看到"高危"就知道是真的要修，看到"加固建议"就知道是 nice-to-have。

什么算"已确认"

README 对 confirmed 的定义很严格：

Only confirm established boundary failures. Keep a source-grounded blocked lead as needs_validation with its exact unresolved fact.

只有"已确立的边界失败"才能确认。如果一个 lead 只是"源码层面被挡住了"（比如代码路径看起来可达但运行时不可达），它只能停留在 needs_validation，带上它未解决的那个精确事实。

这个定义比大多数工具严格得多。大多数工具的"confirmed"只是"agent 认为它是漏洞"，但 agent 的判断可能基于不完整的代码阅读、错误的路径假设、或者忽略了某个运行时检查。security-audit-skill 要求 confirmed 必须有完整的源码追踪——从输入到影响的完整路径，每一步都有源码引用。

适用场景

这个 skill 不是万能的。README 明确列出了要求：

• 需要支持工具调用和并行子 agent 的编码 agent（Claude Code、Codex 等）
• 需要 Node.js（运行零依赖的 validator）
• 需要 OS 强制的 sandbox（用于目标控制的构建、测试、进程等）。sandbox 必须禁用外部网络、使用白名单环境变量、强制资源限制、只允许写入指定路径。没有这些控制，skill 会把 lead 保持为 needs_validation 而不是执行目标代码。

最后一条值得注意：没有 sandbox，skill 不会执行目标代码。它会把需要运行时验证的 lead 标记为 needs_validation，而不是冒险执行可能有害的代码。这是对"安全工具本身不能变成攻击面"的尊重。

设计哲学的启示

security-audit-skill 的设计哲学可以总结为三条：

1. 信息隔离 > 能力增强。不是让 agent 更聪明地发现问题，而是让不同的 agent 互相制衡。发现者不能验证，验证者不能发现。
2. 覆盖率 > 正确率。单次运行的正确率不重要，多次运行的覆盖率累加才重要。承认单次运行的局限性，比假装能一次跑完更诚实。
3. 严格定义 > 宽松定义。confirmed 需要完整源码追踪，defense-in-depth gap 不算漏洞，needs_validation 是显式的中间态。严格定义让报告可信，宽松定义让报告变成噪音。

这三条不只适用于安全审计。任何需要 AI agent 做"判断"的场景——代码审查、测试生成、文档审核——都可以借鉴：让不同的 agent 互相制衡，承认单次运行的局限性，严格定义输出类别。

GitHub: https://github.com/cloudflare/security-audit-skill
许可证: MIT
Cloudflare 博客: Build your own vulnerability harness