Anthropic OSS Scanner 容易被概括成一项免费服务：用最强模型定期扫描开源项目，再把漏洞报告发给维护者。这个概括遗漏了最值得研究的部分。
它交付的是未经人工复核的模型输出。项目必须主动加入，维护者决定哪些报告值得复现、哪些符合自身威胁模型、哪些只是重复项，以及哪些修复真正关闭了风险。OSS Scanner 的核心产品形态因此不是漏洞答案，而是一条维护者可控的验证队列。
当模型能批量发现疑似漏洞之后，安全系统的瓶颈已经从发现转移到验证。
2.9 万个候选不是 2.9 万个漏洞
Anthropic 在 2026 年 10 月 8 日的公告中给出三组数字：过去六个月产生了超过 2.9 万个候选漏洞，人工只完成约 6000 个分诊；另有维护者主动要求接收近 5000 个未经验证的原始报告。
这里存在两套吞吐完全不同的系统。模型按机器速度生成候选，人按维护者速度把候选变成结论。
候选可能无效，也可能确有代码缺陷却不满足项目的安全边界。它还可能与已知问题重复，严重性偏高，或者只在不现实的攻击前提下成立。把候选数直接写成发现漏洞数，会把生成、验证和关闭三个状态混为一谈。
Anthropic 还披露了一次定向验证：渗透测试专家检查了 48 个项目中的 97 个高危和严重候选，其中 85 个达到其协调漏洞披露流程的门槛，11 个属于真实但重复的问题，1 个无效。85/97 对应正文所写的 88%。
这组结果说明经过严重性筛选的原始输出具有较高信号，但它不能代表全量 2.9 万个候选的准确率。样本只包含高危和严重项，复核由 Anthropic 委托的专家完成，结果中还包含 11 个重复项。准确、唯一和具有新增修复价值是三个不同维度。
更稳妥的结论是：原始报告已经值得为愿意承担验证工作的维护者建立快速通道，但仍然只是原始报告。
Opt-in 是第一道控制
OSS Scanner 没有扫描所有公开仓库后向 Issue 区批量投递。核心维护者需要向官方仓库提交 PR，提供 project.yaml 和 Dockerfile，也可以提供 threat_model.md。Anthropic 再按类似 OSS-Fuzz 的条件逐项判断是否接收项目。
官方仓库给出的边界很清楚：
- 项目主动决定是否接收报告。
- Dockerfile 固定代码如何取得、构建和测试。
- 初始化构建阶段可以联网，正式安全扫描在隔离虚拟机中断网运行。
- 报告只发送给配置中的联系人，不会自动公开。
- 报告完全由模型生成，没有经过人工审查。
- 项目可以随时暂停报告或退出。
这套机制首先是一份授权合同。项目控制扫描对象、构建环境、接收者和停止条件。对于会消耗维护者时间、接触未公开漏洞并附带候选补丁的服务，这些控制与模型能力同样重要。
Anthropic 还把两条披露路径分开。人工验证过的报告继续走既有协调漏洞披露流程。OSS Scanner 的原始报告不会自动进入 90 天披露周期，也不会由服务公开。快速通道提高了交付速度，同时保留了报告的未验证身份。
报告应是一份证据包
Anthropic 表示，每份报告都会包含自包含复现器、漏洞解释、条件允许时的引入版本二分结果，以及可用时的候选补丁。
其中最重要的是复现器。技术说明写得流畅，无法证明输入真的抵达危险路径；严重性标签无法证明攻击者获得了新的能力；候选补丁也无法证明根因已经消失。复现器至少给了维护者一个可以证伪的起点。
threat_model.md 则负责校准安全语义。官方建议项目说明未信任输入从哪里进入、哪些组件属于范围内、不同严重性如何判断，以及希望以什么格式接收报告和补丁。缺少这些信息时，模型只能套用通用安全分类，维护者需要自行补上项目上下文。
Anthropic 在公告中承认，早期接收者有时认为严重性被夸大，或者扫描器误解了项目的威胁模型。这个问题说明，代码缺陷真实存在与安全结论成立仍需分别判断。
一份适合进入维护者队列的最小证据包，至少应绑定以下信息：
- 仓库、分支、Commit、构建配置和平台；
- 稳定的 finding ID 与扫描运行 ID；
- 精确复现步骤、实际输出和预期安全属性；
- 受影响代码路径与攻击者前提；
- 已知问题和重复报告的关联；
- 与项目威胁模型对应的严重性理由；
- 候选补丁、回归测试和剩余风险；
- 生成报告时使用的模型、工具和策略版本。
官方仓库已经公开其中一部分输入合同，但没有说明完整 finding schema、跨轮扫描如何去重、模型与 Prompt 如何版本化、补丁状态如何回写，以及修复后是否自动复验。把这些问题在接入前问清楚，比拿到报告后再搭临时流程成本更低。
给发现建立状态机
邮件只负责送达，无法承担漏洞管理。报告量上升后，维护者需要显式状态，防止证据在不知不觉中升级。
已生成
-> 已复现
-> 符合威胁模型
-> 已完成去重
-> 严重性已校准
-> 修复已接受
-> 修复已验证
-> 已发布或关闭
每次状态变化都应保存理由和工件。复现失败要保留环境与输出；判断为范围外要引用威胁模型条款；重复项要指向唯一主记录；严重性变化要同时保留模型建议和维护者理由；关闭则需要回归测试或另一条独立证据。
这也能正确处理前述 97 个高危样本。11 个重复项可以证明模型发现了真实缺陷，但不会增加 11 个独立修复任务。对能力评测而言它们是正样本，对维护者队列而言它们是重复工作。
候选补丁同样需要独立门禁。补丁能编译，只能证明变更具备基本可执行性。它可能只针对当前 PoC，可能改变兼容性，也可能把风险转移到另一条路径。原始复现器、回归测试、根因审查和项目正常代码评审仍应决定补丁能否合并。
衡量队列关闭，而不是扫描产量
发现数只说明有多少工作进入系统。更有价值的指标应回答队列是否持续产生安全收益：
| 指标 | 它回答的问题 |
|---|---|
| 复现通过率 | 原始报告有多少能在冻结环境中重放 |
| 重复率 | 维护者时间有多少消耗在已知问题上 |
| 威胁模型驳回率 | 代码观察真实但安全结论不成立的比例 |
| 严重性调整率 | 模型排序与项目判断有多大偏差 |
| 各状态 P50/P95 停留时间 | 当前瓶颈在复现、判断、修复还是发布 |
| 补丁接受率与返工率 | 候选补丁减少了多少真实工作 |
| 每维护者小时的已验证关闭量 | 服务是否形成防御杠杆 |
这与此前文章讨论的两个问题相邻，但边界不同。Chrome 的 AI 漏洞流水线关注一个漏洞从发现、修复、发布到用户安装的完整风险关闭过程；AI 垃圾 CVE 的复现门关注公开漏洞记录何时可以触发自动修复。
OSS Scanner 面对的是更早的一步：报告还没有 CVE，也没有人工结论时，外部模型生成的 Claim 怎样进入项目自身的责任系统。
维护者接入前的六个问题
第一，谁负责队列？需要明确主要安全联系人、备份人员和响应规则，同时保留并非每条报告都紧急的事实。
第二，项目的威胁模型是什么？攻击者能力、保护资产、范围外组件和严重性规则应成为扫描输入。它是校准依据，不是补充文档。
第三，构建能否安全复现？项目应检查 Dockerfile、依赖、测试和初始化阶段的网络访问，并尽量固定分支或 Commit。
第四，报告保存在哪里？把邮件转入私有跟踪系统，为报告分配稳定 ID，记录处置状态和重复关系，同时原样保存初始证据。
第五，哪些动作禁止自动化？原始报告可以自动创建分诊任务，但不应直接公开公告、合并补丁或触发生产升级。
第六，如何证明已经关闭？至少应让原始复现器安全失败，增加回归测试，确认根因被修复，并记录包含修复的发布版本。
如果项目没有能力维护这条队列，人工复核后的协调披露路径可能更合适。主动加入的依据应是验证能力，而不是想看看模型能发现多少问题。
FAQ
Anthropic OSS Scanner 是开源模型吗？
这里的 OSS 指开源软件。加入项目所用的仓库和工具公开可见，扫描服务使用 Anthropic 托管的前沿模型，包括 Claude Mythos。该计划没有开放这些模型的权重。
OSS Scanner 发来的报告已经验证过吗？
没有。Anthropic 明确说明，报告完全由模型生成，未经人工审查或分诊。报告中的复现器和其他材料用于帮助维护者完成验证。
原始报告会被自动公开吗？
官方仓库说明，原始报告会私下发送，不进入 90 天披露周期，也不会由该服务公开。人工验证后的报告可以进入另一条协调漏洞披露流程。
开源项目如何加入？
核心维护者需要向 anthropics/oss-scanner 官方仓库提交 PR，提供项目配置和 Dockerfile。Anthropic 会逐项判断项目是否符合资格。
对维护者最大的风险是什么？
最大的运营风险是形成无边界的验证积压。复现器、威胁模型、去重、显式处置状态和关闭指标决定了更多报告是在提升安全性，还是只在占用维护者时间。