先看证据
扫描更快，瓶颈换了位置
Anthropic于2026年10月8日推出OSS Scanner。这是一项面向关键开源项目的免费、自愿报名漏洞扫描服务，由Anthropic的模型定期检查获准代码库，报告直接发给维护者，不经过漏洞报告的人工审核。项目需要由核心维护者申请，服务并非面向所有新仓库开放。
这项安排回应的是发现速度与人工处理能力之间的落差。Anthropic称，在此前六个月里，模型发现了超过2.9万条候选漏洞，但人工只审查、分流了约6000条；另有近5000份未经验证的报告，曾按部分维护者的要求直接发送。OSS Scanner把这种快速通道扩展成一项有报名机制的服务，改变的不只是扫描规模，也是谁来承担第一轮判断。
隔离扫描不等于隔离整个构建链
报名项目要向Anthropic的GitHub仓库提交配置，并提供Dockerfile来准备依赖和构建环境。构建阶段可以联网；构建完成后，扫描代理才在没有互联网访问的隔离虚拟机中检查代码。这个先构建、再断网扫描的边界，能限制扫描期间的外部连接，但不能被理解成整个供应链都与网络隔绝。
扫描流程不只是让模型给出一条告警。Anthropic称，代理会复核发现、分析根因，并在可能时提出补丁；报告通常附带漏洞解释和可独立运行的复现材料，有时还会指出引入问题的提交。维护者也可以提供威胁模型，说明攻击面、排除项和严重性标准；若没有这份信息，扫描器只能自行推断项目的安全边界。
88%是披露门槛，不是总体准确率
Anthropic请渗透测试人员审查早期版本在48个项目中产生的97条高危或严重报告：85条达到Anthropic协调漏洞披露流程的标准，11条是真实问题但与已知问题或其他扫描发现重复，1条无效。这个结果说明样本里有相当多值得处理的发现，却不能直接读成“总体准确率88%”：样本限定在高危和严重报告，评判标准是能否达到披露门槛，测试也由Anthropic组织。
维护者反馈提供了另一个、但同样有限的观察点。wolfSSL维护者称收到74条报告，其中72条有效，5条后来成为CVE；这是单个项目的经验，不是跨项目独立测评。上线11天后的10月19日，Anthropic报告有114个项目获准，申请约650份，并称模型评级发现包括77条严重和803条高危；当时并非所有获准项目都已完成扫描，评级也来自模型本身。
curl案例说明报告能落地，也说明不了全部
curl维护者修复的CVE-2026-92392，是这项服务能产生实际结果的例子。该漏洞涉及HTTP/2上传过程中的释放后使用问题，影响curl 8.12.0至8.22.0，修复版本8.23.0于2026年10月14日发布。报告能导向可复现的问题和补丁，说明模型扫描可以进入真实维护流程，而不只是生成看起来可信的安全描述。
但一个成功修复案例不能替代对整条流程的评估。报告到达维护者，不等于维护者已经确认其影响范围，也不等于项目能立即发布修复。重复发现、严重性高估和对项目威胁模型的误读，都会占用本就有限的安全响应时间。Anthropic明确将服务定位给有能力处理更多报告的项目，这实际上把维护带宽列为采用前提。
把它当发现信号，而不是漏洞结论
OSS Scanner与OSS-Fuzz的相似之处在于，它们都把持续检查开源项目组织成服务；区别在于，Anthropic以语言模型代理替代模糊测试器，报告又未经人工验证就交付。这不是对现有协调披露流程的替换。未验证报告没有统一的90天披露倒计时，也不会由Anthropic直接公开；若之后进入人工验证的协调披露流程，期限才按该流程计算。项目也可以暂停或退出。
对技术负责人而言，采用前要先问的不是模型能否“发现漏洞”，而是团队能否接住发现：谁负责复现，怎样识别重复项，怎样复核模型给出的严重性，报告如何进入修复排期。报名资格还会经过人工核验，Dockerfile范围也会被检查，但这些控制并不等于每条漏洞报告都经过专家把关。免费降低了扫描服务的直接成本，没有免除维护者的分流成本；若没有明确的接收和响应流程，更多报告可能只是更快地堆进收件箱。