Anthropic 免费为关键开源项目扫描漏洞

Anthropic 把开源安全扫描做成了一项免费服务：项目主动报名，模型定期审计代码，报告直接交给维护者。原文的核心判断是，模型已经能找到不少真实漏洞，人工复核的速度反而成了瓶颈，因此 OSS Scanner 选择让维护者直接接收未经人工审核的结果。

这能扩大扫描规模，也把去重、定级和确认影响的工作交给了项目团队。对程序员来说，值得看的不只是漏洞数量，还有这套流程如何运行，以及「模型发现问题」距离「确认安全风险」还有多远。

免费扫描解决了成本，谁来消化报告？

OSS Scanner 面向关键开源项目，由 Anthropic 的 Frontier Red Team 和 Safeguards Research 团队共同运行，使用包括 Claude Mythos 在内的最强模型定期审计代码。它借鉴了 Google OSS-Fuzz 的项目接入方式，但把模糊测试器换成了语言模型。

推动这个方案的是报告积压。原文称，过去 6 个月，Anthropic 的模型发现了超过 29,000 个候选漏洞，人工审核约 6,000 个；另有近 5,000 份报告，应维护者要求直接发送，无论是否验证。OSS Scanner 将这种按需发送变成了正式的自愿加入机制。

按原文时间线，服务于 10 月 8 日推出。截至 10 月 19 日，约 650 份申请中有 114 个项目获准加入。前 11 天产出了 77 个模型评级为 critical、803 个评级为 high 的发现。

这些数字首先代表模型给出的发现数量，不能直接当作已确认漏洞数量。

免费也不代表维护成本归零。Anthropic 承担基础设施和扫描费用，维护者仍要判断报告是否重复、是否能触达真实攻击面，以及模型给出的严重程度是否合理。原文已经提到，有维护者认为严重性被高估。

报名只要一个 PR，但威胁模型不能随便省

核心维护者通过向 anthropics/oss-scanner 提交 PR 报名，按模板新增 projects/<project>/project.yaml。

必填项是 repo、primary_contact 和 Dockerfile 路径；可选项包括 threat_model、用于加密报告的 pgp，以及 auto_ccs、homepage、disabled。

运行分成两个阶段：先联网构建 Dockerfile，再把 VM 切到没有 Internet 的网络中审计。扫描运行在 Anthropic 的基础设施上。流水线中的 Agent 会复查问题、分析根因，并尝试提出补丁。

报告包含可独立运行的复现材料和漏洞解释；条件允许时，还会定位引入问题的提交，并附上候选补丁。这比只给一段「这里可能不安全」的描述更有用，维护者可以沿着复现过程检查结论。

但有一个配置尤其影响报告质量：可选的 threat_model.md。它用于说明攻击者能控制哪些输入、哪些代码不在审计范围内，以及严重程度如何划分。没有它，扫描器就需要自行推测。

例如，一个问题是否允许攻击者通过外部输入触发，会直接影响风险判断。模型可以发现异常路径，却未必了解项目实际的部署边界。把这些前提写清楚，才能减少双方围绕「这到底算不算漏洞」反复解释的成本。

88% 的结果够好吗？先看它测了什么

Anthropic 请渗透测试人员复核了来自 48 个项目的 97 个 critical 和 high 级别发现。其中 85 个，即 88%，达到了其协调漏洞披露流程（CVD）的门槛；11 个是真实问题，但重复了已知问题或其他扫描结果；只有 1 个属于误报。

这个结果说明样本中的报告有较高真实性，但不能把它理解成「所有扫描结果都有 88% 的准确率」。样本仅覆盖 critical 和 high，原文也没有说明抽样方式、维护者处理一份报告需要多久。

维护者反馈提供了另一组证据：wolfSSL 收到 74 份报告，其中 72 份有效，5 个问题成为 CVE。curl 则修复了 CVE-2026-92392，一个 High 级别的 HTTP/2 上传 use-after-free，也就是内存释放后仍被使用。受影响版本为 curl 8.12.0 至 8.22.0，修复版本为 2026 年 10 月 14 日发布的 8.23.0。

原文还列出两组能力与规模数据：CyberGym 上，LLM 发现漏洞的比例从不足 20% 上升到超过 85%；截至 10 月 2 日，Anthropic 更广泛的 CVD 看板记录了 591 个项目中的 6,157 个已披露漏洞，其中 516 个已修复。

这些数据的统计范围不同。基准测试、整体披露记录和 OSS Scanner 上线后的发现，不能拼成同一项服务的成绩单；已披露与已修复之间的差距，也无法仅凭原文归因。

我的判断

我认为，这套方案最有价值的部分是把复现材料、根因和候选补丁一起交付，让维护者有条件独立判断。真正需要打问号的，是扩大报告供应后，项目是否有能力处理。

原文把它与几种方案并列：OSS-Fuzz 使用 libFuzzer、AFL++、Honggfuzz 和 sanitizers；OpenAI Codex for OSS 由获准维护者运行和审核扫描；Google DeepMind CodeMender 使用 Gemini Deep Think，并在补丁提交上游前进行人工审核。

这些方案的人工介入位置不同，公开指标也不同。OSS-Fuzz 截至 2025 年 5 月的记录是 13,000+ 个漏洞、50,000 个 bug、1,000 个项目；Codex for OSS 列出 14 个 CVE，Codex Security 测试期误报减少 50%+；CodeMender 截至 2025 年 10 月有 72 项安全修复进入上游。它们无法组成公平的效果排名，原文没有提供统一条件下的对照数据。

OSS Scanner 更适合作为新增的漏洞发现渠道，其收益取决于项目消化报告的能力。

另一个实际差异是披露压力：OSS Scanner 对未验证发现没有披露期限；OSS-Fuzz 的规则是 90 天或修复发布，并有 14 天宽限。这里的「没有期限」仅针对未验证发现，不能扩大理解为所有结果都没有披露约束。

能拿来做什么

• 如果你维护符合条件的关键开源项目，可以先准备可重复构建的 Dockerfile，再评估报名，并提前指定负责接收、去重和验证报告的人。
• 在让 AI 审查代码前，先写清攻击者能控制的输入、排除范围和严重程度规则；这些信息可以整理为 threat_model.md，减少模型猜测业务边界。
• 收到报告后，先运行复现材料、排查重复问题，再结合实际使用方式判断等级；候选补丁也应经过项目原有的代码审查。
• 评估扫描收益时，同时记录有效发现和处理耗时。原文没有给出维护成本数据，你的项目需要自己补上这部分证据。