Cloudflare 安全审计 Skill 怎么用？实测上手

Cloudflare Security-Audit-Skill 是 Cloudflare 官方在 GitHub 开源的 coding agent 技能包，装好后你只要在代码库里对 agent 说一句「security audit this codebase」，它就会按六个阶段把整个项目审一遍，最后输出带证据链的漏洞报告。安装只要一条命令，MIT 协议开源，个人和商用都免费。

这条信息很新：仓库在 2026 年 9 月 14 日刚更新过一次，最新提交说明是 Clarify guidance and full audit modes；仓库 2026 年 6 月首次提交，截至 2026 年 9 月 17 日约 8.9k Star、484 Fork。

它的来历也很清楚：Cloudflare 官方博客的漏洞挖掘流水线文章里描述的那套系统，而它就是那套系统的单仓库起点版本。

本文要点：

1. 一条命令安装，不需要改配置文件
2. 三种说法都能唤起审计，full audit 与 guidance 两种模式的区别
3. 六阶段流程逐段拆开讲，每个阶段产出什么文件
4. 实测踩坑：沙箱、Node 运行时、输出目录
5. 国内用户用什么宿主 agent 跑

Security-Audit-Skill 到底是什么

它不是一款能双击运行的软件，而是一个技能包：一组 Markdown 提示词加两个零依赖的 Node 校验脚本，由宿主 agent 按需读取。它的作用是把「审代码找漏洞」从一次随意的对话，变成一条有硬性约束的流程。想直接看源码可以打开 Cloudflare 官方仓库。

官方把设计原则写得很直白，两条一起看才完整：

1. 用确定性工程守住「不该出错」的环节，比如审哪些文件、哪些文件该过滤、规则怎么匹配、改动怎么分捆，全部由代码逻辑决定，不交给语言模型拍脑袋
2. 用 agent 负责「需要动态判断」的环节，比如读完整文件、搜索代码库、交叉查看其他改动文件、追溯调用链

理解这一点，你就明白它为什么比「让 agent 随便看看 diff」稳得多。

装之前要准备什么

三个前置条件，缺一个都跑不顺：

1. 一个支持工具调用、且能并行起子 agent 的 coding agent，Claude Code、Codex、Cursor、Kimi Code 这类都可以
2. 可用的 Node.js 运行时，因为 Skill 里两个校验脚本要靠它执行
3. 一个操作系统级沙箱，官方要求必须禁外网、使用白名单化的净化环境变量、强制资源限额、只允许写指定临时目录

第 3 条最容易被忽略。安全审计免不了要跑构建、测试甚至 fuzzer，如果直接在你的工作机上执行目标代码，风险比漏洞本身还大。没有这层隔离时，流程会把线索停在 needs_validation 状态而不是硬着头皮往下跑，这属于安全设计在起作用，不是 Skill 坏了。

Security-Audit-Skill 怎么装：一条命令

官方推荐用 Skills CLI 安装：

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

想装成用户级、所有项目都能用，加一个参数：

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

执行 npx skills --help 还能看到宿主 agent 选择和免交互安装的参数。装完不需要手写任何配置，Skill 会在 agent 启动时自动注册。

怎么唤起审计：三种说法都能触发

Skill 靠触发词自动激活，下面三种说法都能唤起，区别只在范围：

1. security audit this codebase，对整个代码库做完整审计
2. find security vulnerabilities in ./src，只审指定目录
3. do a security review, output to ~/audits/my-project，指定报告落到哪个目录

激活后有两种模式：明确提出「审代码 / 找漏洞 / 做渗透测试」会进入 full audit 模式，完整跑完六阶段并产出报告文件；只问一个安全问题、或做很窄的漏洞排查，则走 guidance 模式给建议，除非你主动要报告产出物。

报告目录如果不指定，默认落到 ~/security-audit-skill/仓库名/run-N，N 是第几次运行。只有你显式指定一个被版本控制忽略的目录，它才会把文件写进目标仓库内部。

六阶段审计流程拆解

这是整个 Skill 最值得看的部分。六个阶段各有明确产出物，不是流水账。

阶段 1 侦察：先把攻击面画清

产出 architecture.md 和 coverage-ledger.json 两份文件，内容包括架构、信任边界、输入面、历史证据和确定性覆盖清单。台账每次更新后，父 agent 都会跑一次 validate-coverage-ledger.cjs 校验格式，避免台账本身烂掉。

阶段 2 覆盖驱动的猎取

按台账里的单元分配隔离的 hunter 子 agent，每个 hunter 记录自己查了什么，再由 coverage critic 反过来找没覆盖到的缺口。这一步专门解决通用 agent 的老毛病：改动一多就开始选择性偷懒，只审一部分文件。

阶段 3 候选验证：只做证伪

每一个独立候选漏洞都交给一个全新的 verifier，而这个 verifier 的任务是证伪它，不是确认它。这是整套流程防误报的核心机制。

阶段 4 结构化输出

把结论写成 confirmed、needs_validation、rejected 三类记录，落到 findings.json，并用 report-schema.json 校验。三种结论含义严格区分：

1. confirmed，有完整来源追溯，且有观测到的有界结果
2. needs_validation，有一个明确未解决的事实，且不给严重级别
3. rejected，记录被证伪的候选

阶段 5 独立复核

再由全新 agent 复核最终的源码断言，涉及重大替换时还要再找一个独立 verifier 过一遍。每次替换后都要重跑 validate-findings.cjs。

阶段 6 目标中立的报告

从已复核记录和覆盖台账推导出三份报告：REPORT.md 总览、FINDINGS-DETAIL.md 已确认漏洞详情、NEEDS-VALIDATION.md 待验证线索。

跑完会拿到哪些文件

审计结束后目录里主要是三类东西：

1. 报告类，REPORT.md 总览、FINDINGS-DETAIL.md 确认漏洞详情、NEEDS-VALIDATION.md 待验证线索
2. 数据类，findings.json 机器可读结果、coverage-ledger.json 覆盖台账
3. 过程类，architecture.md 架构与信任边界记录

findings.json 走的是 report-schema.json 里定义的 schema，所以你可以直接写脚本把它转成内部工单或 GitHub Issue，不用再从报告里手工抄。

为什么它坚持「让另一个人验证自己的发现」

这是整套设计里最值得学的一条原则：检查发现的人，永远不能是发现它的人。

道理不难懂。同一个 agent 找完漏洞再自证，很容易顺着刚才的思路把误报说圆；换成全新上下文的 verifier 专门去证伪，误报率会明显下降。官方 README 里还给了一条实测经验：同一仓库多跑几次结果可以叠加，在他们的测试里，单次运行大约只找到重复运行总量的一半漏洞。

另外两条原则也建议记住：

1. 严重级别必须由影响推导，靠可能性乘以影响，而不是「和检查清单对不上就算漏洞」
2. 纵深防御缺口不算漏洞，如果 A 层已经挡住了攻击，B 层缺失只能算一条加固建议

实测踩坑与加固建议

1. 沙箱是第一道坎。没有隔离环境时流程会大量停在 needs_validation，看起来像什么都没查出来，其实是安全设计在拦
2. 输出目录别写进仓库。默认落到 ~/security-audit-skill/ 是有意为之，如果非要指定到仓库内，务必确认该目录已被 .gitignore 忽略
3. Node 版本要够新。两个 .cjs 校验脚本本身零依赖，但仍需要可用的 Node 运行时
4. 一次别审巨型仓库。先用 find security vulnerabilities in ./src 收窄目录，跑通再放大范围，token 和时间都省

国内用户怎么用

安装时要从 GitHub 拉取，需要能访问 GitHub 和 npm 源，这一步用国内镜像或代理即可。装好之后审计过程全部在本地执行，不依赖 Cloudflare 的在线服务，所以不存在用着用着被墙的问题。

宿主 agent 建议选支持子 agent 的，这一步可以对照站内的 Skill 安装类教程：

• frontend-design skill 怎么装怎么用
• gc-minimal-zine-poster Mac 安装教程
• ffmpeg-skill 怎么用？一条命令装上视频剪辑
• 卡兹克的 AI Skill 实践合集，含 storage-analyzer

想先拿一个门槛更低的 Skill 练手，可以看 Cloudflare 钱包申请实测。