真实率不到7%,谷歌开源Mantis让AI自己验漏洞

AI 扫一遍代码，列出一百个漏洞。真能复现的，可能不到 7 个。

谷歌把处理剩下那九十几个的流程开源了，名字叫 Mantis。它不多找漏洞，只负责让 AI 报出来的每一条都有证据。

真阳率不到 7%，这笔账谁在付

AI 找漏洞这件事，防守方一直在追。谷歌在官方博客里给了很直接的判断：模型已经能在几乎没有人类帮助的情况下发现并利用漏洞，所以防守这一侧必须把 AI 用起来。

麻烦在于，让它读源码、列可疑点，它会编。官方博客里提到的口径是，AI 代码扫描的"真阳率"，也就是报出来的漏洞里真存在的比例，可能低于 7%。

curl 关了赏金。那赏金是给漏洞的。谷歌停了漏洞提报。理由都一样。审不完。审核员一天看几十条。这已经算快了。十万行的仓库跑一轮。它一屏一屏地吐。

发现能力早就不缺了。缺的是验货。

15 个技能，把报告变成证据

Mantis 是一套装进编码代理里的技能集。每个技能就是一份写给 AI 看的规格文档，装好之后在 Gemini CLI、Antigravity CLI 这类工具里以斜杠命令的形式逐条执行。

装完之后它这么干活：一个漏洞对应一个 JSON 文件，全部落在 workspace/findings/ 目录里，十五个阶段接力改这批文件。它先挖仓库提交历史里修过的旧漏洞，生成一份知识库和持续更新的威胁模型；排完计划逐文件扫，扫完去重，交给 review 阶段用文档里写明的 12 条负向规则删误报，再由 critic 阶段卡一道，只认 release 构建下能崩的。

复现才是分界线。reproduce 阶段写出 PoC 脚本，在 gVisor 或容器里跑，网络是关掉的（--network none）。跑通了才有资格进 patch 阶段生成补丁，补丁还要在沙箱里过一遍验证，最后 calibrate 给每条发现打 1 到 10 的风险分。

晚上把它挂起来。外网全是关的。跑上一夜。早上打开目录。看见崩溃现场。还有能复现的脚本。不是一句疑似存在。这一轮的错误假设。都写进日志文件。下一轮开工先读。

省下 85% token 的不是更长上下文

大仓库上做 AI 分析，最贵的一步是把源码塞进模型。

Mantis 换了个顺序：先按目录聚合文件级信息，再往上合成一份仓库级的安全摘要。AI 先看摘要定方向，只在需要的时候下钻到具体文件。谷歌说这样能保住关键结构信息，同时把 token 开销压掉 85% 以上​。

这一条更容易抄。上下文不够时。很多团队先换便宜模型。有人直接把代码切碎。切碎的代码。看不见调用链。先建摘要层再下钻。是另一条路。

谷歌自己先写了三条警告

官方文档写得比新闻稿狠。

漏洞报告和补丁都不一定对，必须由安全专家人工复核过再往外提交。AI 生成的代码要在和生产系统、内网隔离的环境里执行。无人值守模式的要求更硬：独立虚拟机、不给外网、放进 VPC 服务边界、IAM 最小权限、存储桶只给写不给删。

还有一条容易被忽略的风险：编排这套流程的模型要读你的代码，而恶意代码可以反过来指挥它。官方的建议是把编排从模型手里拿出来，做成确定性的流水线，阶段之间用 SCHEMA.md 定义的契约传数据。

复现失败不等于误报。跑通了也不等于能用。每次结果都不一样。第一轮漏掉。第五轮才看出来。这很常见。跑得越多。捡到的越少。什么时候停手。看你自己。

这套东西里最值得抄的，是它把"AI 说了不算"写进了流程：每条结论都得有沙箱里跑得出来的证据。你们团队的 AI 代码审计现在卡在哪一步，是报告太多没人看，还是报告看完了不敢信？

作者提示含AI生成内容。作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～