Anthropic玻璃翼计划遭质疑：挖出近4万漏洞，仅修复217个

AI挖洞很快，修洞很慢

最近AI在网络安全领域的应用出现了一种奇怪的割裂感。

一方面，大模型展现出了惊人的漏洞挖掘能力。它们能倒查历史代码，揪出PHP底层的重大安全隐患，也能在Linux内核中扒出数百个潜在问题。另一方面，开源社区的反应却有些崩溃：你倒是把修好的补丁交出来啊。

这种矛盾在Anthropic的“玻璃翼计划”（Project Glasswing）上体现得尤为明显。昨天，网络安全公司VulnCheck发布了一份针对该计划的追踪报告，数据让人咋舌：在计划推出七个月后，Claude累计提交了37966条候选漏洞，但截至目前，公开记录显示只有217条被真正修复。

这个转化率不到0.6%。VulnCheck据此质疑，当初宣传中那个由AI主导的网络安全“Mythos时代”，究竟是真的到来了，还是仅仅制造了一场数据泡沫？

3.8万条候选，两百多张补丁

回顾今年4月，Anthropic高调启动“玻璃翼计划”。名字起得很诗意，寓意安全漏洞像玻璃翼蝶一样，透明却难以察觉，数十年潜伏在代码深处无人发现。Anthropic希望通过提高透明度，联合科技巨头和开源社区，在黑客利用之前消除隐患。

当时场面很热闹。Anthropic承诺提供1亿美元的模型额度及400万美元捐款，苹果、谷歌、微软、AWS和英伟达纷纷站台。官方宣称其专用模型Claude Mythos Preview已经发现了数千个高危漏洞。

但VulnCheck的持续追踪揭示了另一番景象。

截至11月初，候选漏洞库膨胀到了37966条。在这座巨大的数字冰山之下，标记为“已修复”的仅有217条。更糟糕的是，无效数据正在堆积：有419条被撤回，1654条被判定为重复提交。

这种差距还在加速扩大。仅在最近两个月，新增候选漏洞就接近1.2万条，而修复记录只微弱增加了15条。

如果看CVE（通用漏洞披露）数据，Anthropic归因的CVE仅占2026年全球公开总量的0.5%。这说明，虽然挖掘数量庞大，但真正形成行业影响力的标准化漏洞披露并不多。

当然，双方统计口径存在差异。Anthropic官方数据显示，截至11月2日，在37966项候选中，有6376条经过外部专家审核，其中6009项确认为有效。在这6009项有效漏洞中，5087项已报告给维护者，629项获得了上游补丁。

即便按Anthropic更乐观的“629个补丁”计算，相对于近3.8万的挖掘量，效率依然低下。而且，无论哪方的数据，都指向同一个瓶颈：人工审核根本吃不消。

Anthropic自己也承认，人工验证能力的严重不足，极大地限制了漏洞的审核与披露效率。AI可以24小时不睡觉地扫描代码，但人类专家需要睡觉，也需要时间复现和验证每一个报错。

为了缓解这一压力，Anthropic在10月8日推出了OSS Scanner服务。开源项目维护者可以主动报名，让Claude直接扫描自己的代码库。这样生成的报告可以直接发给维护者，跳过了Anthropic内部的人工初审环节。这看似提高了效率，实则将审核压力完全转移给了本就捉襟见肘的开源社区。

开源维护者：别让我们淹死

这场AI挖洞狂欢中，最受罪的是一线开源维护者。

VulnCheck在报告中举了curl的例子。curl是一个广泛使用的网络数据传输工具，几乎存在于每一台连接互联网的设备中。11月初，curl的核心维护者Daniel Stenberg又收到了一份来自Anthropic的“大礼包”：45份新的漏洞报告。

这已经不是第一次了。早在之前，Daniel就在博客中无奈地写道：“我们的目标是别被淹死。”（We aim to not drown.）

面对源源不断的报告，Daniel不得不修改curl的安全漏洞处理规则。以前可能内部悄悄处理，现在低危和中危漏洞改为在GitHub上公开讨论，指望社区其他开发者帮忙分担审核工作。

结果如何？在curl公开的34份来自AI的报告里，19份被判定为不构成安全漏洞，6份确认为低危。也就是说，超过七成是误报或无关紧要的问题。

VulnCheck的报告暗指，玻璃翼计划除了给维护者平添审核工作量外，实际安全收益存疑。毕竟，之前宣传的都是“严重危害”，怎么落地变成了大量低效噪音？

不过，公平地说，AI确实挖到过真家伙。今年9月，Claude发现了curl中的一个Use-After-Free内存错误。在特定条件下，恶意服务器可以利用这个漏洞实现远程代码执行。Daniel承认，这是curl多年来最严重的漏洞之一。

这就是现状：AI能在海量代码中大海捞针，找到那个致命的针尖；但它也会捞出成千上万吨的海水，让找针的人疲于奔命。

值得注意的是，VulnCheck这篇报告本身也带有商业色彩。它批评玻璃翼计划效率低下的同时，也在推广自家的漏洞情报和优先级管理服务——言下之意是，你们搞不定排序和筛选，不如买我们的服务。

为什么AI不顺手把Bug修了？

读到这儿，很多人会有一个直观疑问：既然Claude这么强，能发现漏洞，为什么不直接生成修复补丁，非要让人类来填坑？

实际上，Anthropic已经在尝试让AI生成候选补丁。但现实比想象骨感得多。

首先，开发者对AI修Bug早已苦不堪言。让大语言模型（LLM）生成一段看起来能跑的代码不难，难的是开源项目愿不愿意采用这段代码。

审核一份AI生成的补丁，工作量有时几乎等同于重新写一份。开发者必须逐行检查：这个变量名对不对？这个逻辑有没有副作用？会不会引入新的竞态条件？

其次，AI有一种“加法偏好”。它非常擅长添加事物——加一个判断、加一个函数、加一层封装。但它意识不到，有时候解决bug最好的方式是“移除”——删除冗余代码、简化逻辑。

一位资深开发者曾吐槽：“AI点亮一根蜡烛照亮更多黑暗。”为了修复一个Bug，AI往往往代码里加入更多复杂逻辑，结果修好一个旧问题，又带来十个新Bug。

这种“打地鼠”式的修复，对于追求稳定性的基础软件来说，往往是不可接受的。开源项目维护者宁愿慢一点，手动写出简洁、可维护的补丁，也不愿接受一堆虽然能跑但难以理解的AI代码。

所以，至少在当前阶段，最强模型挖出的坑，还得靠人类一铲子一铲子地填。

技术债的利息太高

这场争论背后，折射出的是软件行业积压已久的技术债问题。

有人感叹：“AI正在逼我们立即还清拖欠40年的技术债。”

过去几十年，软件开发追求快速迭代，“先上线再修补”成为常态。无数底层库、框架中埋下了隐蔽的安全隐患。人类开发者因为精力有限，往往 prioritise 新功能开发，而对深层重构望而却步。

AI的出现，突然让这些陈年旧账变得可见了。它不知疲倦地扫描，把那些藏在角落里的灰尘全部扬了起来。问题是，房间的主人（开源维护者）只有那么几个，扫帚（修复资源）也只有那么几把。

当灰尘扬起的速度远超清扫速度时，空气只会变得更加浑浊。

玻璃翼计划的困境，不是AI不够强，而是软件工程的社会结构跟不上技术的爆发。我们拥有了神一般的挖掘能力，却还保留着手工匠人般的修复流程。

未来怎么破局？也许需要更智能的自动化验证工具，也许需要改变开源社区的协作模式，甚至可能需要重新定义“安全漏洞”的披露标准。但在这些方案成熟之前，像Daniel Stenberg这样的维护者们，只能继续在报告的洪流中，努力不被淹死。

对于 Anthropic 和其他投身于此的巨头来说，下一步的关键或许不在于挖掘更多的漏洞，而在于如何降低每一个漏洞的修复成本。否则，3.8万个未修复的候选漏洞，将成为悬在开源生态头顶的一把达摩克利斯之剑，而不是保护伞。