Anthropic OSS Scanner 免费，但维护者承接分诊工作

Anthropic 于 10 月 8 日推出 OSS Scanner，为符合条件的开源项目免费提供定期 AI 安全扫描。该服务会将发现结果未经人工审查便直接发送给维护者，形成了明确的取舍：漏洞发现更快，但验证与修复仍牢牢掌握在人类手中。

Anthropic OSS Scanner 是一项自愿加入的服务，并非面向所有代码仓库的公共扫描器。核心维护者必须申请，Anthropic 会逐一评估项目。获准项目将收到包含漏洞复现、技术说明以及模型能够生成时的修复建议的报告。

这一服务源于 Anthropic 发现的潜在漏洞远多于其安全审查人员所能处理的数量。它也紧随 Google 长期运行的 OSS-Fuzz 项目，以及 OpenAI 进入基于智能体的代码安全领域之后。竞争已不再局限于发现错误；更艰难的较量在于，谁能在不压垮维护者的前提下，将模型输出转化为可信、可部署的修复方案。

Anthropic OSS Scanner 实际改变了什么

Anthropic 正将未经审查的模型发现结果，从内部队列转入那些明确请求接收它们的开源维护者工作流中。

根据 Anthropic 的自愿加入扫描器，已加入的项目将定期接受其当前最强模型的扫描。Anthropic 特别指出，Claude Mythos 是用于生成报告的模型之一。

每份报告都可能包含独立完整的复现程序，即能够重现疑似漏洞的代码或操作说明。报告还可能包含解释、基于历史记录估算的漏洞引入时间，以及候选补丁。

这一套内容很重要，因为一条孤立的警告在创造价值之前，先会制造工作。维护者必须定位相关代码、复现行为、判断严重性，并设计安全的修复方案。可靠的复现程序和可用的补丁，可以缩短其中多个步骤。

Anthropic 表示，它曾与数十个开源项目测试该服务的早期版本。这些测试产生了数百份报告，其中包括研究人员组合成未认证远程代码执行链的漏洞。此类攻击链允许攻击者在无需先登录受影响系统的情况下运行代码。

该公司还发布了一份验证样本，覆盖 48 个项目中 97 项被评为严重或高严重性的发现。独立渗透测试人员认定，其中 85 项符合 Anthropic 的协调披露标准。

对于另外 12 项发现，Anthropic 表示其中 11 项是真实漏洞，但重复了已知问题或其他扫描结果；另有 1 项被判定无效。这些数据描述的是经过筛选的高严重性样本，并不代表未来每份报告的准确性。

Anthropic 另称，预计运营中的服务真实阳性率将超过 90%。这一预测仍是公司的估计，不应被视为在不同项目、编程语言和严重性等级之间已得到独立确立的准确率。

准入边界同样重要。OSS Scanner 面向的是对基础设施或用户安全具有关键影响的项目。Anthropic 表示，将采用类似 Google OSS-Fuzz 所使用的标准，并随后逐案审查。

这使该服务具有选择性，而非普遍适用。一个受欢迎的业余代码仓库并不会自动符合资格；而一个不太显眼的库，可能因其他系统依赖它而获准。

核心维护者通过向 Anthropic 的公共代码仓库提交拉取请求来加入。这一要求使同意过程明确化，也让项目团队有机会评估自己是否能够处理持续到来的发现结果。

Anthropic 计划为缺乏这一处理能力的项目保留人工审查的披露流程。这形成了两条路径：准备充分的团队获得更快的原始输出，而资源受限的团队则继续接收经过专家审查、速度较慢的发现结果。

这一区别避免了“免费扫描”沦为无差别投递。它也揭示了真正提供的产品：Anthropic 并未移除安全审查工作流，而是让有能力的项目更早接触该工作流的前端。

AI 漏洞发现已超出人工审查的承载能力

该扫描器之所以存在，是因为 Anthropic 生成候选漏洞的速度，已快于专家验证、披露和修复它们的速度。

Anthropic 表示，其模型在六个月的扫描期间发现了超过 29,000 个候选漏洞。在服务宣布时，人工审查人员仅手动评估了约 6,000 个。

该公司称，维护者此前已批量请求近 5,000 份报告。这些团队接受未经验证的发现结果，是因为等待 Anthropic 完整审查流程本身也带来了安全风险。

这些数字暴露出不断扩大的产能失衡。模型可以并行检查大量代码路径，但每一份可信报告仍会进入人工系统。必须有人复现漏洞、去除重复项、评估实际暴露面、协调披露、合并修复并发布更新。

Anthropic 早前的Glasswing 结果也在更大规模上显示出同样的不平衡。该公司报告称，使用 Mythos Preview 扫描了超过 1,000 个开源项目。

该模型在 23,019 项发现中，将 6,202 项标记为高或严重级别。独立安全公司或 Anthropic 审查人员评估了其中 1,752 项高严重性发现。

在这些已审查的发现中，1,587 项有效，使该评估样本中的真实阳性率达到 90.6%。然而，只有 1,094 项仍维持确认的高或严重评级。

这一差异至关重要。模型可能识别出真实的软件缺陷，却高估其安全影响。严重性取决于部署环境、可达代码路径、认证要求、已有缓解措施以及被利用后的后果。

Anthropic 承认，一些维护者认为其评级偏高。另一些人则表示，扫描器误解了其项目的威胁模型，也就是说，它对攻击者、资产和可信边界的假设是错误的。

一个有效漏洞若被赋予错误优先级，仍可能浪费稀缺时间。维护者可能仓促修复一个不太可能发生的问题，而一个不那么引人注目的漏洞仍持续暴露。他们也可能推迟常规可靠性工作，转而调查模型生成的紧急问题。

Glasswing 项目还报告了另一项颇具启示性的指标。Anthropic 表示，确认的高或严重漏洞平均约需两周完成修补。

这种延迟主要不是搜索问题。它反映了验证行为、设计修复方案、测试兼容性、协调发布以及通知依赖用户所需的时间。OSS Scanner 仅加速了这条链路中的部分环节。

开源软件放大了这些限制，因为关键库往往依赖小型团队。一个项目可能嵌入数千种商业产品中，却依靠志愿者完成问题分诊和版本发布。

因此，一份安全报告需要与日常维护、用户支持、文档和兼容性工作竞争资源。发送更多发现结果可以提升安全性，但前提是接收项目有足够的注意力将报告转化为补丁。

Anthropic 明确将快速通道服务限制给能够跟上节奏的团队。这项限制并非行政附注，而是防止加速发现变成自动化积压生成器的设计选择。

此次发布是 Anthropic 更广泛Cyber Mission的一部分，该计划也面向关键基础设施。该公司认为，高能力模型正比防御流程扩展得更快地落入攻击者可用范围。

这一论点解释了 Anthropic 为何在报告并不完美的情况下仍偏向速度。一个在审查队列中等待的漏洞，攻击者仍可能独立发现。更快的披露让准备充分的维护者拥有更多时间关闭这一窗口。

但速度会转移责任。当原始报告离开 Anthropic 的系统时，其内部审查瓶颈并不会消失，而是转移给选择加入快速通道的维护者。

Anthropic OSS Scanner 竞争的是上下文，而不只是覆盖范围

关键比较并非 AI 与旧式扫描器之间的对比，而是基于模型的推理与既有测试、审查方法的结合。

Anthropic 表示，OSS Scanner 的灵感来自于 2016 年开始运行的 Google OSS-Fuzz。OSS-Fuzz 使用持续模糊测试，这种技术会向软件输入各种不同或格式异常的数据，以触发崩溃和意外行为。

Google 将持续模糊测试描述为通过大规模、重复执行来发现编程错误的方法。它已成为被广泛使用的开源项目的成熟基础设施。

当系统能够自动识别故障时，模糊测试尤其擅长发挥作用。崩溃、内存违规或断言失败能够提供具体证据。工程师随后可将触发输入最小化，并追溯存在问题的代码。

语言模型扫描器则采用不同路径。它们能够跨源文件推理、推断信任边界、检查权限逻辑，并提出攻击序列。这种更广泛的上下文能够发现不会立即导致崩溃的缺陷。

Anthropic 以会议管理系统 HotCRP 为例。其维护者表示，报告展现出对项目复杂权限模型的理解。仅凭随机输入很难测试这类逻辑。

OpenSSL Corporation 的 Anton Arapov 也将近期报告与大约 18 个月前收到的低质量 AI 提交进行了对比。他表示，Anthropic 的原始输出有时可与人类提交的报告相当，甚至更好。

对于 wolfSSL，Anthropic 报告称，交付的 74 项发现中有 72 项有效。其中 5 项成为 Common Vulnerabilities and Exposures 记录，后者为公开追踪的安全漏洞提供标准化标识符。

这些证词表明，维护者为何可能接受原始模型输出。一份带有可用攻击利用程序的报告可以被快速验证；接近可直接使用的补丁也能缩短确认与修复之间的时间。

但这并不能证明其在整个开源生态系统中具有同等表现。PostgreSQL、OpenSSL、wolfSSL 和 HotCRP 都是拥有经验丰富维护者的成熟项目。它们的团队具备测试和处理敏感安全报告的流程。

竞争领域同样在快速发展。OpenAI 推出了Codex Security，这是一款应用安全智能体，会在分析代码仓库前先构建针对项目的威胁模型。

OpenAI 表示，其测试系统在 30 天内扫描了超过 120 万次提交。它报告称，在外部代码仓库中发现了 792 项严重发现和 10,561 项高严重性发现。

这些数字采用 OpenAI 的分类标准和测试样本，因此无法与 Anthropic 的结果直接比较。两家公司对严重性、验证和代码仓库选择的定义可能不同。

不过，这两款产品都反映出同一种战略转向。前沿模型提供商日益希望其系统先理解应用，再识别漏洞。它们竞争的焦点是上下文、验证、修复支持和工作流集成。

Anthropic 的差异化优势在于：为选定的开源维护者提供免费、定期的快速通道。Claude Security 仍是面向组织使用的通用代码扫描产品，而 OSS Scanner 则将最强模型用于符合条件的公共项目。

该服务并不能取代模糊测试器、静态分析、依赖项扫描、代码审查或渗透测试。Anthropic 自身也建议进行人工验证，其报告可能会误解项目的运行假设。

更现实的安全技术栈应结合这些方法。传统工具可以持续检测已知缺陷模式和运行时故障；模型则能够调查需要更广泛推理才能发现的关联；人工审查者最终决定相关理论是否符合实际。

这种分层方法也能控制模型风险。即使某项发现的解释听起来很有把握，若缺乏可复现的证据，也不应优先于已验证的崩溃问题。

因此，最终胜出的扫描器不会是产出问题数量最多的系统，而是能够可靠帮助维护者修复重大漏洞，且节省的注意力多于其消耗的系统。

免费报告将最困难的工作转移给维护者

OSS Scanner 消除了模型访问成本，但并未消除根据其发现采取行动所需的劳动、责任或运营风险。

每份报告都未经 Anthropic 的人工审查或分流。维护者必须判断相关行为是否可复现、所提议的利用方式是否反映真实威胁，以及建议的补丁是否会引入回归问题。

候选补丁尤其值得谨慎对待。安全修复常会改动解析器、身份验证路径、内存处理或兼容性行为。一个在局部看来正确的改动，可能会破坏下游软件，或引入新的漏洞。

项目还需要受保护的漏洞披露渠道。在修复到达用户之前公开利用方式，可能使依赖受影响库的系统面临风险。在维护者协调发布和安全公告期间，报告必须保持机密。

Anthropic 现有的协调漏洞披露流程在此仍然适用。根据该流程，新发现的漏洞通常会在一个修复窗口期后才公开，以便用户有时间更新。

快速通道改变的是谁来执行初步验证，而不是对负责任披露的需求。参与的维护者成为模型生成的利用方式与更广泛软件生态系统之间的第一道人类过滤器。

还存在重复报告的问题。Anthropic 对 97 项发现的验证样本中，包含 11 个真实问题，但它们重复了已知缺陷或其他发现。在维护者识别出重复之前，重复报告依然会消耗注意力。

代码仓库已经在接收嘈杂的 AI 生成投稿。Curl 维护者 Daniel Stenberg 曾记录过低质量报告激增的情况：它们模仿可信的安全研究，却没有提供可靠证据。

Anthropic 的 OSS Scanner 部分正是为应对这段历史而设计。其报告包含复现步骤和解释，同时访问权限仅限获批项目。与匿名自动化投稿相比，这些设计选择应能提升信噪比。

不过，Anthropic 仍要求维护者信任一套私有扫描管线。该公司尚未发布一项完整、可独立复现的评估，覆盖所有受支持的语言、项目类型和严重性类别。

扫描器还会将代码发送至 Anthropic 的模型和系统。开源代码是公开的，但未发布分支、私有问题讨论和受限修复方案仍可能包含敏感信息。在接入相关工作流之前，维护者需要明确的运营边界。

另一项风险涉及漏洞利用的双重用途。能够发现并复现漏洞的模型既可支持防御者，也可帮助攻击者。OSS Scanner 将结果分发限制在已加入计划的核心维护者范围内，从而减少了对其发现的不加区分访问。

这种更广泛的能力无法永远保持独占。Anthropic 表示，具备类似能力的模型将会广泛可得。竞争对手已经通过云服务和本地命令行工具提供代码安全代理。

这在发现与修复之间形成了一场竞赛。若攻击者自动化侦察的速度快于项目自动化验证和补丁部署的速度，更多发现并不会立刻让生态系统更安全。

Anthropic 自身的数据也显示了这一差距。Project Glasswing 已识别出数千个可能的漏洞，但在公司发布初步更新时，只有一小部分达成了已确认的修复。

因此，维护者应衡量已完成的修复工作，而不是报告数量。有效指标包括已复现的发现、获接受的严重性评级、已合并的补丁、发布时间、下游采用情况以及重新打开的问题。

团队也需要明确责任归属。不能让一名维护者在没有备用审查者、披露协调、测试和发布管理计划的情况下，独自接收源源不断的发现。

对于较大型项目，安全报告可进入与事故和高风险变更相同的系统。一套工程知识库可以在不同审查者之间保留威胁假设、既有决策和修复证据。

较小项目则面临更艰难的选择。加入计划可让它们获得原本几乎无力资助的能力，但也可能形成志愿者无法安全处理的队列。

当项目缺乏专门的安全能力时，Anthropic 的人工审查路线仍是更好的选择。缓慢但经验证的披露，可能比立即获取每一项候选发现更有价值。

真正的考验在于补丁能否跟上进度

只有当参与项目能够更快修复重大漏洞，同时不产生不安全补丁或耗尽维护者精力时，Anthropic OSS Scanner 才算成功。

首个值得关注的信号，是报告转化为已验证修复的比例。Anthropic 已公布 Project Glasswing 下发现、审查、披露和修复漏洞的数量。OSS Scanner 也应跟进发布类似指标。

报告数量上升本身只能说明模型吞吐量增加。达到发布版本的已验证发现占比上升，才能说明该服务改善了真实的安全结果。

严重性变化值得单独报告。Anthropic 应披露维护者下调发现评级、否定威胁假设、识别重复项或大幅改写建议补丁的频率。

这些信息将检验公司预期的真阳性率，也会揭示扫描器是否在优先处理正确的工作，而不是仅仅定位真实缺陷。

第二个信号是维护者留存率。项目可能因为服务免费而加入，但若报告的数量或敏感性超出其承受能力，也可能退出。

持续参与意味着复现步骤和补丁所节省的工作量超过验证所消耗的精力。退出、暂停接收报告或要求降低扫描频率，则表明瓶颈只是被转移到了下游。

Anthropic 还应说明扫描频率如何适配不同项目。大型安全团队与由志愿者主导的库，无法以同样的速度吸收报告。定期扫描需要一个与接收方能力挂钩的运营定义。

第三个信号是竞争对手的反应。Google 可以围绕 OSS-Fuzz 扩展模型推理能力，而 OpenAI 可以加深 Codex Security 对开源项目的覆盖。成熟的安全厂商则可以将专有威胁数据与基于模型的代码分析结合起来。

如果各提供商趋向于提供定期、具备上下文感知能力且附带可操作补丁的扫描服务，竞争将强化 Anthropic 的论点。这会削弱 OSS Scanner 的差异化优势，却可能改善更多项目的防御能力。

若证据表明厂商仍保留广泛的人工验证，则会指向另一个方向。这将表明，尽管基准测试表现出色，原始前沿模型输出对大多数维护者而言仍然风险过高。

Anthropic 更广泛的预测是，AI 最终将有利于防御者。该公司认为，模型应当让发布前发现缺陷变得更容易，并从一开始就帮助构建更安全的软件。

未来几个月将检验一个更狭窄的命题：入选的开源团队能否将更高数量的未经审查报告，转化为安全修复的速度，快过对手利用同类模型的速度？

即使开发者自己的代码仓库从未符合条件，答案也依然重要。现代应用通过框架、加密库、数据库、构建工具和软件包依赖继承代码。上游修复的一个缺陷，可能保护许多下游系统。

企业安全团队应跟踪其依赖项是否加入该计划，以及修复版本是否已部署到运行环境中。发现漏洞，并不能保护仍在运行受影响版本的应用。

开源维护者应在申请前评估能力。他们需要有人能够复现发现、质疑严重性评级、审查补丁、协调披露，并发布经过测试的版本。

Anthropic OSS Scanner 降低了发现复杂漏洞的门槛，但并未降低发现之后的每一道门槛。

这正是此次发布比又一个免费开发者工具更重要的原因。Anthropic 正在测试：前沿模型能否在真实维护体系中成为可靠的安全贡献者。

答案不会出现在基准测试分数或庞大的发现总数中。它将体现在更少可被利用的发布版本、更短的修复周期、可信的严重性判断，以及仍有时间维护项目的维护者身上。

如果你的项目明天收到数百份看似可信的安全报告，你的团队能否安全地验证并解决它们？这个运营问题应决定，AI 扫描的早期访问权限究竟意味着解脱，还是又一个紧急队列。