文章总结： Cloudflare开源安全审计Skillsecurity-audit-skill，通过六阶段流程将AI审计转化为可核查流水线。实测埋入7个漏洞全部被找出，核心价值在于覆盖率台账、结构化输出、发现与验证者分离的对抗性验证及沙箱强制要求，将AI幻觉从能力问题转为流程问题。建议接入CI/CD多次运行累加覆盖率，适用于需证据链的审计场景。
综合评分： 85
文章分类： AI安全,安全工具,代码审计,安全建设
Cloudflare开源了一个一万星的挖洞Skill：我埋了7个洞，它全找出来了，但它最值钱的地方不是“找漏洞”
原创
klsec
klsec
昆仑AI安全实验室
2026年9月29日 16:00
广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
有人把AI安全审计这件事，做成了一条可以被核查的流水线。
2026年9月14日，Cloudflare在GitHub上开源了security-audit-skill。一个MIT协议、纯Markdown加两个零依赖JavaScript校验器组成的“技能包”。上线两天冲上Hacker News首页，单日新增超过3600颗星，目前稳定在13000星以上。
我拿到之后做的第一件事，不是跑它，是在代码里埋了7个已知漏洞，看它能不能全找出来。
先摆数据：7个洞，229行代码，30分钟上限
有一个安全博主做了和我一样的测试。他写了一个229行的内网小服务，故意在里面埋了7个已知漏洞，然后把Cloudflare的security-audit-skill装进编码Agent，让它自己按流程审一遍。
结果是：7个植入点全部被找出，每一条都附带了沙箱实证，其中6条在停表之前已经通过了独立验证。 同时，它还推翻了一条自己猎手提上来的误报，诱饵里“缺安全响应头”那条没有被凑数成漏洞。
代价是什么？30分钟的上限，两轮都被撞了。 对于一个小仓库的日常体检来说，这个耗时不太友好。
但真正让我觉得这东西值得认真聊的，不是“7个洞全找到了”。是它的产物机制。
六阶段里，最值钱的不是“找漏洞”那一步
security-audit-skill把一次完整审计拆成了六个阶段：侦察→覆盖导向狩猎→候选验证→结构化输出→独立记录验证→目标中立报告。
大部分人看到这个流程，第一反应是“第三阶段验证最重要”。错了。验证阶段做的事情是“把误报筛掉”，这确实有价值，但它依赖的是模型自身的判断力。
真正值钱的是第一阶段和第四阶段。
第一阶段侦察阶段，它产出两个东西：architecture.md和coverage-ledger.json。前者是架构、信任边界、输入面的地图，后者是一份覆盖率台账——它把“要审什么”从模糊的“代码库”拆解成一个个具体的“覆盖单元”。
什么意思？意思是它不承诺“我审完了整个代码库”。它承诺的是：“我在这份台账上标记了这些覆盖单元已审，这些未审，这些审过但被推翻了。”未审的部分是透明的。 你拿到报告之后，能清楚地知道“它没看哪些地方”，而不是拿着一个“All clear”的结论蒙在鼓里。
第四阶段结构化输出，它把每一个发现写入findings.json，并用零依赖的Node.js校验器validate-findings.cjs按JSON Schema校验。校验器检查的是证据的“形状” ：指纹必须唯一，测试路径必须从入口点开始、到影响点结束。一条声称“confirmed”的发现，如果它的路径追踪不成立，会被校验器直接拒绝。
还有一个设计，GitHub README里写得很清楚：发现者和验证者必须是不同的Agent。 找到漏洞的那个Agent，永远不参与同一个漏洞的核实。Cloudflare官方的措辞是“adversarial validation”——对抗性验证。验证者的任务是试图推翻这个发现，而不是确认它。
这个设计的精妙之处在于：它把“AI会不会自己骗自己”这个问题，从一个能力问题变成了一个流程问题。模型的能力边界还在，但流程保证了“一个Agent的幻觉不会被另一个Agent原样背书”。
它拒绝执行代码——如果没有沙箱的话
这是我在README里看到的最诚实的一句话。
security-audit-skill的设计原则是：如果没有操作系统级别的强制沙箱，它拒绝运行被审计的代码。 沙箱的条件很具体：网络切断、目标只读、CPU和内存限制。
如果没有沙箱，它不会强行“跑起来验证”。它会把这个发现标记为needs_validation——精确指出缺失的事实是什么，并且不允许标注严重等级。
这个设计解决的是AI安全审计里最隐蔽的失败模式：Agent为了让漏洞“成立”，修改源代码、创造出一个本来不存在的漏洞，然后报告“发现严重漏洞”。Cloudflare把这个行为写进了反模式清单，而沙箱要求是从流程上堵死这条路的唯一方式。
换句话说：它宁可告诉你“我无法验证这个发现”，也不愿意用猜测填满报告。 这种克制，在AI安全工具里很少见。
多跑几次，覆盖面会累加
security-audit-skill有一个被低估的机制：多次运行是累加的。 它读取之前的coverage-ledger.json和findings.json，针对未覆盖的区域继续审计，对已覆盖但源代码变更的重新验证，对已推翻的候选不再重复。
有测试显示，单次运行大约只能覆盖总漏洞的一半，因为每次探索的代码路径不同。多跑几次，覆盖面会明显扩大。
这意味着它的正确用法不是“跑一次看报告” ，而是“把它接进CI/CD，每次PR触发一次轻量审计，积累覆盖率”。findings.json的JSON Schema设计天然适合接自动化——你可以直接把它对接进漏洞管理系统或工单系统。
诚实说边界
它不是命令行工具。 它是塞进Claude Code、Cursor、Codex里的一个Skill。你对着代码库说一句“security audit this codebase”，Agent自己按六阶段往下走。安装走Vercel Labs的skills CLI：npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit。
它慢。 229行代码跑了超过30分钟，因为它真的在并行跑多个子Agent做侦察、狩猎、验证、复核。对于“顺手审一下”的场景，它太重了。它适合的是需要一份拿得出手、被追问时能拿出证据链的审计结论的场景。
验证者的独立性是“要求”而非“强制”。 Cloudflare在README里坦白了这一点：验证者Agent的独立运行，是靠内部编排器保证的，而这个编排器没有开源。公开版本里，独立性依赖指令约束。
它不替代人。 它产出的是confirmed、needs_validation、rejected三类记录。哪些confirmed需要立刻修、哪些needs_validation值得花时间去追、哪些rejected不需要再管——这个判断仍然是人做的。它的价值是让这个判断有据可依，不是替你做判断。
它真正解决的那个问题
AI安全审计最大的信任危机，不是“AI找不到漏洞”，是“AI找到的漏洞你不敢信”。它说“这里有SQL注入”，你点开一看，是测试代码。它说“这个接口未授权”，你验证发现是管理员正常功能。你花在验证误报上的时间，比你自己手工审一遍还多。
security-audit-skill的解法不是“让模型更聪明”。它的解法是：把“我审过了”变成可核对的产物。
覆盖率台账告诉你审了哪些、没审哪些。校验器告诉你证据的形状对不对。发现者和验证者分离，告诉你这个发现被另一个Agent试图推翻过。沙箱要求告诉你，没有被实际执行的发现不会被标为确认。
这四样东西加在一起，构成了一个你可以拿去问“凭什么”的审计结论。
严正声明
Cloudflare security-audit-skill采用MIT许可证，安装和使用请遵循项目开源协议。该Skill仅面向你拥有或已获得明确书面授权的代码库和系统。未授权审计、扫描、测试行为均属违法。技能包的设计原则中明确包含“无沙箱不执行目标代码”的安全边界，请勿强行关闭该限制。本文所述实测数据来自公开的安全社区测试报告，具体结果因代码库和Agent配置而异。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：昆仑AI安全实验室 klsec
klsec《Cloudflare开源了一个一万星的挖洞Skill：我埋了7个洞，它全找出来了，但它最值钱的地方不是“找漏洞”》