把安全审计做成一份能复用的 Skill:这个仓库值得花半小时看懂
2026 年 9 月 20 日的 GitHub 趋势页上,cloudflare/security-audit-skill 单日 +2,375★,是当天整页增星最多的一条(页面排序第 3)。仓库元数据(取数时间 2026-09-20 21:35):17,494★、967 fork、44 个 open issue、MIT 协议、2026-06-18 创建、最后一次提交 09-14、主分支 14 次提交、3 位公开贡献者、无 release 无 tag,顶层只有三样东西:LICENSE、README.md、skills/security-audit/。
数字不算最唬人,但它的出身比数字重要:
这不是又一个人写的提示词合集,而是 Cloudflare 自己那套漏洞挖掘流水线(Vulnerability Discovery Harness)的起点版本——先在一台机器上跑通了一个仓库,再被抽成流水线的。他们 6 月 18 日的官方博文《Build your own vulnerability harness》把过程写完了,顺手把最初那份约 450 行的 Skill 清理干净放了出来。
博文里有句话把这个 Skill 的定位说得很准:“流水线是会换模型的那部分,Skill 里的提示词才是留下来的那部分。” 下面把仓库拆开,拆到你能判断自己该不该装。
一句话定位:它是一份"审计流程说明书",不是扫描器
- 它本身不扫任何东西:仓库里没有二进制、没有规则引擎、没有 CVE 库,只有 Markdown 提示词 + 两个 JavaScript 校验器。真正干活的是你本地的编码 Agent(Claude Code、Codex、OpenCode、Cursor 这类支持子 Agent 的客户端)。
- 它管的是"流程"和"证据标准":什么时候做侦察、谁去攻击、谁来反证、什么算确认、什么只能算待验证,全部写死在文档里,不让模型自由发挥。
- 它是 agent 中立的:SKILL.md 里只写"Parent / Task tool / research agent / general agent"这种角色词,不绑定任何一家客户端,换成等价能力即可。
- 一句话概括:它把"给 Agent 一句『帮我查查有没有漏洞』“这件靠运气的事,变成了一份有阶段、有产物、有校验、有驳回规则的作业流程。
仓库里到底有什么:15 份 Markdown + 2 个零依赖校验器
skills/security-audit/ 目录一共 20 个文件,规模如下(字节数取自 GitHub API 目录接口):
| 文件 | 作用 | 大小 |
|---|---|---|
SKILL.md | 入口:模式、平台术语、执行安全规则、六阶段总览、10 条反模式 | 22.0 KB |
RECONNAISSANCE.md | 第 1 阶段侦察提示词与综合指令 | 15.9 KB |
HUNTING.md | 第 2 阶段编排、狩猎方法论、验证规则 | 22.4 KB |
ATTACK-CLASSES.md | 核心 / 通配 / 显而易见三档攻击类提示词 | 15.7 KB |
VALIDATION-AND-REPORTING.md | 第 3-6 阶段:验证、结构化输出、记录复核、出报告 | 17.8 KB |
WEB-PROTOCOL-AND-AUTH.md | HTTP 请求分帧、缓存、认证协议类 | 12.3 KB |
MEMORY-SAFETY-AND-BINARY.md | 内存安全、二进制、内核类(原生目标) | 10.5 KB |
AI-AND-LLM.md | 提示注入、Agent/工具、输出处理类(LLM 目标) | 10.6 KB |
CLIENT-SIDE.md | DOM 注入、消息信任、UI 重定向、原型污染 | 8.6 KB |
CLOUD-AND-DEPLOYMENT.md | IAM、IaC、容器、Serverless、入口与运行配置 | 8.3 KB |
SUPPLY-CHAIN-AND-RELEASE.md | 依赖、CI、发布、签名、更新、插件、扩展 | 7.3 KB |
DATA-ISOLATION-AND-LIFECYCLE.md | 多租户隔离、缓存、搜索、导出、备份、迁移、删除 | 7.8 KB |
PROTOCOLS-RPC-AND-MESSAGING.md | RPC、序列化、队列、Broker、Webhook、流式协议 | 7.5 KB |
RESOURCE-EXHAUSTION-AND-AVAILABILITY.md | 共享资源、配额、队列、Worker、可花费成本 | 7.5 KB |
DESKTOP-MOBILE-AND-LOCAL-IPC.md | 原生应用、深链、WebView、导出组件、守护进程、本地 IPC | 8.7 KB |
report-schema.json | 三种裁定的 JSON Schema | 14.5 KB |
validate-findings.cjs(+ 测试) | 零依赖校验器,查 findings.json 合不合 schema | 28.8 KB / 26.4 KB |
validate-coverage-ledger.cjs(+ 测试) | 零依赖校验器,查 coverage-ledger.json 的覆盖声明 | 33.5 KB / 28.5 KB |
几点值得单独说:
- 15 份 Markdown 加起来约 18.3 万字节,其中攻击类文档 11 份,是按目标类型分域的(Web 协议、LLM 应用、客户端、云与部署、供应链、数据隔离……),不是一份通用清单抄十遍。
- 两个校验器是"零依赖"的 Node 脚本,还各自带测试文件——它们管的是机械正确性(文件路径在不在、补丁和测试能不能解析、覆盖声明成不成立),不交给模型判断。
- 没有 release、没有 tag:仓库就是 main 分支在推进,最后公开提交是 2026-09-14 的"澄清 guidance 与 full audit 两种模式”,所以别指望版本号,要跟就跟 main。
六阶段流程:每一步谁干活、交付什么
README 把流程写成了六阶段,摘要如下:
- 侦察(Reconnaissance):把架构、信任边界、输入面、历史证据、确定性覆盖单元写进
architecture.md和coverage-ledger.json。 - 按覆盖表狩猎:从覆盖账本里切片,派独立的 hunter 出去,记录每个人查了什么,再用 coverage critic 找漏洞盲区。
- 候选验证:每一个候选都交给一个全新的 verifier,任务不是确认,而是想办法反证它。
- 结构化输出:把
confirmed/needs_validation/rejected三类记录写进findings.json,并对report-schema.json校验。 - 独立记录复核:换一批新 Agent 复核最终的源码断言;如果有实质性替换,还要再过一次独立验证。
- 中立出报告:从已复核的记录和覆盖账本推导出
REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md,报告里不带"去打这个线上地址"这类可执行攻击指引。
配套一条纪律写在 SKILL.md 的"执行安全"一节里:源码检查只读;任何目标代码的构建、测试、浏览器、模拟器、fuzzer 必须在操作系统级沙箱里跑——禁外网、空环境加白名单变量、目标代码只能写自己的 scratch/、限制 CPU/内存/进程/文件大小/磁盘/墙钟;这些控制只要有一样落不了地,就不执行目标代码,直接记成 needs_validation 并给出安全验证方案。
三种裁定:这是它和"AI 帮你查漏洞"最本质的差别
| 裁定 | 含义 | 有没有严重等级 |
|---|---|---|
confirmed | 有完整的来源追溯链 + 有界的实测结果(不是"理论上可以") | 有,且严重等级不得高于实测影响 |
needs_validation | 有明确、无法在源码内解决的事实缺口(比如部署配置不在仓库里) | 没有,不许给等级 |
rejected | 候选被反证掉了,如实记录 | 不适用 |
三条硬规则值得抄到你自己的流程里:
- 找到问题的人不能自己确认:README 原话是"the agent that checks a finding is never the agent that found it"。
- 纵深防御缺口不算漏洞:A 层已经拦住了攻击,B 层缺不缺,只能写成加固建议。
- 多次跑才有覆盖率:官方实测口径是"单次跑大约只能找到多次跑合计的一半",而且单次找到的偏简单、偏显眼。这一条直接决定你的 token 预算要乘几倍。
怎么用起来:三条命令以内
官方给的安装方式是 Agent Skills 生态的 CLI:
| |
装完在你想要审计的代码库目录里启动编码 Agent,用这三种口令触发:
security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project
- 它默认是"顾问模式":只是问一个安全问题时,它不会自动跑完整流程、不会建目录、不会写审计产物。只有当你明确要求"审计整个代码库 / 做渗透测试 / 完整端到端评审 / 要报告产物"时,才进完整模式。请求模糊时它会反问一句再动手。
- 完整模式默认输出到
~/security-audit-skill/<仓库名>/run-<N>;只有你明确指定、并且父级确认该目录被版本控制忽略时,才会往仓库里写。 - 环境要求三条:① 编码 Agent 的模型要支持工具调用和并行子 Agent;② Node.js(给两个校验器用);③ 一个操作系统级沙箱。第 ③ 条不是建议——缺了它,流程会退化成把大量结论标成 needs_validation。
和"一句提示词"、“代码评审工具"差在哪
| 维度 | security-audit-skill | 给编码 Agent 一句"查查漏洞” | 阿里的 open-code-review |
|---|---|---|---|
| 定位 | 安全审计流程与证据标准 | 一次随缘的对话 | 代码评审(不是安全审计) |
| 流程 | 六阶段固定,覆盖账本驱动 | 无固定阶段 | 按规则匹配 + 文件打包 |
| 验证方式 | 独立 verifier 主动反证,找到的人不许确认 | 找的那一个自己说了算 | 定位与反思模块治行号漂移 |
| 输出 | findings.json + schema 校验 + 三份报告 | 一段自然语言 | 带行号的结构化评审意见 |
| 上下文控制 | 每个 hunter 只干一件事,共享文件只由父级写 | 单会话,几十个文件就塞满 | 并发 sub-agent 分包 |
| 失败模式 | 大量 needs_validation(诚实但不出结论) | 自信地报出一堆假洞 | 官方自评:精确率高、召回率低 |
| 适合场景 | 有真实攻击面的自有代码库 | 快速过一眼 | 每次提交/CI 的评审门禁 |
对照表里第三列的数据来自我们 9 月 16 日拆 alibaba/open-code-review 时核过的官方口径(精度优先、召回率更低、token 约通用 Agent 的 1/9)。两个项目不冲突:open-code-review 是"每次提交都要跑"的轻量闸门,security-audit-skill 是"一段时间跑一次的重量级排雷"。
Cloudflare 公布的数字:哪些能用来判断,哪些只是自述
博文里的运行数据很具体,但它属于团队自述、没有第三方复现,读的时候要分清:
| 数字 | 内容 | 性质 |
|---|---|---|
| 20,799 → 12,057 | 原始候选 → 通过独立验证 | 自述,流水线全量口径 |
| 13,841 / 145 | 进验证系统后的总池(仓库数) | 自述 |
| 5,442 | 被去重折叠掉的条数 | 自述 |
| 7,245 | 最终可执行的条数 | 自述 |
| 40% → 11% | 首次验证拒绝率下降 | 自述,归因于侦察阶段上下文注入变好 |
| 35% → 58% | 高可信占比上升 | 自述 |
| ~450 行 → 128 个仓库 | 从一个 Skill 长到全舰队扫描,约 6 周 | 自述,工程事实 |
| 单仓基准 | 3 万行代码 → 约 100 条候选、3-4 小时;压缩到 80 条;修一条约 5 分钟;全流程约 14 小时 | 自述,单次跑 |
| 25,472 次 | 全舰队对"愿望清单"的写入次数 | 自述 |
| 0 次 | Semgrep 接进流水线后一个月被 Hunter 调用的次数 | 自述,但这条很说明问题 |
| 14 小时 | 最差一次单仓运行时长 | 自述 |
三条我觉得最有信息量的:
- 他们明确不宣称召回率。原话大意是:没有标注过的"全量真 bug 集合",任何 recall 数字都是猜的,只能看"重跑还能不能找到新洞"“覆盖单元还在不在长”。这种自我克制在 AI 安全工具的宣传里很少见。
- 静态分析被 Agent 无视了。Semgrep 全链路接好、跑了一个月、Hunter 调用 0 次——Agent 宁愿自己读代码、编译、跑起来打。这条对自建流水线的人是现成的经验:先看 Agent 真正去用什么,再补工具。
- 成本形状是"hunt 阶段吃掉几乎全部算力",追加一轮的成本大约是首次 hunt 的一半,所以他们按仓库给预算、Worker 池开 50-200 个,把大扫描做成"周期性批量排雷"而不是"每次 PR 都跑"。单仓复杂时一次能跑十几个小时。
还有一条落地时容易卡住的细节:沙箱基于 unshare;如果流水线本身跑在 Docker 里,容器需要 seccomp=unconfined 和 apparmor=unconfined,否则沙箱会静默起不来——官方自己说他们在这上面栽过。
坑与边界:装之前先知道这几条
- star 数不等于对你的库有效。17.5k 星反映的是 Cloudflare 的名气和"安全审计 + Agent Skills"这个交叉点很热,不是你那份代码的收益。
- 它产出的东西不是"修好的代码"。这个 Skill 只描述修法、不改目标源码;自动改代码并跑回归的是流水线第二阶段(Fixer),那部分没有开源。指望"一键修漏洞"的人会失望。
- 没有沙箱,价值砍半。上一条执行安全规则会把大量结论压成 needs_validation,你拿到的是一堆"待验证"而不是"已确认"。
- 单次跑覆盖有限是设计事实,官方自己说单跑只覆盖多次跑合计的一半左右。想靠一次跑出完整结论,等于浪费这次预算。
- 它不是渗透测试的替代品。报告的定位是"给代码所有者:来源证据 + 安全复现 + 优先级 + 最小改动",明确禁止去打线上端点、共享环境、他人数据。合规审计、外部渗透这类有法律与授权边界的活,它替不了。
- 迭代靠 main 分支,没有 release 可钉。想稳定复现,自己 fork 一个 commit 固定下来。
我的判断:谁该上、谁再等等、谁别碰
该上
- 自己维护有对外接口的服务端代码的人:自建 API、Web 后端、带鉴权的多用户系统。这类代码的攻击面是真实的,而且很多人从来没有第三方审过。
- 在维护有一定用户量的开源项目的人:它给的产物是有 schema 的 JSON + 三份报告,拿去回帖、开 issue 都站得住,不像一段 AI 生成的"我觉得这里可能有问题"。
- 已经在用 Claude Code / Codex 这类客户端、且能配出隔离环境的人:装上就能用,边际成本只有 token。建议先拿
quickprofile 或一个子系统做小范围试跑,再决定要不要全库。
再等等
- 纯静态站、无后端无鉴权的人:攻击面和收益都太小,装它不如把 Hugo 的依赖升级做完、把 nginx 配好。
- 没有隔离环境、但想跑完整流程的人:可以装,但做好心理准备——大部分结论会是 needs_validation,你得自己补环境这一课。
- 把成本当第一约束的人:一次完整跑是几十到上百个 Agent 调用,先在便宜模型上试编排,别拿主力模型烧第一轮。
别碰
- 打算把它当"上线前最后一关"的人:它是排雷的辅助,不是合规审计的替代;真上线要签字的场景,还得走人工与专业审计。
- 想让它自动改代码并直接提 PR 的人:开源部分做不到,能做这件事的那套系统没放出来。
- 打算拿它去扫别人系统的人:Skill 里明写了不碰部署端点、不做共享环境测试、不做可用性压测——越界就是另一回事了。
顺带一提:安全审计跑完,别忘了给自己配一套顺手的装备——长期盯着代码的人,机械键盘怎么选按手感和预算分了档。
本文由拾光札记编辑部整理,勘误请联系我们。
本文事实取自 GitHub REST API(仓库元数据 / 目录 / 提交 / 贡献者,取数时间 2026-09-20 21:35-21:50)、GitHub 趋势页当日快照、仓库 README.md 与 skills/security-audit/SKILL.md,以及 Cloudflare 官方博文《Build your own vulnerability harness》(2026-06-18)。文中所有运行数据均为 Cloudflare 团队自述、无第三方复现,已在上文表格中逐条注明性质;star / fork / issue 数实时变动,以仓库页为准。本文按官方 README 与官方博文写成,未在本机部署流水线。
站内可对照阅读: