Anthropic OSS Scanner 免费，但维护者必须验证其发现

Anthropic 于 10 月 8 日推出 Anthropic OSS Scanner，这项免费服务让开源项目能够定期接受其最强 AI 模型的安全审计。服务内容包括漏洞说明、复现步骤和建议补丁。不过，这些报告在未经人工审查的情况下便会送达维护者。

这种取舍定义了该服务。Anthropic 通过移除内部审查人员这一环节，能够更快交付发现结果；随后，项目团队必须判断每个漏洞是否有效、优先级是否准确，以及修复是否安全。

此次发布意味着 Anthropic 不再局限于有限的安全研究项目和付费企业扫描服务。它也让该公司加入了 OpenAI 和 Google 的行列，参与将前沿模型用于软件防御的竞赛。这场竞争已不只是寻找漏洞，而是将不断涌现的机器生成发现转化为可信补丁。

开源维护者有充分理由接受这类帮助。被广泛使用的项目往往由小型团队维护，预算有限，安全责任却不断扩大。然而，当每一份报告都需要测试、披露决策和发布协调时，免费发现仍可能带来实际成本。

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

Anthropic OSS Scanner 让维护者直接获取原始 AI 发现结果，更快交付既是其主要优势，也是其核心风险。

这项服务采用自愿加入方式，符合条件的开源项目可免费使用。Anthropic 表示，加入的代码库将定期接受其最强模型的扫描，包括 Claude Mythos。

根据扫描器发布公告，每份报告可包含独立的复现程序、漏洞说明，以及在可用时提供的候选补丁。复现程序是一种精简测试，可让维护者触发并确认疑似缺陷。

这一格式很重要，因为模糊的警告会将大部分调查工作重新交给接收方。可运行的复现程序能为工程师提供明确的起点；建议补丁则可进一步缩短从发现到修复的路径。

项目可通过公开 GitHub 代码库加入。维护者需要提交一个包含配置文件、构建流程、联系信息和可选威胁模型的拉取请求。

扫描器随后会在隔离虚拟机中构建项目，并在分析前将该环境移至无法访问互联网的网络中。发现结果会通过电子邮件发送给项目指定联系人，而不会自动公开发布。

加入说明明确指出，报告在送达前不会接受人工审查。Anthropic 还表示，不会对这些发现施加标准的 90 天披露期限，也不会将其公开。

这一政策限制了一项直接风险：不确定的报告不会自动暴露疑似弱点，也不会启动公开披露倒计时。维护者仍可控制验证、修复以及后续可能发布的安全公告。

不过，保密并不能解决验证问题。模型可能识别出真实的编码缺陷，却误判其可达性、严重程度或实际影响。它也可能提出一种补丁，封堵一条路径的同时改变其他地方的预期行为。

Anthropic 公开承认了这种可能性。该公司将此服务定位为一条可选的快速通道，面向有能力处理未经审查输出的项目。没有这种能力的项目则可继续留在 Anthropic 的协调披露流程中，由人工审查人员在交付前检查发现结果。

由此形成的实际上是双轨系统。一条路径强调审查质量和受控披露；另一条路径强调频率和速度，并由维护者承担更多分诊责任。

Anthropic 表示，它已与数十个项目验证了早期版本。这些披露产生了数百份报告，其中包括据称可构成未经身份验证的远程代码执行链的缺陷。

该公司还请渗透测试人员审查了涉及 48 个项目的 97 项高严重性和关键发现。Anthropic 称，其中 85 项发现，即 88%，符合其协调披露标准。另外 11 项确有问题，但属于已知问题或同一次扫描中的重复发现；另有一项无效。

这些结果令人鼓舞，但它们来自 Anthropic 自身的验证。它们并不能证明该服务在不同编程语言、构建系统、架构或项目规模下的表现。

这些结果也说明，原始准确率并非完整衡量标准。重复报告可能描述了真实缺陷，却仍会消耗维护者稀缺的时间。一份严重性评级被夸大的有效报告，同样可能扰乱项目的发布优先级。

因此，该服务改变的不只是检测速度。它将运营判断的第一道防线，从 Anthropic 的安全团队转移给了原本就负责受影响代码的人。

此次发布将研究项目转变为开放基础设施

OSS Scanner 将 Anthropic 早期的漏洞研究转化为更多维护者可直接申请的持续性服务。

该扫描器源于 Project Glasswing，这是 Anthropic 使用先进模型应对关键软件的受限项目。Anthropic 于 2026 年 4 月与科技公司、安全厂商和开源组织共同推出了这项计划。

首批参与方包括 Amazon Web Services、Apple、Broadcom、Cisco、CrowdStrike、Google、Linux Foundation、Microsoft、Nvidia 和 Palo Alto Networks。Anthropic 还向另外 40 多家组织扩展了访问权限。

Anthropic 承诺提供最高 1 亿美元的模型使用额度，并向开源安全组织捐赠 400 万美元。该计划让选定的防御方提前使用 Claude Mythos Preview，这是一款具备高级漏洞发现和利用能力的模型。

这种受控结构服务于两个目标：防御方能够提前获得模型访问权限，同时 Anthropic 限制了可能支持进攻性操作的能力被更广泛获取。

报告发现的规模很快带来了不同问题。Anthropic 在 5 月的一次更新中表示，大约 50 个合作伙伴发现了超过 10,000 个高严重性或关键漏洞。该数字是公司自行报告的总数，并非独立审计结果。

Anthropic 的 Glasswing 更新认为，主要瓶颈已从发现转向验证、披露和修复。换言之，模型产出潜在发现的速度，已超过人类能够安全处理的速度。

OSS Scanner 是 Anthropic 在不要求自身审查人员检查每一份报告的前提下扩大访问范围的尝试。该服务保留了自愿加入的边界，同时移除了限制吞吐量的核心审查阶段。

这一转变使扫描器区别于一次性的研究实践。研究团队可以选择代码库、控制扫描时机，并聚焦重要发现；持续性服务则必须支持多样化项目，并在不了解每位维护者工作流程的情况下交付有用输出。

截至 2026 年 10 月，Anthropic 已通过其协调披露流程审查了超过 6,000 份报告。人工审查有助于保护项目免受误报影响，但也延迟了部分披露。

据报道，一些维护者要求 Anthropic 提供与其项目相关的全部发现，包括未经审查的输出。OSS Scanner 将这一安排正式化，面向愿意自行进行分诊的团队。

早期反馈凸显了部分团队接受这种取舍的原因。WolfSSL 表示，收到的 74 份报告中有 72 份有效，其中 5 份最终获得漏洞编号。PostgreSQL 报告称，若干建议修复方案只需少量修改即可使用。

OpenSSL 的 Anton Arapov 将这些报告与大约 18 个月前收到的质量明显更低的 AI 提交进行了对比。他表示，Anthropic 的原始输出有时可媲美甚至超过人工报告，尤其是在包含可运行漏洞利用程序时。

Curl 维护者 Daniel Stenberg 表示，扫描器发现了多个值得处理的问题，其中包括近年来最严重的 curl 报告之一。这些说法来自经筛选的早期参与者，因此不应被视为具有代表性的基准。

不过，它们仍展示了将证据与发现一并打包的实际价值。维护者需要的并不只是一个识别可疑代码的 AI 系统；他们还需要足够的背景信息，以复现问题、评估受影响版本并准备安全发布。

这也是有组织的工程知识库发挥作用的地方。团队需要将报告与架构说明、此前的修复、职责记录和发布决策关联起来。

OSS Scanner 并不能取代这类机构知识。它为其提供了另一种输入，而且输入量可能高得多。

开源维护者成为新的安全瓶颈

这项服务降低了发现漏洞的成本，但并未消除验证和交付修复所需的人力工作。

漏洞报告是一个流程的开始，而非结束。维护者必须复现行为、确定受影响版本、评估可利用性，并检查建议补丁是否会引入回归问题。

他们可能还需要与下游发行方私下协调。一个被广泛使用的库可能出现在操作系统、云服务、应用程序和嵌入式产品中。未做好准备便发布补丁，可能会在用户完成更新前提醒攻击者。

大型厂商会雇用安全响应团队处理这类工作。许多开源项目则依靠少数维护者，而这些人还要负责功能开发、支持请求、构建失败和社区治理。

Anthropic 的扫描器面向具备足够能力处理其输出的项目。这一条件很重要，因为如果报告积累速度超过团队的评估能力，扫描频率就会带来负面影响。

即使是高质量报告也有处理成本。必须有人负责它，在受支持环境中进行测试，判断其是否影响已发布版本，并记录解决方案。

自动生成的补丁也带来了另一项审查义务。某项修改可能阻止所提供的概念验证，却未解决根本弱点。它还可能破坏兼容性、降低性能，或违背代码库其他位置的假设。

当模型缺乏完整运营背景时，风险会更大。代码库访问权限可能揭示代码和测试，但未必涵盖每一种部署模式或下游修改。

威胁模型可以缩小这一差距。Anthropic 允许项目提供描述安全边界、可信输入和重要资产的威胁模型文件。不过，维护准确的威胁模型本身也是一项持续工作。

报告优先级排序也面临类似挑战。被标为关键的缺陷，可能需要极少用户启用的配置才会出现；评级较低的问题则可能更重要，因为它位于常见的暴露组件中。

Anthropic 表示，其报告可能包含不准确的严重性评级。这意味着项目不能安全地将模型标签直接转化为发布优先级。

重复问题同样值得关注。Anthropic 的验证发现了 11 个真实问题，它们与已知问题或其他扫描发现重复。在更大规模下，重复变体可能造成待处理积压不断增长的假象，却并不代表新增的修复任务。

项目需要制定去重规则、明确责任归属路径，并保留清晰的关闭记录。它们必须区分新的漏洞与现有根本原因的另一种表现形式。

扫描器的隔离模型解决了另一个问题。在线构建、随后在无互联网访问的环境中扫描，会限制模型控制环境接触外部系统的能力。但这并不能消除所有供应链或构建时风险。

项目的 Dockerfile 和依赖项仍会决定哪些内容进入构建环境。维护者需要以审查持续集成工作流时同样的谨慎程度，审查接入配置。

因此，最有价值的采用信号将是已完成的修复，而非发现数量。即使扫描器识别出数千个看似合理的问题，如果项目无法验证并关闭它们，仍可能在运营层面失败。

这构成了此次发布最核心的反转：AI 降低了在代码中搜索的边际成本，却提升了能够作出负责任安全决策的维护者的相对价值。

OpenAI 和 Google 正在争夺通往可信补丁的路径

Anthropic 真正的竞争对手，是能够将发现、验证和修复结合起来的系统，而不是生成最长告警列表的扫描器。

OpenAI 于 2026 年 3 月以研究预览形式推出 Codex Security。这款应用安全代理会构建对代码仓库的上下文理解，调查疑似漏洞，并提出修复方案。

OpenAI 强调自动化验证和更低噪声的结果。其明确目标是发现安全团队可以采取行动的问题，而无需把大部分时间花在排除低质量告警上。

该公司还通过 Codex for OSS 将开源维护者纳入支持范围。该项目提供安全支持以及其编程工具的访问权限。

到 8 月，OpenAI 表示 Codex Security Cloud 已分析超过 30,000 个代码库中的 3,000 多万次提交。其更广泛的 Daybreak 工作将仓库扫描与拉取请求审查、定期检查、问题调查及既有安全系统连接起来。

因此，Codex Security 预览版代表了对 Anthropic 方法更为一体化的竞争。两家公司都声称，其模型能够跨代码进行推理，而非仅匹配已知模式。

Google 正通过 Big Sleep 和 CodeMender 推进相关策略。Big Sleep 专注于发现软件漏洞，而 CodeMender 则利用 Gemini 的推理能力来开发和验证修复方案。

Google 在 OSS-Fuzz 中也拥有长期的开源安全先例。该服务持续应用模糊测试，即向程序输入异常数据，以发现崩溃和不安全行为。

Anthropic 明确将 OSS-Fuzz 视为灵感来源。这一比较很有帮助，但底层方法不同。模糊测试在特定输入导致故障时提供可观察的证据。语言模型则可以对更广泛的逻辑、权限和数据流进行推理，而这些问题未必会产生简单的崩溃。

这种更广泛的覆盖范围带来了更多解释上的不确定性。模型可以追踪微妙的授权路径，但其结论仍需要在项目真实的安全语境中得到确认。

Google 的 AI 威胁研究也凸显了这些产品背后的双重用途压力。该公司报告称，发现一名攻击者使用了其认为由 AI 开发的零日漏洞利用程序。

Anthropic 提出了同样的战略论点。如果先进模型让漏洞利用变得更快，防御者就需要在攻击者利用未修复弱点之前获得相应能力。

各厂商对这种优势的包装方式不同。Anthropic 为已接入项目提供其最强模型的直接、定期输出。OpenAI 强调仓库上下文和验证。Google 则将发现能力与自动修复及其现有安全基础设施相连接。

目前没有公开证据表明，某一种方法在开源项目中始终优于其他方法。厂商统计采用了不同的范围、定义、严重性体系和审查流程。

发现数量可能包含重复项、不可达代码、已知问题，或从未被分配漏洞编号的缺陷。补丁数量同样可能掩盖被维护者拒绝或大幅改写的变更。

可信的竞争指标，是在不压垮维护者的前提下，进入已接受修复流程的独立有效漏洞数量。从初始报告到安全发布的时间同样重要。

即使没有明确赢家，这场竞争最终也可能惠及开源项目。多个系统可以通过不同的推理路径审查同一份重要代码。独立发现能够提高信心，或揭示另一款扫描器覆盖范围中的缺口。

然而，并行扫描器也可能成倍增加重复提交。服务提供方需要协调披露实践，并尊重项目特定的报告规则。

AI 安全的下一阶段将奖励那些理解这些运营边界的工具。发现一个漏洞很有价值；帮助负责的团队安全地关闭它，才是更难打造的产品。

免费扫描并不意味着零成本或零风险

当项目将 AI 输出视为结构化证据，而非权威性的安全结论时，OSS Scanner 才最有用。

这项服务最有力的理由很直接。维护者可以持续使用原本需要大量计算资源和安全专业知识才能获得的模型。

报告可能揭示现有测试、静态分析器、模糊测试器和人工审查遗漏的缺陷。其复现程序可以加速确认，而候选补丁则可缩短探索修复方案所需的时间。

该服务的私密交付模式也为项目提供了调查空间。Anthropic 表示不会公开原始发现，从而降低自动披露期限带来的压力。

不过，仍存在若干不确定性。首先，Anthropic 尚未发布足够的生产数据，来说明准确率会如何随语言、代码仓库规模或漏洞类别而变化。

报告中 88% 的协调披露接受率涵盖了 97 个经过筛选的高严重性和严重级别发现。它并未衡量一次典型扫描中生成的每一项发现。

其次，模型改进可能改变扫描器行为。较新的模型可能发现更深层的缺陷、生成更多报告，或给出不同的严重性判断。项目需要一种方法来比较不同扫描器版本之间的结果。

第三，原始模型输出可能造成安全敏感型错误。有缺陷的复现程序可能无法证明所声称的问题。拟议的补丁可能只是抑制了一种症状，而没有消除底层利用路径。

第四，报告本身包含敏感信息。电子邮件交付很方便，但项目必须控制对包含利用步骤和受影响代码路径的消息的访问。

维护者应将发现纳入受限的安全流程。他们还应验证联系地址、归档决策，并记录接受或拒绝报告的原因。

第五，这项服务依赖 Anthropic 持续的资金支持和运营决策。Defender Advantage Fund 目前支持这一免费服务，但该公司尚未承诺永久提供。

因此，“免费”指的是不收取服务费用。它并不涵盖维护者时间、测试基础设施、协调发布或下游通知工作。

还存在一个更广泛的治理问题。Anthropic 运营这些模型、选择扫描方法，并初步评估性能。独立研究人员和参与项目需要随着时间推移检验这些说法。

有用的公开证据包括匿名化的精确率数据、重复率、补丁接受率和修复时间中位数。按编程语言和漏洞类别进行拆分，会让这些数字更有意义。

项目也可以在漏洞修复后公布自身评估。这些记录可以揭示扫描器在哪些方面表现良好，以及人工调查人员仍在哪些环节承担大部分工作。

这些担忧没有一项意味着该服务本身不安全。它们界定了负责任使用的条件。

当项目拥有私密报告流程、可用的审查人员、可靠的测试，以及协调发布的权限时，就应考虑接入。缺少这些资源的项目，可能更适合采用 Anthropic 的人工审查披露渠道。

这不是在拥抱 AI 与忽视安全之间作选择，而是在不同的审查负担、交付速度和置信度之间作选择。

三个信号将表明 Anthropic OSS Scanner 是否有效

未来几个月应以已接受的修复、维护者能力和竞争性验证来评判，而非以吸引眼球的漏洞总数来评判。

第一个信号是报告转化为已接受补丁的比率。早期证词显示，一些项目获得了可用的修复方案，但更广泛的生产结果将更具意义。

一份有说服力的记录，应将独立漏洞与重复项区分开来。它还应说明维护者接受、修改、拒绝或替换了多少候选补丁。

如果项目能够在不扩大未解决安全积压的情况下更快关闭重要漏洞，这一信号将强化 Anthropic 的论点。如果未经审查的报告产生大量分诊队列，则会削弱这一论点。

第二个信号是成熟开源项目的采用情况。接入拉取请求提供了一个可见指标，但仅凭仓库数量无法讲述完整故事。

如果报告量变得难以管理，项目可能会暂停扫描。公开配置支持禁用状态，这可以揭示参与团队是否需要停止接收定期报告。

维护者评论将尤其有价值。团队可以说明发现是否附带了足够证据、严重性标签是否有用，以及补丁是否通过了其审查流程。

如果项目在处理完首批报告后仍持续接收扫描，这将强化 Anthropic 的模型。一次性试验之后普遍暂停，则意味着工作负担问题尚未解决。

第三个信号是与 OpenAI、Google 以及成熟安全工具的独立比较。同一批代码仓库应产生足够多的公开披露，以揭示覆盖范围和报告质量的差异。

公平比较不能依赖原始总数。研究人员需要匹配的项目、统一的严重性定义，以及维护者的确认。

不同 AI 系统独立发现各自不同且有效的漏洞，将支持多工具安全策略。若证据显示存在严重重复，则会加大对共享报告和协调系统的压力。

竞争方的回应同样重要。OpenAI 可以扩大对维护者的免费安全支持。Google 可以让 CodeMender 与 OSS-Fuzz 及开源项目工作流更加紧密地连接。

Anthropic 可以通过发布纵向扫描器数据并强化自动化验证来改善其地位。它还可以加入帮助项目去重、确定优先级、测试和跟踪修复的工具。

该公司已将分诊和补丁自动化确定为下一步。这项工作将决定 OSS Scanner 是继续作为发现引擎，还是成为完整修复系统的一部分。

Anthropic OSS Scanner 的出发点颇具可信度：在攻击者获得同等优势之前，让开源维护者先用上高能力模型。真正更艰难的考验，则始于第一份报告送达之后。

考虑加入该计划的维护者，应先评估自身的私下披露流程、审查能力、测试覆盖率和发布权限。随后，他们应衡量已修复的漏洞数量，而非生成的告警数量。如果 Anthropic 能帮助项目在不压垮小型团队的前提下更快发布安全修复，免费的 AI 扫描将成为有价值的基础设施。若验证仍是主要成本，行业仍需解决这款扫描器所暴露的人力瓶颈。