AI一天找100个漏洞,但96%没人修—

AI一天找100个漏洞,但96%没人修——Anthropic的解法

Anthropic用AI扫描开源软件，一个月找到了超过10,000个高危漏洞。其中仅Anthropic自己扫描的1,000+开源项目就发现了6,202个高危漏洞，经过独立安全公司验证，90.6%是真阳性。

但修补速度呢？截至5月22日，Anthropic披露了1,596个漏洞，只有97个被修补——修补率6%。

这不是AI不够强，恰恰相反。发现漏洞已经可以并行化，瓶颈转移到了验证、分类和修补。 Anthropic在最新开源的defending-code-reference-harnes中，给出了完整的解法。

10,000+

一个月扫到的高危漏洞

修补率（97/1596）

90.6%

真阳性率

6步Find-and-Fix循环

基础设施（每库一次）

Step 1

威胁建模

Step 2

沙箱

↓ 循环执行

Step 3

发现

Step 4

验证

Step 5

分类

Step 6

修补

第一轮发现最多，后续越来越复杂

第1步：威胁建模

最大误报来源不是模型看不懂代码，是模型不了解你的信任边界。

CISO原话模型可能把受信任的内部配置当攻击面（误报），也可能把公网暴露的服务当内部服务（漏报）。一位CISO的话很直白："模型对代码有很好的理解，但对我们没有。"

数据

威胁模型写得好的系统，模型发现的可利用率达90%。反之，大型项目40%的"误报"不是因为PoC不可复现，而是开发团队认为这些漏洞不符合项目的威胁模型。

怎么建威胁模型？两步：

方法一从代码和文档bootstrap。 把架构文档、入口点、git历史、历史CVE喂给模型，生成威胁模型草稿。有团队回顾数百个历史CVE和安全修复commit，提炼出"bug形状"提示，问模型两个问题：修复是否完整？同样的修复是否应用到了其他地方？一小时找到3个可利用漏洞。

方法二让模型访问熟悉系统的人。 用Shostack四问法：我们在建什么？什么可能出问题？我们对此做了什么？做得好吗？先跑bootstrap再访谈，对方不用从零开始。

关键实践 显式写出信任什么（配置文件/已认证客户端）；把THREAT_MODEL.md放代码库；参考依赖的安全策略（vLLM/SQLite/ImageMagick）。

第2步：沙箱——双重目的

沙箱有两个目的，很多人只想到第一个。

目的一·保护系统

容器读代码；microVM跑PoC；锁定出站流量；永不访问凭据。一个团队告诉模型没网络，模型自己发现能拉GitHub——约束必须靠代码强制。

目的二·证明可利用

静态扫描无法判断路径可达性。能构建PoC并在沙箱中运行成功才算真阳性。攻击安全团队原话："最大效能杠杆是给模型测试床，让它跑PoC。"

踩坑案例有团队扫描报了个漏洞，结果是Agent下载了旧版本依赖而非实际部署的版本。修法：Docker构建时依赖锁版本匹配生产环境。

第3步：发现——并行扫描

让模型分析源码找漏洞。多Agent并行，大代码库按威胁模型分区。

每次扫描从快照开始，保证环境一致。第一轮发现最多，后续越来越少但更复杂。不要期望第N轮零发现——模型有随机性，大代码库有长尾漏洞。

没有沙箱也能做发现——前沿模型仅从源码分析就能找到漏洞，多团队验证过。代价在验证阶段：没有运行环境，你无法证明漏洞可达。

第4步：验证——独立确认

硬性规则发现和验证必须用不同Agent。 同一个Agent既发现又验证会产生确认偏差。

验证标准：能构建PoC并在沙箱中运行成功才算真阳性。一个团队扫描开源包的闭环：扫描包→生成PoC→部署使用该包的mock应用→触发PoC。他们的总结："验证是最大的瓶颈，PoC就是验证。"

注意PoC构建失败不等于假阳性。可能是沙箱不够忠实，也可能是Agent能力限制。验证失败需要人工判断。

第5步：分类——真正的瓶颈

模型午饭前能找100个候选漏洞，分类跟不上。这就是瓶颈。

告警疲劳分类不当会提交太多重复或严重度虚高的发现，产品工程师会停止阅读。开源维护者尤其容易被淹没。

去重规则：

● 同根因不同表述 → 重复

● 同一漏洞多调用点 → 重复

● 缺失全局保护按端点报告 → 重复

● 同一路径的因和果 → 重复

● 同文件不同漏洞类 → 独立

● 不同变量到达不同sink → 独立

严重度6维度：

维度	评估问题
可达性	攻击者能从真实入口点到达吗？
攻击者控制	不受信任输入能完整到达sink吗？
前置条件	需非默认设置、特定feature flag？
认证要求	未认证能触发还是需登录？
读写权限	只读还是能写？
爆炸半径	一个用户还是整个平台？

防锚定让模型先列证据再打分。 起点：零前置条件+未认证远程=严重/高，1-2个前置条件或需认证=中，3个以上或仅本地=低。

第6步：修补——关闭循环

TDD思路：先写一个会失败的测试→实现修复→确认测试通过→确认不破坏其他东西。不加测试，修复可能悄悄回退。

4级验证阶梯：

1. 编译补丁能编译，新测试通过

2. 复现原始PoC不再复现（捕获无效补丁）

3. 回归原测试套件仍通过（捕获过度严格补丁）

4. 对抗新发现Agent攻击补丁（捕获不完整补丁）

100% 闭环

常见失败

修症状不修根因 / 补丁过于严格导致依赖不可用 / 只修一个调用点。修后更新威胁模型，把验证过的发现喂入下一轮扫描。

实战效果

Project Glasswing一个月的数据：

2,000

Cloudflare bug

271

Firefox 150

10x+

vs Firefox 148

Cloudflare2,000个bug（400高危/严重），误报率低于人类测试。

MozillaFirefox 150修了271个漏洞，是Firefox 148用Claude Opus 4.6的10倍以上。

Palo Alto最新版本补丁量是平时的5倍。

wolfSSLMythos Preview构建了完整的证书伪造exploit——攻击者可伪造银行/邮件提供商的证书。

银行案例一家银行用Mythos Preview检测并阻止了一笔150万美元的欺诈转账。

上手指南

① 克隆defending-code-reference-harness，在Claude Code中运行/quickstart

② 装GitHub Action：claude-code-security-review，每次PR自动安全review

③ 从自己的一个服务开始：bootstrap威胁模型→建沙箱→扫描→验证→分类→修补→定期重扫

预算提醒

第一次扫描会发现比你预期更多的漏洞。大多数需要验证和分类。在预算更多扫描之前，先预算扫描之后的pipeline。

写在最后

AI找漏洞的能力在快速提升。UK AI安全研究所报告Mythos Preview是第一个端到端解决其两个网络靶场的模型，XBOW称其在web exploit基准上"显著超越所有现有模型"。

防守方的时间窗口

防守方必须在攻击者之前找到并修补漏洞。发现只是第一步，验证-分类-修补的pipeline才是关键。Anthropic开源这个框架，就是让每个团队都能跑起这个循环。