11 天报出 77 个严重漏洞，报告不经人看：Anthropic 把最强模型免费借给开源，把「谁来判断」摊上了桌

10 月 8 日，Anthropic 上线了一个叫 OSS Scanner 的服务。它做的事情很直接：用公司最强的模型，包括 Claude Mythos，去读关键开源项目的代码，把疑似漏洞整理成报告，直接发给项目维护者。免费，自愿报名，灵感来自 Google 已经跑了多年的 OSS-Fuzz。

真正不寻常的不是免费，而是流程里少了一道工序：没有人工复核。报告由模型生成，不经过 Anthropic 任何员工分诊，直接进维护者的邮箱。官方在说明里写得很清楚，这是产品设计，不是疏漏——为了让扫描更快、更频繁。

每份报告的形态倒是很实在。它包含一个自包含的复现器，拿到就能跑；一段漏洞解释，尽可能用二分法定位到引入问题的那个提交；以及一个候选补丁，能写就写。对维护者来说，这三样加起来，把「需要相信的叙述」变成了「可以直接验证的事实」。

首周的账单是：77 个严重、803 个高危，评级来自模型，未经人审，扫描还在继续。这个数字放在任何一家安全厂商的季报里都算漂亮，但它同时是一个提醒——这些报告是「模型认为」的严重，不是「确认过」的严重。

最有说服力的案例来自 curl。这是一个被无数应用和设备用来传输数据的底层库，维护者 Daniel Stenberg 曾经公开抱怨过「死于千份 AI 垃圾报告」——过去一年多，低质量、看着像那么回事但根本复现不了的 AI 提交，把开源维护者的收件箱淹了。

这次不一样。OSS Scanner 的早期版本发现了 CVE-2026-92392：HTTP/2 上传场景下的释放后使用。触发条件是服务端在传输过程中返回 RST_STREAM，并带上 HTTP_1_1_REQUIRED 或 REFUSED_STREAM；清理逻辑留下一个指向已释放结构的悬垂指针，服务端可控的数据随后可能占据那块内存，甚至替换函数指针。影响版本是 8.12.0 到 8.22.0，8.23.0 于 10 月 14 日修复。

Stenberg 的评价是「curl 很长时间以来最严重的漏洞之一」。他也说了实话：最可能的结果是崩溃，远程代码执行需要相当苛刻的条件。这个分寸感很重要——它说明 AI 找到的是真问题，但严重性的最终判断仍然要靠人。

还有两个细节值得记下来。一是时间：curl 团队 9 月 15 日收到报告，数小时内完成确认；二是节奏：为了这次修复，他们把发布周期从 8 周压缩到 6 周。也就是说，AI 带来的真正变化不是「发现得早」，而是「修复被提前」——后者才是风险真正下降的时刻。

顺带一提，这份漏洞公告的发现者署名是「Luna, with Claude (Anthropic)」。一个新名字加一个模型名，这可能是未来安全公告里越来越常见的格式。

在发布之前，Anthropic 请专业渗透测试人员复核了早期版本的产出：48 个项目、97 个严重与高危发现。结果是 85 个（88%）达到了公司协调漏洞披露流程的门槛，11 个是真实的但与其他已知问题或同批报告重复，只有 1 个是误报。

这个数字需要正确理解。88% 说的是「够格进入披露流程」，不是「88% 准确」。重复的 11 个仍然是真的问题，只是价值打了折；误报只有 1 个，说明「编造一个不存在的漏洞」这种最坏情况很少发生。

早期用户的反馈更具体。wolfSSL 收到的 74 份报告里只有 2 份无效，5 个拿到了 CVE 编号；PostgreSQL 的维护者说发现了相当高比例的缺陷，好几份报告附带的修复「几乎可以直接用」；OpenSSL 的评价是十八个月前 AI 报告还很糟，现在的「和人写的一样好，有时更好，尤其附带真实验证程序的时候」。

但这些好评不能推广成「AI 安全审计已经成熟」。官方自己列了两个已知问题：严重性评级可能虚高，以及可能误解项目的威胁模型。前者会让维护者疲于奔命，后者更麻烦——一个在内网工具里无关紧要的问题，在暴露到公网的服务里可能是致命的，模型不一定分得清你在哪种部署里。

这件事的背景数字比首周战果更说明问题。过去六个月，Anthropic 的模型在一批重要软件里发现了超过 2.9 万个候选漏洞，而人工只复核了大约 6000 个。也就是说，四分之三的产出压在了队列里，没人看。

在学术基准 CyberGym 上，模型的漏洞发现率从去年年初的不足 20% 提升到今年的 85% 以上。能力曲线陡峭到这种程度，产业里最先崩掉的环节一定不是「发现」，而是「分诊」。

所以 OSS Scanner 的本质不是「更强的扫描器」，而是一次流程外包：把分诊这道工序，从 Anthropic 的员工转移给了开源项目的维护者。官方甚至承认，已经向主动索取的维护者发送了近 5000 份未经核实的报告——不是他们不想审，是审不过来。

这就解释了一个反直觉的现象：能力越强，维护者的负担可能越重。过去一年开源社区对「AI 垃圾报告」的抱怨，本质上是分诊成本转嫁的早期版本；现在报告质量上来了，但数量也上来了，负担只是换了一种形式。

对整个安全行业，这是一个明确的信号：未来的竞争点不在「谁能扫出更多洞」，而在「谁能把洞排好序、派对人、关掉它」。扫描是入口，运营才是壁垒。

OSS Scanner 对项目方免费，但成本没有消失，只是换了承担者。维护者要读报告、要判断严重性、要确认是不是重复、要决定修不修。对一个只有两三个核心维护者的项目，这可能是每周多出十几个小时的工作量。

官方的设计对此有一定考虑。报告里带复现器和候选补丁，等于把「验证」这一步的摩擦降到最低；未经验证的报告没有强制披露期限，90 天倒计时只在 Anthropic 确认并纳入协调披露流程后才开始；项目可以在配置里写一行 disabled 暂停接收，也可以直接删掉目录退出。

报名方式也很克制：核心维护者向 GitHub 仓库提交 PR，加上项目配置与一个能构建依赖的 Dockerfile，因为扫描代理在没有网络的加固沙箱里跑，依赖必须预先取好。还可以附一份 threat_model.md 说明威胁模型，以及 GPG 公钥用于加密邮件。仓库本身是 Apache-2.0。

这套设计里最值得学的，是「把不确定性写进流程」：明确告诉对方这是模型输出、明确不承诺准确率、明确把裁决权留在项目自己手里。相比那些把 AI 结论包装成「检测通过」的产品，这种坦诚反而更容易被专业用户接受。

先说清楚边界：OSS Scanner 面向的是关键开源项目的核心维护者，报名要审核，普通企业用户既不能提交自己的代码库，也不能拿它扫自己的系统。国内企业现在想用，用不上。

但这件事传递的变化是通用的。第一，漏洞发现的速度单位已经从「月」变成「天」甚至「小时」。攻击侧用同样的模型找洞、写利用，防守侧如果还按季度做一次渗透测试，节奏就彻底错位了。

第二，报告形态变了。带复现器、带候选补丁的报告，把「要不要修」变成了一道可以当场验证的题。这对内部研发团队是好事——不用再花两周复现，直接看补丁对不对。但它也提高了要求：如果你们连代码仓库的版本管理都不规范，候选补丁根本无从落地。

第三，开源依赖的透明度变成硬指标。绝大多数中国企业的系统里，真正自己写的代码可能只占三成，其余是框架、组件、中间件、SDK。这些组件的漏洞公告你有没有订阅？升级窗口有没有排？出了 0day 谁来拍板停机？这三个问题，比「有没有买扫描工具」重要得多。

一个具体的例子：ThinkPHP、若依、Spring、Log4j 这些名字，很多企业的资产表里根本没有。等到公告出来才去问「我们用没用」，通常已经晚了三天。

第一张是组件台账。要能回答：我们用了哪些开源组件、什么版本、部署在哪些机器上、谁负责。台账不必一步到位做成 CMDB，先从一个 Excel 或一张表开始也行，关键是「可查」且「有人维护」。很多企业做不起来，不是工具不行，是没人认领。

第二张是漏洞工单。漏洞不是一个通知，而是一条要走到关闭的流程：谁认领、影响哪些系统、临时缓解是什么、什么时候修、修完谁验证。这里的关键是分级标准要写死，不能每次靠开会决定。常见做法是按「可利用性 × 资产重要性」两维打分，而不是只看 CVSS。

第三张是升级窗口。开源组件的升级往往牵一发动全身，所以要提前排期：哪些组件可以随时跟版本，哪些必须等业务低峰，哪些因为二次开发不能动。这张表做出来，你会发现自己其实有一半的组件是「不敢升」的——那才是真正的风险敞口。

这三张表都不需要 AI。但没有它们，AI 扫出来的东西落不了地。反过来，有了这三张表，即使没有 OSS Scanner，你也能把公开漏洞公告的响应时间压下来一大截。

拿到一份高危清单，多数团队的第一反应是「按严重性排序，从最高的开始」。这在实践中经常卡住：最高的那几个往往在核心系统里、改动最大、需要停机、要走变更评审，一个月都修不完；而中间那批「中危」里，有些只是改一个配置、加一条校验，两小时就能上线。

更有效的顺序是「修复成本 × 暴露面」。先把外网可访问、修复成本低的清掉，再处理内网、修复成本高的。这不是降低标准，而是用有限的人力换取风险下降的最大斜率。

同样的逻辑适用于 AI 辅助修复。候选补丁给的是「可以试的方向」，不是「可以直接合并的代码」。合理的用法是：拿补丁当参考，让熟悉这块代码的人改，改完跑回归。把 AI 补丁直接合进主干，是把自己的名字签在别人的判断上。

还有一个容易被忽略的收益：每次修完，把「为什么会产生这个漏洞」写进复盘。三个月后你会发现，八成的问题集中在两三个模式上——参数没校验、权限没复核、错误处理吞异常。把这三件事做成代码规范与自动化检查，比再买一套扫描工具划算得多。

OSS Scanner 值得被认真对待，不是因为它免费，而是因为它把一件事摊到了台面上：当 AI 能在几天内找出上千个真实问题，安全工作的重心就必须从「发现」移到「裁决与修复」。

这也解释了它为什么选择「不经人审」。如果等人工复核再发，扫描规模会被审核人力锁死，2.9 万与 6000 的差距就永远补不上。官方选择把不确定性交给最懂项目的人，同时把复现器和补丁一起递过去，让判断变得便宜一点。这是一个务实的设计，也是一种责任的重新分配。

对中国企业的启示很朴素：你不需要等一个用不了的服务，你需要的是三张表、一条工单流和一次真正的演练。工具会一直变强，流程不会自己变好。

最后提一句容易被忽略的配套：Anthropic 同期还推出了面向开源维护者的免费订阅、面向安全专业人员的验证计划，以及面向电力、水务、交通等关键基础设施的防御项目。这些动作拼在一起，说明免费扫描不是公益，是一套更大的安全生态布局——先用能力换信任，再谈别的。这一点，比任何一个单点修复都更值得留意。