Anthropic 发布 OSS Scanner：免费给开源项目做 AI 安全扫描，模型报告不经人工直达维护者

导语：开源安全史上第一次，"不经过人工"成为卖点

北京时间 10 月 8 日，Anthropic 宣布推出 OSS Scanner——一个面向开源生态、完全免费的 opt-in（自愿加入）漏洞扫描服务。加入的项目将定期接受 Anthropic 最强模型（含 Claude Mythos）的深度安全扫描，扫描产出的漏洞报告直接交付给维护者，中间不经过任何人工审核、分诊或润色。

把"无人审核"当作正式特性写进发布公告，这在安全行业是头一遭。过去几年，AI 生成的漏洞报告在开源社区里名声不佳——curl 创始人 Daniel Stenberg 早在 2025 年初就抱怨过"大多是垃圾（mostly slop）"，维护者们普遍把未经验证的 AI 报告视为噪音。Anthropic 这次要做的，恰恰是把"快但可能错"做成一个可选的加速通道：你可以选择继续走人工复核的协调披露（CVD）慢车道，也可以直接签收模型原始输出，自己承担分诊成本。

先做一个透明的说明：Anthropic 官方博客页面没有显示发布日期戳。TheHackerNews、SecurityWeek、Unite.AI、Help Net Security、Tech in Asia 五家独立媒体一致将发布时间标注为 2026 年 10 月 8 日，本文采用这个口径，时间均为北京时间。

背景：从 Project Glasswing 到 Cyber Mission

要理解 OSS Scanner，得先看清 Anthropic 在过去半年里铺的整条线。2026 年初，Anthropic 启动了内部计划 Project Glasswing：用 Claude 的最新模型对全世界最重要的软件项目做大规模漏洞挖掘。六个月里，模型挖出了 29,000 多个候选漏洞，但 Anthropic 的人工安全团队只来得及复核其中约 6,000 个——人成了瓶颈。

瓶颈的另一面是需求在反向倒逼：收到第一份报告的维护者，开始主动要求 Anthropic"把你们手里没验证过的东西全发过来"。截至目前，Anthropic 已经向提出这种要求的维护者直接发送了近 5,000 份未经验证的报告。换句话说，维护者们用行动投票：与其等三个月拿一份打磨完美的报告，不如现在就拿一份可能粗糙但及时的。OSS Scanner 正是把这种"快餐式交付"产品化了。

同一周，Anthropic 还把 Project Glasswing 并入了一个更大的框架：Cyber Mission——一项长期投入、动用工程人才、工具和资金去支援关键基础设施与开源社区防御者的计划。Cyber Mission 起步包含两个项目：一个是联合 CrowdStrike 等 11 家创始伙伴的 Critical Infrastructure Defense Program（关键基础设施防御计划），另一个就是 OSS Scanner。此外，Anthropic 还把 Cyber Verification Program 扩展为防御、红队、专项三档，给合格的安全从业者开放 Mythos 级模型和降低的拦截分类器，并推出 Claude for OSS（免费的 Claude Max 20x 订阅，帮维护者修漏洞）。OSS Scanner 不是孤立的产品发布，而是一套"AI 用于防御"组合拳里最面向社区的一招。

这条线还有更深的行业背景：学术基准 CyberGym 上，LLM 的漏洞发现率从去年初的不足 20% 一路涨到今年的 85% 以上。模型找漏洞的能力曲线正在变陡，而利用（exploit）的生成速度也在变快——Anthropic 在公告里直言，漏洞利用代码如今可以在几分钟内被开发出来。防御方的算术因此改变了：当攻击者用 AI 几分钟就能把漏洞武器化，防御方多等一周人工复核，代价是实实在在的风险敞口。

关键机制拆解：三层设计，一个核心取舍

第一层：opt-in 的准入方式

项目不是被动被扫，而是主动报名。核心维护者需要向 OSS Scanner 的 GitHub 仓库提交一个 PR，按标准模板附上一份 YAML 配置，写明：要克隆的代码仓库链接、主要联系人邮箱，以及一个仓库内相对路径的 Dockerfile——这个 Dockerfile 负责把构建环境、全部依赖装好，让离线 agent 能在无网络环境下完成安全审计（Anthropic 建议先验证测试用例能在容器里跑通）。还可以选填抄送邮箱和项目主页。

入选标准参考 Google 的 OSS-Fuzz：项目应对"基础设施和用户安全有关键影响"，具体个案逐个判断。OSS-Fuzz 是用 fuzzing 扫开源的老牌项目，Anthropic 明确说受到了它的启发——只不过把模糊测试换成了大语言模型。值得注意的是，Claude Security 是 Anthropic 面向企业的代码扫描与修复产品，OSS Scanner 则是同一技术路线的免费社区版：企业版帮公司防自家系统，社区版免费给开源项目做审计。

第二层：跳过人工审核——刻意的设计 trade-off

这是整个公告里最值得细看的一句：扫描输出将完全由模型生成，不经过人工审核或分诊（fully model-generated, without human review or triage）。好处是扫描可以更快、更频繁；代价是报告可能不正确或无效。Anthropic 没有回避这一点，而是把它摆上了台面。

但"没有人工"不等于"没有结构"。每份报告都包含三件套：自包含的可复现验证器（reproducer）、漏洞解释（尽可能附带二分定位、说明 bug 是何时引入的）、以及候选修复补丁（有时有）。在早期验证阶段，Anthropic 用这套流水线在数十个开源项目里跑了几百份报告，其中多个漏洞可以被串联成无需认证的远程代码执行（RCE）利用链——这已经不是"找找空指针"的水平，而是实战级的攻击链构造。

这个设计的聪明之处在于它承认了现实：Anthropic 的人工团队六个月只消化了 6,000 个发现，剩下 23,000 个候选在排队。与其让它们烂在队列里，不如把选择权交给维护者——你有能力分诊，就签收原始输出；没能力，继续走人工 CVD 通道。两条路并存，而不是一刀切。

第三层：双轨披露政策

披露节奏上，Anthropic 做了明确的双轨划分：经人工复核确认的漏洞报告，继续走现有的协调漏洞披露（CVD）流程，90 天披露时钟从人工确认那一刻才开始起算；未经验证的原始模型输出则直接交付给加入 opt-in 的维护者，不强制套用 90 天披露期——因为它们本质上是"未经确认的候选"，而不是"已确认的漏洞"。

这个区分很关键。它避免了把大量未经证实的发现强行塞进 CVD 的重型流程（那会拖死所有人），同时保留了严肃漏洞的负责任披露通道。代价是灰色地带变大了：一个"未经验证但大概率为真"的高危发现，在没有 90 天时钟约束的情况下，修复的紧迫感完全取决于维护者自己的判断。

数据解读：29,000、6,000、97 三组数字分别意味着什么

公告里的数据不多，但每一组都值得拆开看。

29,000+ 候选 vs 6,000 人工复核。这是六个月里模型从"世界上最重要的软件项目"中挖出的候选漏洞总数，和人工团队实际复核的数量。复核率只有约 20%。这个数字同时说明了两件事：模型找漏洞的吞吐量已经远超人类专家的处理能力；以及 Anthropic 过去半年其实一直在"憋大招"——OSS Scanner 不是从零启动的新服务，而是把已经跑了半年的内部流水线向社区开放。29,000 这个数字也解释了为什么维护者愿意签收"未经验证"的报告：排队的人工复核根本消化不完，晚拿到不如早拿到。

97 个严重/高危发现中，85 个达到 CVD 标准，仅 1 个误报。这是 Anthropic 请外部专家渗透测试员对 48 个项目的 97 个严重和高危发现做的抽检：88% 达到 CVD 披露标准；剩下 12 个里，11 个是真实的但与已知问题或同批其他发现重复，只有 1 个是真正的误报。注意这个样本的限定条件——它只覆盖了严重和高危级别，而且是"专家抽检"，不代表全部 29,000 个候选的准确率。但即便如此，1/97 的误报率也足以说明：在高危漏洞这个区间，当前最强模型的输出质量已经越过"可用"线。这也是 Anthropic 敢把"无人审核"写进公告的底气。

wolfSSL 的 74 份报告：72 份有效，5 个转成 CVE。这是来自维护者一线的、独立于 Anthropic 抽检的第三方验证。wolfSSL 的 Todd Ouska 表示 74 份报告里除了 2 份全部有效，其中 5 个最终成为正式 CVE 编号。附带补丁的报告可以直接塞进他们现有的修复流程。PostgreSQL 的 Noah Misch 说，不少报告附带的修复"几乎可以直接用"，快速通道让他们在 GA 版本发布前就堵住了最新问题。OpenSSL 的 Anton Arapov 的对比更有杀伤力：18 个月前的早期 AI 报告"糟糕透顶"，而 Anthropic 这批原始模型输出"和人类报告一样好，有时更好"——特别是当报告附带真实可用的 exploit 时，"工程师验证一下就行，工作基本就算完成了"。

curl 的 Daniel Stenberg 则给出了分量最重的一句：OSS Scanner 帮 curl 找到了多个值得修的问题，其中包括"过去几年里上报给 curl 的最严重的漏洞之一"。要知道，curl 是被全世界安全研究员用显微镜看了二十年的项目，能在这里找到"几年最严重"级别的漏洞，说明模型的发现能力已经摸到了人类专家长期耕耘区的天花板。

行业反响：叫好之外，也有皱眉的

维护者阵营的反馈一边倒地积极，这不意外——免费的顶级模型审计，不要白不要。但安全社区里也有另一种声音，而且值得认真听。

Google 方面提醒，自动化的安全发现会给维护者带来额外的分诊工作；OpenSSF（开源安全基金会）的讨论则警告，AI 生成的披露可能带来低质量噪音。这两点担忧都指向同一个结构性问题：当"生成报告"的成本趋近于零，"阅读和验证报告"的成本就成了新的瓶颈。OSS Scanner 用 opt-in 把这个成本转嫁给了自愿承担的维护者，但转嫁不等于消除——一个只有两三个兼职维护者的小项目，就算免费拿到 50 份模型报告，也可能根本看不过来。

更深一层的问题是激励错位。OSS-Fuzz 模式之所以成功，是因为 fuzzing 找到的是"确定性崩溃"，验证成本低；而 LLM 报告是"概率性判断"，每份都需要人脑过一遍。如果未来多家厂商都推出类似服务，维护者可能同时收到五六家的 AI 报告，重复发现、互相矛盾的评级、被夸大的严重度——噪音会指数级增长。Anthropic 在公告里承认"严重度评级可能被夸大、扫描器可能误解项目的威胁模型"，算是提前打了预防针，但这只是承认问题，不是解决问题。

还有一个微妙的竞争维度：Anthropic 把最强模型（含 Claude Mythos）的扫描能力免费开放，客观上是在给开源生态做"安全补贴"。这对商业代码扫描厂商（如 Snyk、Semgrep 背后的公司）是直接的压力——当最强模型的审计免费时，"AI 代码扫描"这个品类的定价逻辑会被重写。Claude Security（企业版）和 OSS Scanner（免费版）的搭配，明显是在复制"开源版引流、企业版变现"的经典打法。

对 vibe coder 和独立开发者的启示

这条新闻和 vibe coding 社区的关系，比表面上看起来更近。想一想：现在独立开发者用 AI 写代码的速度越来越快，一个周末就能搓出一个像模像样的 SaaS，但安全能力并没有同步跟上。过去，"请人做安全审计"是独立开发者够不着的奢侈品——贵、慢、排期长。OSS Scanner 把这件事变成了"提个 PR、写个 YAML 就能排队"。

具体来说，有三层可操作的启示：

• 把 OSS Scanner 当作发布 checklist 的一环。如果你的开源项目对基础设施或用户安全有关键影响（这是入选标准），现在就可以去 GitHub 仓库提 PR 报名。重点是先把 Dockerfile 环境准备好——Anthropic 要求离线 agent 能在容器里完成构建和测试，这本身就是一次很好的"可复现构建"健康检查。
• 学会读"未经验证"的报告。签收原始模型输出意味着你要自己做分诊。建议建立简单的处理流程：先跑 reproducer 验证是否真实可复现，再看严重度评级是否匹配你的威胁模型，最后决定修不修、什么时候修。不要把"模型说高危"直接等同于"必须立即修"——Anthropic 自己都承认评级可能夸大。
• 把 AI 安全扫描纳入 vibe coding 工作流。更广的思路是：既然模型能给 PostgreSQL 找漏洞，也能给你的项目找。在等 OSS Scanner 排期的同时，可以用 Claude Security 这类企业产品、或者直接在开发流程里让模型做安全自查。AI 写代码和 AI 审代码，应该是同一枚硬币的两面——只用一半的人，是在给自己埋雷。

还有一个容易被忽略的点：Claude for OSS 提供免费的 Claude Max 20x 订阅帮维护者修漏洞。这意味着"发现-修复"闭环里，修复那一端也有免费算力支持。对独立开发者来说，这整套组合拳几乎把开源项目的安全成本打到了零——剩下的只是你愿不愿意花时间看报告。

风险与争议：四个绕不开的问题

第一，误报的真实成本。97 抽检里只有 1 个误报，听起来很美，但那是严重/高危子集。29,000 个候选中低危和中危部分的准确率，Anthropic 没有公布。维护者的时间是最稀缺的资源，如果低危报告里误报率偏高，小项目的维护者很快就会从"全都要"变成"已读不回"。OSS Scanner 能不能持续，取决于它能否长期维持让维护者觉得"值得看"的信噪比。

第二，责任归属的模糊地带。报告完全由模型生成、未经人工审核——那么如果一份报告里的"候选补丁"引入了新问题，或者一份被判定为"无效"的报告实际上是真实漏洞后来被利用了，责任在谁？Anthropic、模型、还是签收了报告的维护者？公告没有触及这个问题。opt-in 的自愿性质在一定程度上是免责条款，但法律和道义上的边界迟早需要厘清。

第三，攻防不对称的另一面。Anthropic 强调这是"防御性"部署，但同样的模型能力也可以被攻击者用来找漏洞。Anthropic 的逻辑是：既然攻击者迟早也会用 AI 找漏洞，不如先让防御者拿到同样的武器——"以快打快"。这个逻辑成立的前提是防御方真的"快"：报告发出去了，维护者修得上吗？Stenberg 那句"大多是垃圾"的抱怨才过去一年多，生态的修复能力是否跟上了发现能力的跃升，还是个未知数。

第四，准入门槛的隐性筛选。入选标准参考 OSS-Fuzz（对基础设施和用户安全有关键影响），个案审批。这意味着最需要安全帮助的长尾小项目，可能恰恰排不上队；而已经有成熟安全流程的大项目，拿到的更多是"锦上添花"。Anthropic 说标准会随时间演进，但现阶段 OSS Scanner 更像是一场"精英试点"，而不是普惠的安全基础设施。这一点不妨碍它的价值，但决定了我们对它的期待值。

结语：安全行业的"iPhone 时刻"可能不是模型，而是交付方式

回看这件事真正新颖的地方：不是"AI 能找漏洞"（Glasswing 已经证明了半年），也不是"免费"（OSS-Fuzz 免费了快十年），而是 Anthropic 把"未经人工审核"从一个需要道歉的缺陷，变成了一个可以 opt-in 的特性。

这个转变背后是一个诚实的判断：当模型找漏洞的速度超过人类验证速度一个数量级时，继续坚持"每份报告都必须人工过目"不再是严谨，而是另一种形式的不负责任——让 23,000 个候选漏洞在队列里过期。Anthropic 选择把选择权交还给维护者，用 opt-in 机制让"快但可能错"和"慢但可靠"两条路并存。

对开源生态来说，这是一个值得欢迎的实验，但实验的成败不取决于 Anthropic 的模型有多强，而取决于维护者们愿不愿意、能不能消化这些报告。29,000 个候选是模型的胜利；6,000 个人工复核是人类的瓶颈；OSS Scanner 赌的是：把瓶颈从 Anthropic 内部搬到整个社区之后，社区能接住。

如果你维护着一个有一定影响力的开源项目，现在就可以去 red.anthropic.com/oss-scanner 看看报名方式——提个 PR 的成本很低，而错过第一批深度扫描的代价，可能是别人先发现你代码里的问题。毕竟在这个 AI 找漏洞的时代，问题不在于有没有漏洞，而在于谁先找到。