Anthropic OSS Scanner 提供免费的开源审计，但维护者必须筛查 AI 输出

Anthropic 于 10 月 8 日推出 Anthropic OSS Scanner，为符合条件的开源项目提供免费的定期漏洞审计服务。这项服务显著扩展了 AI 辅助安全研究的范围，但由于报告未经人工验证，也将一项重要负担转移给了维护者。

这种取舍定义了此次发布。Anthropic 表示，其模型能够检查的代码量超过安全研究人员可人工审查的范围。OSS Scanner 通过将原始发现直接发送给参与项目，消除了这一审查瓶颈。

对于开源维护者而言，推出时机颇为尴尬。Google 最近因收到越来越多无效的自动化报告，暂停了其开源漏洞奖励计划的部分内容。curl 项目也因维护者难以应对低质量提交而终止了漏洞赏金计划。

Anthropic 认为，其报告如今提供的证据远优于此前令维护者感到困扰的 AI 生成发现。早期项目反馈在部分案例中支持这一说法。不过，这项公开服务尚未证明其准确性是否能在更广泛的代码仓库中保持稳定。

Anthropic OSS Scanner 以人工审查换取速度

Anthropic OSS Scanner 让维护者能更早获知潜在漏洞，但每个参与项目都需自行验证模型的结论。

根据 OSS Scanner 发布公告，参与项目将定期接受 Anthropic 最强模型的扫描。这些模型包括 Anthropic 为高级网络安全工作开发的 Claude Mythos。

这些报告完全由模型生成。Anthropic 并不承诺在发现提交给项目之前由安全研究人员进行验证。该公司明确警告，报告可能不正确或无效。

每份报告的设计不只是标出可疑代码位置。Anthropic 表示，在可行时还会提供解释、复现说明和候选补丁。报告还可能包含代码历史分析，指出疑似缺陷何时出现。

这些证据至关重要，因为维护者需要一套可重复执行的方法，以区分真实漏洞与看似合理的模型输出。具体的复现程序可让工程师运行相关代码，并观察报告所述行为是否确实发生。

候选补丁可以缩短后续处理步骤，但并不能免除审查、测试、兼容性检查和下游协调的需要。安全修复有时会改变用户或依赖软件默认依赖的行为。

Anthropic 在更广泛开放注册前，已与数十个开源项目测试了这条流程。据该公司称，这些早期扫描产生了数百份报告。Anthropic 表示，多个发现可组合成无需认证的远程代码执行漏洞利用。

这是一类严重漏洞，因为攻击者可能无需先登录受影响系统即可执行代码。不过，Anthropic 尚未公布对这些早期结果的完整独立评估。

此次发布扩展了 Anthropic 先前通过协调漏洞披露计划开展的工作。在这一流程中，安全研究人员会先审查发现，再通知维护者。公开披露通常遵循既定时间线。

OSS Scanner 建立了一条独立的快速通道。其自动化发现会通过电子邮件私下发送给维护者，Anthropic 表示不会按标准披露期限自动公开这些发现。

如果 Anthropic 后来通过人工审查计划验证了某项发现，该报告便可能进入公司现有的披露流程。在此之前，自动化报告仍是一项未经验证的私下提交。

这种区别至关重要。Anthropic 并非为已加入的软件提供安全认证。它提供的是另一类漏洞假设来源，并在系统成功时以可复现证据作为支持。

数据解释了 Anthropic 为何改变流程

这项服务之所以存在，是因为 Anthropic 的模型生成候选发现的速度远快于其研究人员能够验证的速度。

Anthropic 表示，在过去六个月中扫描重要软件项目时，发现了超过 29,000 个候选漏洞。同期，其研究人员人工审查了约 6,000 份报告。

这意味着超过 23,000 个候选发现尚未经过完整的人工审查流程。其中一些代表真实的安全问题，另一些则可能是重复项、误解、影响较低的缺陷，或模型得出的错误结论。

Anthropic 还表示，维护者越来越多地要求批量获取未经验证的输出。该公司称，已向要求接收所有可用内容的项目发送了近 5,000 项未经验证的发现。

这些数字解释了 Anthropic OSS Scanner 背后的运营逻辑。若继续要求人工审查，将限制 Anthropic 能覆盖的代码仓库数量。取消该要求则会同时提高覆盖范围、扫描频率和不确定性。

该公司将这一转变与模型性能的提升联系起来。Anthropic 表示，语言模型在 2025 年初仅能发现 CyberGym 基准测试中不足 20% 的漏洞，而在 2026 年这一结果已超过 85%。

基准测试是标准化测试集，并不能保证实际环境中的表现。真实代码仓库包含不寻常的构建系统、未文档化的假设、生成代码以及项目特有的安全边界。

模型也可能识别出真实的软件缺陷，却无法正确判断其安全影响。一个位于不可达测试工具中的越界读取，与通过网络服务暴露的同类问题，风险并不相同。

Anthropic 自身的数据还揭示了第二项限制。发现候选问题不再是唯一稀缺资源。验证、优先级排序、修复和披露正成为工作流中更困难的部分。

这种转变给没有专职安全团队的项目带来了压力。一个重要的基础设施库可能依赖少数维护者，他们还要处理功能请求、回归问题、打包问题和社区支持。

即使是结构良好的报告也会消耗注意力。必须有人复现行为、确认受影响版本、评估可利用性、设计安全修复方案并协调发布。

安全团队长期以来一直使用静态分析、模糊测试和依赖项扫描来识别可疑行为。模糊测试会向软件输入意外数据，以暴露崩溃或其他故障。

AI 漏洞扫描加入了一层推理能力。模型可以检查函数之间的关系、推断预期行为、审视版本历史，并构造针对性测试。

Anthropic 表示，其模型有时会在传统技术未发现问题后探索新的调查路径。早期研究包括检查源代码控制历史，以及为疑似漏洞编写概念验证程序。

这种更广泛的推理能力能够发现基于模式的工具遗漏的缺陷，也可能产生一套具有说服力但错误的叙述。因此，随附证据的质量比解释语言是否流畅更重要。

开源维护者成为最终验证层

Anthropic 的免费服务将昂贵的模型计算从维护者身上转移出去，但并未消除安全分诊的人力成本。

核心维护者必须通过项目的注册代码仓库选择加入。他们需要提交包含配置详情和软件构建说明的拉取请求。

每个项目需提供代码仓库地址、主要安全联系人和 Dockerfile。Dockerfile 描述了在容器内构建项目所需的环境和命令。

项目还可以提供威胁模型。这份文档说明哪些资产重要、不受信任的数据从何处进入，以及维护者如何划分严重程度。

这些背景信息可避免明显误解。否则，扫描器可能将有意设计的行为视为漏洞，或夸大从不处理不受信任输入的代码的重要性。

Anthropic 会在隔离的虚拟机中构建参与项目。设置过程可能使用网络访问来获取所需依赖项。实际安全分析则在经过加固、无互联网访问的沙箱中运行。

随后，发现将通过电子邮件发送给项目指定联系人。维护者可通过在注册配置中发布 OpenPGP 密钥，请求加密投递。

这项服务仅面向符合资格的开源项目。Anthropic 表示，其资格标准与 Google OSS-Fuzz 计划使用的标准相似。项目应对基础设施或用户安全具有关键影响。

这一标准使 OSS Scanner 不同于任何人都可用于任意代码仓库的公开工具。Anthropic 控制注册，并为获接纳项目承担模型计算成本。

该公司还采用了比其通用商业安全产品更具实验性、更耗费 token 的扫描方法。这一选择使开源服务成为更深入审计的试验场。

维护者在注册后仍保有控制权。他们可以编辑配置、更新构建说明、暂停扫描，或通过另一项拉取请求退出项目。

他们也决定如何处理每项发现。Anthropic 不会自动创建公开 issue、分配漏洞标识符，或对原始自动化输出施加披露时限。

这种方式降低了错误报告在公开场合指控项目发布可被利用漏洞的可能性，也避免在维护者评估补丁前暴露技术细节。

然而，私下投递无法解决产能限制。一个小型项目仍可能收到多于志愿者可处理数量的可信报告。Anthropic 尚未宣布适用于所有项目的报告量上限。

项目将需要自己的接收规则。一套实用的工作流应将可复现、可从外部触达的问题，与需要不现实条件才能触发的崩溃区分开来。

团队还需要持久的技术记录。可搜索的工程知识库可以保留复现步骤、受影响版本、补丁决策和后续任务。

当多份报告具有相同根本原因时，这些文档尤为重要。缺少它们，不同维护者可能重复同一调查，或在不同分支中应用不一致的修复。

AI 漏洞扫描如今面临准确性考验

核心问题不再是 AI 模型能否发现漏洞，而是它能否提供足够多经验证的有效信号，以证明维护者投入注意力是合理的。

Anthropic 最有力的早期证据来自测试过该系统的项目。PostgreSQL 贡献者 Noah Misch 表示，数份报告识别出了缺陷，并包含几乎可直接使用的修复方案。

OpenSSL Corporation 的 Anton Arapov 对原始输出给予了不逊于人工报告的积极评价。他强调，获得可用的漏洞利用代码很有价值，因为工程师可以直接对其进行测试。

据 Anthropic 发布的反馈，最具体的报告结果来自 wolfSSL。该项目收到了 74 项发现，除两项外均被认为有效。其中五项发现成为通用漏洞披露（Common Vulnerabilities and Exposures）记录，通常称为 CVE。

这一结果表明，在一次早期部署中实现了较高的准确率。但它并不能证明在不同编程语言、项目类型、构建配置和威胁模型中也能达到相同水平。

该样本同样来自 Anthropic 自身的发布材料。该公司尚未发布完整数据集，说明其试点中每一份被接受、被拒绝、重复和存在争议的报告。

独立评估需要的不只是统计报告数量。研究人员还应考察有效性、严重程度、重复率、复现耗时、修复耗时，以及建议修复方案引发的回归数量。

维护者投入也是另一项重要指标。即使扫描器能发现更多真实缺陷，若每份有效报告都夹杂在大量看似可信的误报之中，整体仍可能造成负担。

这种风险并非理论上的担忧。其他开源社区也曾经历自动化漏洞提交激增、但缺乏充分证据的情况。

Google 表示，在自动化报告大幅增加后，它暂停了 Open Source Software Vulnerability Rewards Program 的一部分。根据该公司的说明，其中大多数提交都无效。

curl 项目于 2026 年 1 月结束了漏洞赏金计划。其维护者曾多次警告，AI 生成的报告正在消耗时间，却没有带来相应的安全价值。

Linux 维护者也表示，重复的自动化报告很难管理。多个人可能运行类似工具、发现同一种可疑模式，并各自提交几乎完全相同的报告。

Anthropic 的自愿加入设计解决了部分问题。只有获得授权的维护者才能为项目注册，报告会直接发送给指定联系人。没有任何经济奖励鼓励外部人员最大化提交量。

强制要求提供复现程序也提高了证据标准。能够展示可观测行为的报告，比仅仅将某段代码模式标记为危险更有价值。

不过，复现程序可以证明发生崩溃，却无法证明存在有意义的攻击路径。它也可能依赖于人为设置的构建选项，或真实用户从未部署的配置。

候选补丁带来了另一层不确定性。补丁可能让测试不再触发问题，却仍未修复底层漏洞；它也可能引入其他错误，或破坏下游兼容性。

早期结果值得审慎关注，而非自动信任。Anthropic OSS Scanner 必须证明，在注册范围扩展至协作性试点项目之外后，其输出仍然有用。

OSS Scanner 补充现有安全工具

Anthropic 将其扫描器定位为额外的发现系统，而不是模糊测试器、依赖数据库、代码审查或协调披露机制的替代品。

最明确的历史参照是 Google 的 OSS-Fuzz service，该服务一直利用模糊测试基础设施持续测试重要的开源项目。

当工具能够生成可触发有意义程序行为的输入时，OSS-Fuzz 非常有效。它尤其适用于解析文件、网络消息或其他不受信任数据的软件。

不过，模糊测试依赖测试框架和可观测的失败结果。一些授权错误、业务逻辑缺陷和多步骤攻击路径不会立即导致崩溃。

大语言模型可以推理这些关系。它们能够追踪数据在不同组件间的流动，考虑项目声明的安全模型，并生成有针对性的实验。

传统静态分析提供了另一种参照。它无需执行完整程序即可检查源代码，并应用规则识别高风险的数据流或模式。

静态分析器具有可重复性，并可在每次软件变更期间运行。其价值取决于规则质量、语言支持，以及团队管理持续出现警告的能力。

软件成分分析聚焦于所包含的软件包和已知漏洞。它可以告知团队某项依赖是否匹配受影响版本，但通常无法发现此前未知的缺陷。

Anthropic 的服务面向源代码内部的未知漏洞。其模型并不局限于将代码库与现有漏洞目录进行匹配。

在所有这些方法中，人工审查仍然必不可少。安全工程师了解部署环境、攻击者动机、兼容性要求，以及扫描器即时测试环境之外的后果。

这些工具也可以相互加强。AI 生成的假设可以转化为模糊测试目标；模糊测试器发现的崩溃则可为模型进行根因分析提供具体证据。

模型可以提出补丁，而静态分析和回归测试可以检查该变更是否引入新问题。随后，依赖分析可识别需要发布更新版本的下游产品。

当 Anthropic 的研究人员验证某个问题时，其标准披露政策仍然适用。该政策通常规定先行通知，随后在 90 天后或补丁发布后进行披露。

对于正在遭受利用的严重漏洞，该政策允许采用更短时间表。它还为正在推进修复工作的维护者规定了延期机制。

原始 OSS Scanner 报告不适用这一自动时间表。Anthropic 表示，除非它们随后进入人工审查流程，否则不会公开发布。

这种分离为维护者留出了调查空间。但对于长期未解决的发现，它也带来了一个尚未回答的治理问题。

Anthropic 表示，未来可能会为部分高严重性自动化发现引入披露期限。该公司承诺将提前通知，并允许项目在政策变化时退出该服务。

目前，这项服务更倾向于提供私密的防御性访问，而非公共问责。这是合理的上线立场，但它高度依赖参与的维护者作出负责任的响应。

决定该服务是否有效的因素

三个信号将表明 Anthropic OSS Scanner 会成为有用的安全基础设施，还是又一个要求苛刻的自动化报告来源。

第一个信号是新注册项目的体验。Anthropic 的试点反馈来自技术能力强、安全流程成熟的成熟团队。

更广泛的注册将考验该扫描器在不同语言、架构和维护模式下的表现。结果应能揭示其早期准确性是否能迁移到经过筛选的群体之外。

有公开记录的修复将提供有用证据。提交引用、CVE 记录和维护者复盘可以表明，哪些报告带来了有意义的安全改进。

署名并非强制要求，但 Anthropic 鼓励项目在相关提交中加入扫描器报告标识符。这些标识符可以帮助公司衡量哪些发现促成了补丁。

第二个信号是报告质量随时间的表现。Anthropic 最终应在不暴露未解决漏洞的前提下，发布汇总的准确率、重复率、严重程度和修复数据。

最具参考价值的衡量标准不会是候选发现总数，而是维护者无需投入过多调查就能复现、接受并修复的报告占比。

误报率下降将强化 Anthropic 的论点，即大语言模型已经跨越了重要的实用性门槛。分类处置成本上升则会削弱这一论点。

第三个信号是其他安全计划如何应对。Google 计划在处理无效自动化提交后，重新审视其暂停的开源奖励流程。

成功部署 Anthropic 的服务，可能会影响漏洞赏金和披露计划所采用的证据标准。复现程序和可测试补丁或许会成为所有机器生成报告的预期要求。

糟糕的部署则可能促使采用更严格的过滤机制。除非获得认可的组织进行人工验证，维护者可能会默认拒绝自动化发现。

Anthropic 还必须关注攻击者的适应性。同样可用于发现防御性问题的模型能力，也能帮助恶意研究人员调查被广泛部署的软件。

该公司表示，它围绕高级网络能力实施了访问控制和监控。OSS Scanner 通过在隔离环境中运行并私密交付发现，进一步限制了风险暴露。

这些措施无法消除更广泛的竞赛。模型将持续改进，类似能力也会扩散到各家服务提供商、安全公司和本地系统。

这使得修复速度愈发重要。如果项目无法在攻击者利用漏洞前完成复现、修补、测试和分发修复，那么率先发现漏洞提供的保护就微乎其微。

开源维护者应将该服务视为额外的安全输入，而不是对其代码的裁决。符合条件的项目可以审查注册要求，并决定自己是否拥有足够的分类处置能力。

更好的问题不是 AI 扫描器是否偶尔会犯错。每种安全技术都有局限。真正的问题是，Anthropic 的报告节省的工程时间是否多于其消耗的时间。

Anthropic OSS Scanner 现在必须在公开环境中证明这一平衡。未来数月维护者的实际结果，将比其模型声称发现的漏洞数量更重要。