这篇文章讲的是 Cloudflare 如何用 AI 搭建了一套自动找漏洞的流水线。简单说，就是让一群 AI 程序员 7x24 小时不停地在 Cloudflare 自己的代码里找安全漏洞，找到之后还要验证、去重，甚至直接生成修复补丁。
不要依赖某一个最厉害的 AI 模型，而是搭建一套“流水线”，让不同的 AI 模型各司其职、互相验证，像工厂流水线一样把“原始发现”加工成“可信的漏洞报告和修复方案”。
代码地址：https://github.com/cloudflare/security-audit-skill
一、他们在做什么？
Cloudflare 代码库非常大——横跨 Rust、Go、C、Lua、TypeScript、Python 等多种语言，有 145 个以上的代码仓库。靠人工审代码找漏洞根本不可能。所以他们搞了一套自动化系统：
让 AI 自动扫描所有代码，找出真正的安全漏洞，去重、验证，最后生成可用的修复补丁。
截至发文时，这套系统已经处理了 13841 个发现，最终筛选出 7245 个可执行的漏洞交给工程师修复。
二、为什么不用普通方法？
很多人可能会问：直接用 ChatGPT 那样的 AI 去读代码不就行了吗？文章提到了三个致命问题：
1. 上下文窗口撑爆
AI 模型一次能处理的信息是有限的（就像人的短期记忆）。让它读一个小时代码，上下文窗口就被塞满了，模型会“忘掉”自己一个小时前追踪的那个漏洞。解决方案：把 AI 当成“无状态计算引擎”——它每干完一件事就把结果存进数据库，不靠记忆。
2. 中途崩溃就全完了
AI 服务可能因为限流、网络抖动等原因突然断掉。如果跑了几小时的工作因为一个错误全丢了，成本太高。解决方案：每个阶段的结果都实时写入数据库——崩溃只丢当前这一个任务，其他的都还在。
3. 跨仓库的漏洞看不到
一个代码仓库可能被另一个仓库的代码调用。如果只单独看每个仓库，就看不到“A 仓库的代码在 B 仓库里被错误使用”这种跨仓库的漏洞。
三、系统怎么工作？两阶段流水线
整个系统分成两大阶段：
第一阶段：漏洞发现（VDH — Vulnerability Discovery Harness）
这一阶段负责主动扫描代码，找出潜在的安全问题。
整个流程拆成了 8 个步骤：
| 步骤 | 干什么的 | 大白话 |
|---|---|---|
| Recon（侦察） | 3 个 AI 并行读代码，写出架构文档 | 先派 3 个 AI 去“踩点”，搞清楚这个代码是干什么的 |
| Hunt（狩猎） | 按漏洞类型发起“攻击”，尝试破坏代码 | AI 假装自己是黑客，想办法攻破这套代码 |
| Validate（验证） | 先机械检查格式，再用另一个 AI 尝试推翻发现 | 找到漏洞后，派另一个 AI 专门来“抬杠”，看能不能推翻 |
| Gapfill（补缺口） | 发现哪些地方覆盖不足，生成新的狩猎任务 | 哪块代码还没查到位，就再派任务 |
| Dedup（去重） | 合并重复的漏洞发现 | 不同 AI 可能找到同一个漏洞，合并掉 |
| Trace（追踪） | 遍历依赖关系图，在调用方仓库里生成新任务 | 发现某个组件有问题，就去查哪些代码用了它 |
| Feedback（反馈） | 从历史报告中学习，优化后续任务 | 总结经验，下次查得更准 |
| Report（报告） | 生成人类可读的报告 | 最后输出给人看 |
关键设计是 第 4 到第 8 步会循环执行——发现漏洞→补查→去重→再发现，像一个不断运转的齿轮。
第二阶段：漏洞验证（VVS — Vulnerability Validation System）
第一阶段找到的东西还只是“嫌疑犯”，第二阶段负责最终审判：
| 步骤 | 干什么 | 大白话 |
|---|---|---|
| Dedup（去重） | 判断这个漏洞是不是已经在系统里了 | 先查查这个洞是不是之前有人报过了 |
| Judgment（审判） | 查生产环境配置，判断这个漏洞在实际环境里能不能被利用 | 这个洞在真实线上环境里到底能不能被攻击？ |
| Fixing（修复） | 生成补丁、跑回归测试 | 直接生成修复代码，跑测试验证 |
关键细节：第二阶段用的 AI 模型和第一阶段完全不同。相当于让模型 B 来审核模型 A 的作业，两个模型互相复核，避免同一个 AI 的偏见导致漏报或误报。
四、几个特别聪明的设计
1. 让 AI 自己写“威胁模型”
不是给 AI 一份现成的漏洞清单让它去查，而是让 Recon agent 自己读完代码后，针对这个代码库的特点现场写一份威胁模型。不同的代码有不同的风险点，让 AI 自己判断更精准。
2. 让 AI 真的“跑”代码，而不只是“读”代码
对于 C 这类底层语言，光读代码看不出问题。【Hunter agent 会真的编译代码片段、运行、尝试让它崩溃**。这就从“纸上谈兵”变成了“真刀真枪”。
3. “愿望清单”（Wishlist）
如果 AI 发现需要某个工具才能继续验证（比如需要一个 FreeBSD 虚拟机来验证某个漏洞），它会写进一个“愿望清单”。系统会记录下来，等人提供资源后自动重新跑这个任务。这个机制已经被写入了 25,472 次。
4. 防止 AI“自己批改作业”
AI 有一个坏毛病：它会修改代码让漏洞能跑通，然后兴高采烈地报告自己“创造”出来的漏洞。为了防止这个问题：
- Hunter 必须先说明攻击者是谁、跨越了什么边界，才能提交发现
- 每个漏洞必须附带一个可运行的 PoC（概念验证），在原始代码上跑通才算数
- Validator 专门负责推翻 Hunter 的发现，不能自己提交漏洞
5. 修复要带测试
每个确认的漏洞必须附带 proposed patch（修复补丁）和 unit tests（单元测试）。Fixer 会应用补丁、跑测试，要求测试从“失败”变成“通过”才算修复成功。而且 Fixer 永远不会自己合并代码，必须由人工审查。
五、成本和效果
成本：跑几百个 AI 不便宜，但成本集中在“狩猎”阶段。他们按代码仓库做预算，对每个仓库设任务上限，用 50 到 200 个 worker 并行跑。最复杂的一次扫描跑了 14 小时。
效果（数据说话）：
- VDH 生成了 20,799 个原始发现
- 验证后存活 12,057 个
- 进入 VVS 后，与另一个系统的发现合并，中心池达到 13,841 个
- 去重去掉 5,442 个
- 过滤掉 1,154 个（属于其他仓库或低风险）
- 最终留下 7,245 个可执行的漏洞交给工程师处理
验证拒绝率从 40% 降到了 11%，高质量发现占比从 35% 升到了 58%。
六、总结
Cloudflare 用一套“流水线”把多个 AI 模型组织起来：一批 AI 负责找漏洞，另一批 AI 负责推翻，再一批 AI 负责去重、验证、生成补丁。核心思想是“不要把赌注押在任何一个模型上”，而是搭建一个不依赖特定模型的架构。
这样即使某个 AI 模型被淘汰或升级了，整个流水线依然能运转——换掉模型就行，不用重写整个系统。
文章评论