共计 5565 个字符，预计需要花费 14 分钟才能阅读完成。
截至 10 月 25 日上午，cloudflare/security-audit-skill 在 GitHub Trending 日榜和周榜上都排第一：当天新增 2,264 个 star，本周新增 12,680 个，总数 44,664。
它是一个装进 AI 编程助手里的“技能”（skill）。装好之后，你对助手说一句“security audit this codebase”，它就会按六个阶段给你的代码做安全审计，每个可疑问题都要交给另一个独立的 agent 去复核，最后输出机器可读的 JSON 和几份 Markdown 报告。
有意思的是，这个仓库 6 月就公开了，最后一次提交停在 9 月 15 日（北京时间），到现在一个多月没有新代码，也没有正式 release。它是这几天又重新火起来的。
它从哪来
6 月 18 日，Cloudflare 在官方博客发了一篇《Build your own vulnerability harness》，作者之一 Dan Jones 也是这个仓库的主要提交者。文章讲的是他们怎么用 AI 在自家代码库里成规模地找漏洞，security-audit-skill 就是同一天放出来的。
博客里说，整个系统一开始只是一个大约 450 行的 security-audit 技能，在单个仓库上跑，反复调提示词，直到能挖出真实的 bug。后来他们把每个阶段拆成独立的 agent，后面接数据库、前面加调度器，用大约六周扩展成能覆盖 128 个仓库的扫描系统。博客原话的意思是：真正的价值在提示词里，后来的大系统还在沿用最初技能里的攻击场景、漏洞类别和反模式检查。
这个单仓库版本也碰到过天花板，博客列了三条：
- 上下文用完。跑一个小时，上下文窗口满了，模型会忘掉前面追到的线索。
- 没有持久化。中途崩一次就得从头来。
- 看不到跨仓库的关系。
博客还给了一个数据：单次运行大约只能找到多次运行总数的一半，而且找到的偏简单。README 里也写了同样的结论。
所以这个仓库的定位很清楚：它是 Cloudflare 大系统长出来之前的那颗种子，适合拿来审一个仓库。他们内部那套全量扫描系统并不在这个仓库里。目前我没查到那套系统有开源的消息。
时间线大致是这样：
- 2026-06-18：仓库创建，官方博客同日发布
- 2026-07-10：博客文章上了 HN，72 分
- 2026-09-10：合并 PR #12，审计流程、findings 格式和校验脚本整体重写
- 2026-09-15：最后一次提交，补充“指导模式”和“完整审计模式”的说明
- 2026-09-17：仓库本身上了 HN，213 分
- 2026-10-09：一篇第三方试用文章记录的 star 数约 2.67 万
- 2026-10-25：日榜、周榜双第一，总 star 44,664
这次为什么又火了
我先说结论：没查到明确的触发原因。
我查了这几处。GitHub 上，9 月 15 日之后没有新提交、没有 release。Cloudflare 博客我没找到 10 月关于这个技能的新文章。HN 上能找到的两次讨论都在 7 月和 9 月。X 上 10 月 24、25 日的相关帖子很多，但大多是“今天 GitHub 榜首”这类转述，属于上榜之后的结果。
有两件同期的事可以当背景，但我没有证据说它们就是原因：
- 10 月 22 日，X 账号 @ClaudeDevs 发帖说把 Agent Skills 标准捐给 Agentic AI Foundation，并提到已有 70 多个 agent 平台接入这个标准。skill 这个形式这几天讨论度很高。
- 仓库的 issue 区 10 月一直很活跃，10 月 11 日到 24 日之间有不少新 issue，有人在报校验脚本和流程规则的问题。说明一直有人在实际跑它。
另外从 star 数看，10 月 9 日约 2.67 万，到 10 月 25 日 4.47 万左右，涨得比较持续，不像某一天被一个帖子突然引爆。这是我根据两个时间点的数字做的推测，仅供参考。
六个阶段分别做什么
按 README，一次完整审计分六步：
- 侦察（Reconnaissance）：梳理架构、信任边界、输入面和已有证据，写出
architecture.md和coverage-ledger.json。后者是一张“覆盖台账”，把要查的单元一条条列出来。 - 按台账搜漏洞（Coverage-led hunting）：从台账里分配单元给彼此隔离的“猎手” agent，记录每个猎手查了什么，再由“覆盖评审”找出漏查的地方。
- 候选验证（Candidate validation）：每个候选漏洞交给一个全新的验证 agent，它的任务是想办法推翻这个结论。
- 结构化输出（Structured output）：结果写进
findings.json，分confirmed、needs_validation、rejected三类，并用report-schema.json校验格式。 - 独立记录复核（Independent record verification）：再派新的 agent 核对最终结论引用的源码。如果结论有实质替换，还要再找一个独立复核者。
- 生成报告（Target-neutral reporting）：根据复核后的记录和台账，生成
REPORT.md、FINDINGS-DETAIL.md和NEEDS-VALIDATION.md。
三种结论的区别值得记一下：
confirmed：有完整的源码追踪和实际观察到的结果。needs_validation：源码路径能追到，但还差一个关键事实没确认（比如生产环境配置），这类不给严重等级。rejected：候选被推翻了。
仓库里带了两个零依赖的 Node.js 校验脚本，validate-coverage-ledger.cjs 和 validate-findings.cjs，负责机械地检查台账和结果文件的格式。
我觉得最值钱的两个设计
找问题的和查问题的永远不是同一个 agent。 README 的设计原则里写得很直白。博客里讲了原因：如果让发现者自己评分，它会很自信地确认自己输出的一切。AI 审计最让人头疼的就是误报，这个设计直接针对这一点。
宁可标“待确认”，也不硬下结论。 跑目标代码需要一个操作系统级别的沙箱：断外网、环境变量走白名单、限制资源、只允许写指定的临时目录。没有这样的沙箱，技能不会去执行目标代码，只会把线索留在 needs_validation。这对使用者是好事，报告里 confirmed 的那几条可信度会高很多。
还有一条我很认同：“纵深防御缺一层不算漏洞”。如果 A 层已经挡住了攻击，缺 B 层只算加固建议。这能少掉很多看着吓人、其实打不进来的“漏洞”。
怎么装、怎么用
下面的步骤来自仓库 README。我还没有在自己的项目上完整跑过一轮，所以只写 README 里写明的内容。
准备条件
- 一个支持工具调用和并行子 agent 的编程助手，比如 Claude Code、Codex 这类
- 本机装好 Node.js，用来跑两个校验脚本
- 如果想让它真的执行目标代码做验证，需要准备上面说的隔离沙箱。没有也能跑，只是更多结果会停在“待确认”
第一步：安装技能
用 Skills CLI 安装到当前项目：
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit
想装到用户级别、所有项目都能用，加上 --global：
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit \
--global
选择装给哪个 agent、非交互安装等选项，可以看 npx skills --help。
第二步：在要审计的代码目录里启动编程助手，直接说需求
README 给的示例：
security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project
请求匹配到“安全审计、找漏洞、渗透测试代码”这类意图时，技能会自动启用。
第三步：分清两种模式
- 直接要求审计整个代码库或做渗透测试，会进入完整审计模式，走完六个阶段并生成报告文件。
- 只是问安全问题、或者盯着某一个漏洞，会进入指导模式，不产出报告文件，除非你明确要。
第四步：去哪找结果
完整审计模式下，如果你没指定输出目录，结果默认写到 ~/security-audit-skill/<仓库名>/run-<N>。只有你明确指定了一个被版本控制忽略的目录时，它才会往目标仓库里写东西。
第五步：多跑几次
对同一个仓库重复运行，结果是累加的。技能会读之前的台账和结论，专门补漏查的地方，源码改过的部分会重新验证。前面说过，单次运行大约只能找到多次运行总数的一半。
看结果时，我的建议是先读 REPORT.md 了解全貌，再重点看 confirmed 的条目，NEEDS-VALIDATION.md 里的条目当作待办清单逐个人工确认。
社区怎么看
HN 9 月那次讨论有 38 条评论，几种声音比较有代表性：
- 成本。有人问要花多少 token，也有人说在一个中等规模的代码库上花了 100 万 token，没得到想要的结果。
- 提示词被拒。有安全从业者提醒，把任务明确写成“安全研究”的审计技能，有时会触发头部模型的防滥用拒答。他的做法是按 bug 类型拆成不带安全字眼的技能，再用一个技能汇总判断。
- 上下文占用。有人建议 Cloudflare 把官方的多个技能合并，避免占用太多上下文；也有人认为往提示词里塞大量 schema 会推高 token 和延迟。
7 月博客那次讨论里，有人问“harness 到底是什么，为什么需要”，这个问题其实正好说明这类工具的门槛不低。
另外，日本的 Metronome.fm 团队 10 月 9 日发了一篇试用记录。他们用它审了自家网站，得到两条“待确认”结果：离线缓存页面的内容和清理方式，以及发送错误日志用的 token 放在哪。两条他们都人工核实并当天改掉了。他们也提到，在 macOS 上满足不了它的沙箱要求。
我的看法
我觉得它最大的价值，是把一套“怎么用 AI 做安全审计”的方法论摊开给你看。台账怎么列、猎手怎么分、谁来推翻谁、什么才算 confirmed，这些写在一堆 Markdown 提示词里，你可以直接读，也可以改成适合自己团队的版本。博客也明说了，这个技能本来就是让你当起点用的。
它能替你做的：在上线前或者大改之后，帮你系统地过一遍攻击面，把值得人工看的地方列出来，并且尽量告诉你哪些已经验证过。
它替代不了的：人的判断，以及正式的安全审计。needs_validation 和 confirmed 之间的那道坎，往往就是生产环境的真实配置，这一步还得你自己确认。我也不建议把报告结果直接当结论贴出去。
我认为最适合用它的是两类人：一是独立开发者和小团队，没有专职安全人员，但有一个对外的 Web 服务或 API；二是已经在用 Claude Code、Codex 这类工具写代码的人，顺手让它审一遍成本不高。
几个注意点：
- 预算。它会并行拉起很多子 agent，token 消耗不小，先拿小项目或一个子目录试。
- 隐私。技能跑在你自己的编程助手里，代码会发给你助手所用的模型服务商。公司代码要先确认这一点是否允许。
- 沙箱。不要为了“让它验证得更彻底”就在本机裸跑目标代码，README 的沙箱要求是有道理的。
- 项目状态。仓库一个多月没更新，仓库有 32 个未关闭的 issue 和 54 个未合并的 PR，其中有人报了校验脚本和流程规则的矛盾。用之前可以先翻一下 issue。
下一篇我打算拿一个自己的小项目实际跑一遍，把安装、输出和人工复核的过程完整记下来。感兴趣的话可以收藏本站，或者订阅更新。
参考来源
- 仓库主页与 README：https://github.com/cloudflare/security-audit-skill
- 提交历史：https://github.com/cloudflare/security-audit-skill/commits/main/
- Issue 列表：https://github.com/cloudflare/security-audit-skill/issues
- 仓库数据（创建时间、最后推送、fork 和 issue 数）：https://api.github.com/repos/cloudflare/security-audit-skill （2026-10-25 上午查询，总 star 44,669、fork 2,771、未关闭 issue 32、未合并 PR 54，API 的 open_issues_count 86 是两者合计）
- GitHub Trending 日榜与周榜：https://github.com/trending （2026-10-25 09:56 北京时间抓取）
- Cloudflare 官方博客《Build your own vulnerability harness》：https://blog.cloudflare.com/build-your-own-vulnerability-harness
- HN 讨论（仓库，213 分，2026-09-17）：https://news.ycombinator.com/item?id=49736466
- HN 讨论（博客，72 分，2026-07-10）：https://news.ycombinator.com/item?id=48854681
- Metronome.fm 试用记录（2026-10-09）：https://metronome.fm/blog/en/cloudflare-security-audit-skill
- @ClaudeDevs 关于捐赠 Agent Skills 的帖子（2026-10-22）：https://x.com/ClaudeDevs/status/2113328526413996100
