Cloudflare 开源了一套安全审计 Skill，让编码智能体自己去挖漏洞

原文来源：cloudflare/security-audit-skill — Cloudflare 把驱动自家漏洞挖掘 harness 的那套审计流程开源成了一个编码智能体 Skill，六个阶段走完一轮代码审计，产出的结论可以机器校验。

用编码智能体找漏洞这件事，多数人的做法是把代码丢给它、问一句「这里有什么安全问题」，然后收到一堆似懂非懂的清单。Cloudflare 开源的这套 security-audit Skill 想解决的就是这个环节——让审计有流程、有证据、有可复核的结论。

它不是扫描器，也不接 SAST 引擎。它做的事是把一个结构化的审计方法论塞进编码智能体的上下文，让 agent 按阶段推进，并且用几个零依赖的 Node.js 校验脚本卡住中间产物。

六个阶段和三种结论

整个流程分六步：侦察（reconnaissance）、按覆盖率驱动的猎取、候选验证、结构化输出、独立记录验证、以及不偏向特定目标的报告。

每个候选结论最终只能落在三种判定里：

• confirmed：有完整的源码追踪链，加上范围明确的实测结果
• needs_validation：还剩一个明确的未解决事实，此时不允许给出严重性等级
• rejected：被证伪的候选

这套划分的好处在于，它不给「看起来像漏洞」的东西留位置。要么证据链闭合，要么老实说还缺什么——缺的那一步写得越具体越好，因为下一个 agent 要接着往下查。

最狠的一条规则

README 里列了六条设计原则，其中最反直觉的是对抗式验证：检查某个结论的智能体，永远不能是发现它的那一个。同一份上下文里自问自答，只会把误判越描越真。

另外几条同样在限制「虚报」：

• 只确认已经确立的边界失效
• 有源码支撑但跑不通的线索，保留成 needs_validation，并写清那个确切没解决的事实
• 严重性必须有影响力支撑——按「可能性 × 影响」算，而不是对着清单打勾
• 纵深防御的缺口不算漏洞。如果 A 层已经挡住了攻击，B 层的缺失只是一条加固建议，不是漏洞
• 多轮运行是可累加的。Cloudflare 在测试中发现，单轮大约只能找到重复运行能找到总量的一半，所以 skill 会用上一轮的 ledger 和 findings 去找空白、重新验证改动过的源码，并且不会把过期或未解决的条目当成已覆盖

最后一条尤其重要：它把「覆盖了多少」和「确认了什么」分开记账，审计过程本身也变成了可审计的对象。

目录结构：一份按攻击面拆开的作战手册

Skill 由一堆 Markdown 提示词加几个校验脚本组成，攻击类别切得很细：

除了 SKILL.md 讲总纲和「反模式」，剩下的是 HUNTING.md（怎么编排猎取）、RECONNAISSANCE.md（侦察提示词与综合）、ATTACK-CLASSES.md（把提示词分成核心、通配和「显而易见」三类），以及 VALIDATION-AND-REPORTING.md（后三个阶段）。

两个校验脚本都是零依赖的：validate-coverage-ledger.cjs 由父 agent 在创建覆盖率台账后以及之后每次更新台账后运行，validate-findings.cjs 则在 Phase 4 和每次 Phase 5 替换之后运行。仓库里还带了和它们对应的测试文件。

怎么装、怎么用

安装走 skills 生态的通用方式：

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

加 --global 则装到用户级，所有项目都能用。

用法上不需要记什么特殊命令。在目标代码库里（或把 agent 指向目标代码库）启动编码智能体，然后直接说人话：

security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project

请求命中触发条件时 skill 会自动激活。完整的代码库审计或渗透测试请求走「完整审计模式」；单纯问安全问题或者做局部排查则走「指导模式」，除非你明确要求输出报告文件。完整审计模式下如果不指定输出目录，默认落在 ~/security-audit-skill/<仓库名>/run-<N>。默认情况下所有产物都写在仓库外面，只有你显式选一个被版本控制忽略的目录时，它才会往目标仓库里写东西。

三个前置条件，缺一个就降级

README 把运行要求写得很直白，值得照着检查一遍：

1. 一个支持工具调用和并行子代理的模型
2. Node.js，用来跑那两个零依赖校验器
3. 操作系统级别的沙箱——因为流程要执行目标项目控制的构建、测试、进程、浏览器、模拟器和 fuzzer。沙箱必须禁用对外网络、使用白名单化的干净环境变量、强制资源上限，并且只允许写入分配到的那块临时目录

第三条是硬约束。如果沙箱控制不了这些，skill 不会去执行目标代码，而是把线索统一保留成 needs_validation。这个设计挺有意思：能力不足的时候它选择降低结论强度，而不是赌一把。

适合谁

这套东西面向的是能接受「审计结论需要证据链」的团队。它不产出那种「发现 37 个高危问题」的概览式报告，换来的是每条结论都能回溯到源码和实测结果，而且验证者和发现者被强制分开。

反过来说，如果你的目标只是给依赖树做一次 CVE 扫描，或者只想要一份快速体检，这套流程偏重了——它要跑多个阶段、多轮迭代，还要准备沙箱。它真正的价值场景是有一定规模的代码库、需要定期做深度审计、并且愿意为「结论可信」付出额外算力的团队。