文章总结: 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个洞,它全找出来了,但它最值钱的地方不是“找漏洞”》