Anthropic OSS Scanner 加速漏洞报告，但将审查工作转移给维护者
Anthropic 在发现超过 29,000 个候选漏洞后推出了 Anthropic OSS Scanner，但这项免费服务在最快的报告路径中取消了人工审核。这一变化改变了开源维护者收到的内容，也改变了由谁来判断一条 AI 生成的警告究竟代表紧急安全漏洞、重复报告，还是噪声。
这项自愿加入的服务会定期使用 Anthropic 最强大的模型（包括 Claude Mythos）检查符合条件的开源代码库。维护者会收到包含复现步骤、根因分析以及可用时的修复建议的报告。Anthropic 承担扫描成本，参与项目则提供验证和确定结果优先级所需的专业知识。
这种安排挑战了协调漏洞披露背后的既有模式。Google 的 OSS-Fuzz 及传统安全计划强调可复现性、专家分诊和受控披露。Anthropic 正在测试：模型生成的证据是否已足够可靠，能够在人工审核员批准每一份报告之前，直接送达准备充分的维护者。
Anthropic OSS Scanner 开辟更快的报告渠道
这项服务并非只是自动化了另一种代码扫描，而是建立了从前沿 AI 模型直达开源维护者的渠道。
Anthropic 于 2026 年 10 月 8 日宣布推出 OSS Scanner。该公司将其描述为面向具有重要基础设施或用户安全影响力的成熟项目的一项免费、自愿加入服务。
核心维护者可通过 Anthropic 的公共代码库注册。他们需要提交项目配置、安全联系人，以及在容器中构建软件的说明。Anthropic 会在接纳申请者前核实其是否为合法的项目维护者。
扫描器会先在具备网络访问权限的隔离虚拟机中构建项目。随后，在其代理开始安全审计之前移除互联网访问权限。这种隔离限制了代理在分析过程中联络外部服务或传输信息的能力。
维护者还可以提供威胁模型。威胁模型会记录可信边界、恶意输入、排除的组件以及项目的严重性规则。这些背景有助于模型区分真实的安全边界与项目有意允许的行为。
Anthropic 的 scanner documentation 表示，该流程使用代理来复核发现、分析根因并准备候选补丁。这些检查仍由模型生成；每份报告在交付前均不会经过人工批准。
报告会以邮件包的形式送达。每份报告可能包含可独立运行的复现程序、漏洞说明和建议修复方案。Anthropic 也可能识别出易受攻击的行为何时被引入代码库。
这种支撑材料的完整程度至关重要。维护者无法仅凭“某个函数看起来存在风险”的简短说法安全地采取行动。他们需要可靠地复现该行为、评估暴露面，并测试补丁是否会影响现有功能。
在初次审计后，Anthropic 计划定期扫描已注册项目。后续扫描可以检查新引入的弱点，并重新审视此前模型运行遗漏问题的代码。具体频率将取决于需求和可用容量。
项目可以通过修改配置值暂停接收报告，也可以通过从注册代码库中移除其目录来退出。这使得参与具有可逆性：如果发现数量或质量变得难以管理，项目可以停止参与。
资格范围比“免费”一词所暗示的更为狭窄。Anthropic 打算优先考虑处理不可信输入或为大量下游项目提供支持的成熟软件。该公司会逐项评估申请，并可能随着参与规模扩大调整标准。
Anthropic 明确表示，该计划适合已经能够处理经验证的高严重性和严重报告的项目。这一条件为该服务划定了重要边界：它提供的是更多检测能力，而不是替代维护者调查每一项结果。
注册流程还要求项目公布可用的安全联系人。需要私密通信的团队可以提供公开加密密钥。这一选项降低了敏感报告未经保护地通过普通电子邮件传输的风险。
最终形成的服务类似一支持续可用的外部研究团队。不过，其报告会在缺乏 Anthropic 人工审核披露流程所具备保障的情况下进入项目队列。速度是其收益，转移而来的验证工作则是代价。
Anthropic 为何取消人工审核
AI 漏洞发现能力的扩张速度，已超过 Anthropic 验证、披露并协助修复其模型所发现全部问题的能力。
Anthropic 表示，其模型在发布前六个月内扫描了重要软件项目，生成了超过 29,000 个候选漏洞，而人工仅审核和分诊了约 6,000 个。
相比免费访问，这一差距更能定义此次发布。Anthropic 原本已有一套审核报告并与维护者协调的流程，但该流程无法以模型生成发现的速度吸收这些结果。
一些维护者开始索取未经验证的积压报告。根据 Anthropic 的 launch announcement，项目已请求近 5,000 份原始报告，其中包括建议补丁。这些请求表明，准备充分的团队更重视快速获取结果，而非所有报告都经过人工验证。
因此，Anthropic 将其披露系统分为两条路径。现有的协调漏洞披露流程继续交付经人工验证的发现；OSS Scanner 则为愿意自行审查模型生成输出的项目提供可选的快速通道。
这并不意味着放弃协调披露。Anthropic 表示，未经验证的扫描器报告不会触发其标准披露期限。维护者收到此类发现，并不意味着公司会将其公开。
如果 Anthropic 随后通过常规计划验证一份报告，正常的披露期可以在通知后开始。这一区别让维护者可以审查原始发现，而不会自动进入公开倒计时。
该系统源自 Project Glasswing，这是 Anthropic 利用先进模型开展防御性网络安全工作的更广泛计划。今年 5 月，该公司表示，大约 50 家合作伙伴发现了超过 10,000 个高严重性或严重漏洞。
Anthropic 还报告称，其扫描了超过 1,000 个开源项目。当时，Claude Mythos Preview 在总计 23,019 项发现中，将 6,202 项归类为高严重性或严重。这些数据是公司自行报告的估计值，而非完成的独立审计结果。
更广泛的 Glasswing results 显示了第二个瓶颈。发现疑似漏洞所需的时间，可能远少于验证它、协调修复、测试变更及分发已修补软件所需的时间。
模型可以在数千个代码库中重复执行分析。维护者则必须理解本地设计决策、兼容性承诺、发布实践和下游依赖。这些职责无法以相同速度扩展。
Anthropic 此前与 Firefox 的合作同时说明了两面。Claude Opus 4.6 在为期两周的合作中发现了 22 个漏洞，Mozilla 将其中 14 个评为高严重性。研究人员在独立虚拟机中验证第一个严重发现后才提交报告。
这项 Firefox security work 涉及 Anthropic 与 Mozilla 的积极合作。它表明，在有专家团队可复现发现并管理修复时，AI 能够加快漏洞发现。
OSS Scanner 试图将这种能力扩展到少数高强度合作之外。其做法是将有能力的维护者视为最终审核者：模型提供覆盖范围，每个项目提供判断力。
这一设计也反映出模型生成报告质量的变化。Anthropic 引用了基准测试结果，显示其在漏洞发现方面取得显著提升。但基准测试仍无法预测模型在所有语言、架构或威胁模型中的表现。
维护者反馈提供了更实际的信号。Anthropic 表示，早期参与者认为许多报告很有用，尤其是其中包含可运行的漏洞利用程序或接近可用的补丁时。这些说法仍属于 Anthropic 的发布材料，而非独立调查。
公开的最强样本包含来自 48 个项目的 97 项严重或高严重性发现。外部渗透测试人员发现，其中 85 项达到 Anthropic 的披露标准。另外 11 项是实际问题，但与已有发现重复；还有 1 项无效。
按照 Anthropic 所述标准，该样本的接受率为 88%。这令人鼓舞，但并不能确立普遍的误报率。该样本聚焦于已被标记为严重或高严重性的发现。
选择效应同样值得注意。Anthropic 在公布结果前，已花费数周时间与数十个项目一起验证该流程。在不熟悉的项目、特殊构建系统或安全边界文档不足的环境中，表现可能有所不同。
因此，此次发布是对“发现过剩”的运营回应。Anthropic 拥有的疑似漏洞多于其专家能够及时审核的数量。OSS Scanner 提出的问题是：成熟项目能否安全地承担其中一部分验证工作。
Anthropic OSS Scanner 对传统安全工作流程施压
核心竞争并非 Anthropic 与某一家供应商之间的竞争，而是 AI 规模的发现能力与人类规模的验证和修复能力之间的竞争。
传统扫描器通常专注于明确类别。依赖项工具将软件包版本与已知漏洞数据库进行比对；静态分析检查源代码模式；模糊测试器则生成异常输入，并观察崩溃或错误行为。
语言模型代理的工作方式可能不同。它们可以跨文件移动、就程序行为形成假设、检查调用路径并修正调查方向。它们还可以在同一工作流程中描述漏洞利用方式并起草补丁。
这种灵活性可以暴露没有已知特征的漏洞，但也可能生成看似有说服力却错误的解释。详细报告并不自动等同于有效报告，尤其是当项目特定假设决定某种行为是否可被利用时。
Google 的 OSS-Fuzz 提供了最清晰的历史参照。它持续对重要开源项目进行模糊测试，并将可复现的故障整合到既有披露流程中。Anthropic 表示，该计划帮助启发了其资格模型。
OSS Scanner 并不取代模糊测试。它增加了基于推理的一层，可检查逻辑、权限、状态转换以及组件间的交互。这些领域可能难以被围绕已知模式或随机生成输入构建的扫描器覆盖。
竞争格局也在扩大。Cisco 发布了 Antares 模型，旨在调查代码仓库并定位存在漏洞的代码。Capital One 发布了 VulnHunter，其他安全公司则在测试和修复产品中嵌入智能体。
Cisco 的方法强调规模更小、专业化程度更高的模型，组织可以让它们更贴近自身代码运行。Antares 模型策略回应了另一项担忧：一些团队不愿将敏感代码仓库发送给外部模型提供商。
Anthropic 则运营扫描服务，并为获接纳的开源项目承担计算成本。这种模式让维护者无需部署先进的模型技术栈，也能使用资源密集型技术。
相应的代价是依赖 Anthropic 的基础设施、政策和可用容量。维护者还会收到 Anthropic 系统所生成的输出格式。他们无法控制底层模型，也无法控制每一套扫描框架。
对于商业客户，Anthropic 将 Claude Security 作为独立产品提供。该服务将漏洞检测和补丁生成整合到企业开发工作流中。OSS Scanner 的定位是为开源项目提供基础设施支持，而不是免费的企业级替代方案。
这种区别对安全厂商形成了战略压力。如果前沿模型提供商为基础性项目资助安全审计，部分高价值漏洞研究就会向上游转移。商业工具随后必须通过工作流集成、私有化部署、治理和响应管理来竞争。
开源维护者面临的是另一种压力。获得充分支持的项目可以将这些报告视为新的研究线索来源。而由志愿者运营的项目即使每项发现都在技术上有用，也可能难以应对。
验证只是第一步。维护者还必须评估受影响版本、编写测试、选择安全的修复方案、协调发布，并通知下游用户。修复一个路径的补丁，可能会引入另一处缺陷或破坏兼容性。
当一个模型在多个分支中发现相关弱点时，负担会进一步增加。每份报告都可能为软件包分发方、云服务商、应用团队和事件响应人员带来工作。检测速度可能会放大整个供应链中的协调成本。
因此，扫描器提出的补丁很重要，但并不能解决全部问题。候选补丁缩短了进入测试的路径，却不能让维护者放弃对架构、向后兼容性和发布安全的责任。
团队还需要建立持久记录，将报告与修复及部署决策关联起来。可搜索的工程知识库可以跨越多个版本保留威胁模型、复现证据和补丁审查记录。
最好的结果并不是尽可能多的报告数量，而是可被衡量的、可利用暴露面的下降。这要求追踪哪些发现有效、修复发布速度如何，以及用户是否安装了已修复的版本。
Anthropic 要求维护者在为修复署名时附上报告标识符。这些标识符可以帮助衡量被采纳的发现和补丁。但它们无法揭示下游系统是否在攻击者发现同一漏洞之前完成更新。
因此，扫描器会对发现后的每一个阶段施加压力。拥有成熟安全流程的项目会获得一个新的高吞吐量输入来源。缺乏此类流程的项目则会面对仅靠更好的检测无法解决的积压问题。
更快的发现带来验证权衡
取消人工审查能让报告更快送达，但也会将不确定性直接转移到维护者的安全队列中。
Anthropic 对这一局限性表现得格外坦率。该公司表示，由于报告由模型生成且未经人工分诊，它们可能不正确或无效。公司还承认，严重性评级可能被夸大。
严重性取决于具体环境。暴露于匿名互联网流量的代码中出现内存错误，与同样的错误位于认证机制之后，情况截然不同。权限问题可能在一种部署中很严重，在另一种部署中却根本无法触及。
当文档不完整时，模型可能会误解这些边界。Anthropic 正是出于这个原因鼓励项目提交威胁模型文件。但模型仍是在解读这些指导，而不是执行经过形式化验证的策略。
重复发现也会带来成本。在 Anthropic 的 97 项发现验证样本中，有 11 项是已经知晓的问题，或与其他发现重复。重复报告可能包含有用证据，但维护者仍必须识别并协调处理它。
报告量也可能成为对项目注意力的拒绝服务问题。开源社区已经抱怨低质量、由 AI 生成的漏洞报告。即使报告准确，也要与功能开发、发布、支持工作和现有安全义务争夺资源。
OSS Scanner 通过自愿加入和维护者验证来限制这一风险。它也面向已经能够处理经验证严重发现的项目。这些控制措施减少了非主动提交，但不会增加项目可用的工程时间。
该服务的隔离模型解决了另一类担忧。扫描智能体在构建阶段后不具备互联网访问权限。报告存储在受限制的云环境中，只有需要访问的 Anthropic 安全人员可以查看。
不过，设置阶段仍需要网络访问来获取依赖项和构建项目。项目维护者必须提供安全、可复现的 Dockerfile。构建脚本可能在不同环境中表现不同，或依赖不可用的外部服务。
Anthropic 的公开注册仓库包含本地验证和构建检查工具。其文档警告称，在未采用更强虚拟机隔离的情况下进行测试时，项目 Dockerfile 可能访问本地服务。
这一警告很重要，因为维护者可能会专注于扫描器输出，而忽视注册机制。安全的安全服务必须同时保护被分析的项目，以及用于准备其配置的工作站。
披露带来了更微妙的风险。Anthropic 不会对未经验证的报告设定公开期限。这避免了以 Anthropic 自身尚未审核的主张向维护者施压。
没有期限也意味着修复进展可能持续不可见。公众难以轻易得知有多少报告被接受、修复、拒绝或仍未解决。Anthropic 所要求的署名标识符只能提供部分可见性。
防御者与攻击者之间还存在不对称性。符合条件的项目可获得 Anthropic 最强模型的私密、周期性分析。攻击者仍可使用其他模型、本地工具或自行研究来检查同一份公开源代码。
只有当维护者能够迅速行动时，扫描器才能缩小这一差距。一份正确的报告躺在负担过重的收件箱中，几乎不具备防御优势。补丁必须在利用开始前完成测试、发布和部署。
Anthropic 自身关于 Glasswing 的报告称，高严重性或关键发现平均需要两周完成修复。这一由公司报告的数据凸显了为什么原始发现速度不能成为唯一的成功指标。
更有意义的评估应包括按严重性划分的准确率、中位分诊时间、补丁采纳情况、回归率和下游部署情况。它还应区分新漏洞、重复问题和此前已知的问题。
项目多样性也应纳入结果考量。在成熟的 C 和 C++ 基础设施上的表现，未必能预测其在分布式服务、加密库、数据库扩展或权限逻辑复杂的 Web 应用中的表现。
该服务也可能改变维护者的行为。团队可能会因为扫描器会使用威胁模型而更清晰地记录它们。更好的文档既能帮助人工审查者，也能帮助 AI 智能体。
相反的结果仍然可能出现。团队可能因报告看起来完整而过快接受看似合理的补丁。复现步骤和充满信心的解释应当支持审查，而非取代审查。
维护者应将每份报告视为经过充分发展的研究线索。他们仍需要独立复现、代码审查、回归测试和暴露面评估。高严重性标签值得紧急处理，而不应获得自动信任。
Anthropic 的早期证据支持谨慎乐观。该服务已经产出了被采纳的发现、可用的补丁和数条严重的利用链。随着注册范围扩展到初始合作伙伴之外，其更广泛的可靠性仍将取决于实际表现。
三个信号将揭示该模式是否奏效
下一项考验是，OSS Scanner 能否将加速发现转化为经验证的修复，同时不压垮它原本打算保护的项目。
第一个信号是注册队列的构成。Anthropic 并未承诺提供普遍访问权限，而且可以随着需求变化调整资格条件。获接纳项目的数量和类型，将揭示该服务的实际覆盖范围。
如果基础性库大量加入，将增强 Anthropic 关于该计划改善共享基础设施的说法。若队列主要由资金充足的项目构成，仍会创造价值，但较小的依赖项仍将面临暴露风险。
容量与需求同样重要。Anthropic 承诺提供周期性扫描，但频率可能会随项目规模和其他因素而变化。对于快速变化的代码仓库，较长的间隔会削弱扫描器的价值。
第二个信号是大规模下由维护者验证的准确率。Anthropic 的 97 项发现样本提供了一个有用起点，早期评价也描述了可执行报告占比较高的情况。但仍需要更大规模的公开测量。
报告标识符可以支持这一评估。Anthropic 可以追踪哪些发现获得提交记录中的署名、成为安全公告，或促成补丁。维护者也可以报告被夸大的严重性、重复项和误解。
不断上升的补丁采纳率将强化快速通道模式。即使扫描器持续发现真实缺陷，若重复报告长期居高不下，或宣称与实际分配的严重性存在重大差异，该模式也会被削弱。
必须按项目类型和严重性报告准确率。混合平均值可能掩盖复杂架构中的薄弱表现。它也可能通过将大量低影响发现与少量严重错误一并计算，让扫描器显得准确。
第三个信号是修复吞吐量。Anthropic 创建 OSS Scanner，是因为人工审查无法跟上检测速度。同样的不匹配也可能在每个加入项目的内部重现。
有用的衡量指标包括复现时间、修复时间和发布时间。下游采用同样重要，因为已修复的代码仓库无法保护仍在使用易受攻击版本的用户。
项目可能会通过增加安全人员、自动化测试或改进发布流程来应对。Anthropic 也可以围绕报告去重和补丁验证扩大支持范围。这些变化将应对模型发现漏洞之后才开始的工作。
竞争性回应将使比较更加鲜明。Cisco 的小型安全模型倾向于本地控制，而企业平台强调集成和治理。Google 的模糊测试基础设施则继续提供一种成熟、以可复现性为重点的模式。
没有单一方法能够覆盖所有漏洞类别。最可能的结果是分层安全：依赖项扫描用于已知漏洞，模糊测试用于运行时故障，智能体用于需要深入推理的缺陷，而人类负责最终判断。
OSS Scanner 最重要的理念并非让 AI 取代安全研究人员，而是让稀缺的审查人员不再成为有能力的维护者看到潜在紧急证据前的必经关卡。
它最大的风险也源于同一理念。当这一关卡消失后，每个接收报告的项目都要承担更多责任，判断哪些发现是真实的、哪些重要，以及哪些能够被安全修复。
开发者应关注该服务已验证的成果，而非原始发现数量。企业采购方应询问其关键依赖项是否已加入，以及补丁能否抵达实际部署的系统。维护者则应在请求另一批报告前，评估自身的分诊处理能力。
如果 Anthropic OSS Scanner 能缩短从发现问题到部署修复之间的路径，它就会成功。若它只会扩大安全积压，瓶颈只是转移了位置，而非真正消失。哪一种结果先出现，将塑造软件行业如何利用 AI 开展漏洞研究。
