Anthropic OSS Scanner 使用指南
为能处理漏洞报告的开源维护者提供免费安全扫描。
Anthropic OSS Scanner 是一项面向符合条件的开源项目、需主动申请的免费漏洞扫描服务。 Anthropic 在 2026 年 10 月 8 日发布该服务，定期用旗下最强模型检查已接入的代码仓库，并通过邮件向维护者发送发现。使用前需要明确：这些报告发送前未经 Anthropic 人工审核，验证和确定处理优先级的工作由项目方承担。
如果你维护重要的库或应用，并有余力调查安全报告，可以从官方 FAQ了解申请要求。报名通过向 Anthropic 的仓库提交 PR 完成；下载工具或购买 API Key 都不等于项目已接入。
资料核验日期：2026 年 10 月 9 日。 本文基于 Anthropic 公告、FAQ 和报名代码撰写，未实际报名或运行扫描。效果数据来自厂商披露；文中引用的一手资料为英文。
哪些项目可以申请？
Anthropic 参照 OSS-Fuzz 的标准，逐项评估对基础设施和用户安全有重要影响的成熟项目。是否暴露于远程攻击、是否处理不可信输入，以及用户和依赖项目的规模，都会影响判断。官方 FAQ 没有公布达到某个 Star 数便自动获批的规则。
申请人必须是核心维护者，Anthropic 会核实其身份。申请时应简要说明项目的重要性，并指定能处理安全邮件的联系人。FAQ 明确将服务面向已经能够跟进经过验证的高危、严重漏洞报告的团队。扫描免费，分诊、修复和发布仍然需要维护者投入时间。
与 Claude Security、Claude Code 有何区别？
这些工具涉及相近的工作，但使用入口和交付方式不同。OSS Scanner FAQ与 Claude Code Security Reviewer 仓库给出的区别如下：
| 工具或流程 | 主要用途 | 接入与结果 |
|---|---|---|
| OSS Scanner | 定期审计获批的开源项目 | 主动申请的免费服务；邮件发送模型生成的报告 |
| Claude Security | 商业源代码安全扫描与修复 | 独立的企业产品与接入流程 |
| Claude Code Security Reviewer | 在开发过程中审查代码变更 | 独立的 GitHub Action 与 /security-review 工作流 |
| Anthropic 常规 CVD 流程 | 协调披露已验证的漏洞 | 人工审核后的报告，适用相应披露政策 |
发布研究说明扫描使用 Anthropic 最强的模型，包括 Claude Mythos。这描述的是服务内部使用的能力，不代表维护者可以下载模型或获得通用 Mythos API 权限。公开仓库提供报名配置和准备工具，并未提供在本地复现整套托管扫描服务的文档方案。
如何接入 OSS Scanner
1. 准备构建环境和安全联系人
先阅读仓库说明及贡献指南，准备一个能够安装依赖并构建项目的 Dockerfile。构建阶段可以联网，随后进行的安全审计不能联网。 测试所需的资源应在准备阶段下载完毕，并确认测试在准备好的环境中能够离线运行。
报名文件中的联系邮箱是公开的，建议使用可公开的安全联系别名。如果通过 pgp 公钥要求加密报告，邮件只发送给 primary_contact，不能同时配置 auto_ccs。
2. 添加报名配置
在你 fork 的 Anthropic 仓库中，根据官方模板创建 projects/my-project/project.yaml。以下最小示例假设构建文件和威胁模型文件保存在你自己的项目仓库中。请替换示例仓库与邮箱，并创建对应文件：
repo: https://github.com/example/project#main
primary_contact: security@example.org
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md
字段名应使用模板和校验器中的小写 dockerfile。另一种方式是在报名配置旁放置名为 Dockerfile 的文件，并省略 dockerfile 字段。两种位置只能选一种。被扫描的 Git 仓库不必托管在 GitHub。
可选的 threat_model 文件很有价值。可以写明不可信输入、安全边界、范围外行为、严重程度判定规则，以及什么样的复现材料和补丁有用。这些说明有助于模型理解预期行为，但不能保证每条发现都正确遵循项目的威胁模型。
3. 校验配置并检查离线环境
在报名仓库本地副本的根目录中，官方提供的准备命令为：
python3 tools/validate.py
tools/check my-project
第一条命令校验报名配置；第二条构建项目并打开禁用网络的 shell，供你运行项目测试。上游说明要求安装 Git、Docker，以及带 PyYAML 的 Python 3。只构建可信的项目定义，因为构建阶段可以联网。本文核对了命令与官方文档，未通过执行这些命令进行扫描实测。
4. 提交报名 PR
每个 PR 对应一个项目，完成检查清单，并按仓库流程处理服务条款和贡献者协议。Anthropic 会在接纳前核实申请人的维护者身份。如果获批项目无法在其基础设施上构建，团队会通过主联系邮箱通知你。
首次扫描后，后续扫描会寻找新引入的问题以及此前遗漏的漏洞。官方没有承诺固定的每日或每周扫描周期；FAQ 说明频率取决于待处理项目数量、项目使用情况等因素。
报告包含什么，效果数据该怎么看？
Anthropic 会通过邮件发送一组报告，包含复现材料和漏洞解释，并在可提供时附上候选补丁。报告还可能通过二分定位引入问题的版本。流程中有负责复核的智能体，但智能体复核不等于人工确认。严重程度可能偏高，报告可能重复已知问题，模型也可能误解项目的威胁模型。
发布时的验证样本包含 48 个项目的 97 条高危或严重级别发现：85 条达到 Anthropic 的 CVD 标准，11 条是确实存在但重复的问题，1 条无效。这是经过选择的早期样本，不是覆盖全部严重程度的独立准确率测试，也没有衡量扫描漏掉了多少漏洞。
Cyber Mission 公告中的 “真阳性率超过 90%”属于预期，而非服务保证。项目自己评估时，应分别记录确认有效、重复、严重程度误判和无效报告，避免混用这些指标。
维护者收到报告后的处理流程
以下是本文建议的处理方法，不是 Anthropic 对服务效果的承诺：
- 接收并登记。 在受限的安全邮箱中分配负责人，记录报告编号、受影响版本和初始状态。
- 复现并去重。 在隔离的测试环境中核对复现材料，再与已有公告或私下收到的报告比较。重复报告可以描述真实漏洞，但不一定需要第二次修复。
- 评估影响。 确认输入是否由攻击者控制、受支持的配置能否触达问题路径，以及利用需要哪些权限，再应用项目自己的严重程度标准。
- 审查补丁并发布。 检查建议改动，添加回归测试并验证兼容性。在公开敏感细节前，按项目的安全流程协调修复和公告。
例如，报告将某问题标为“严重”，但触达它需要管理员权限，应记录这个前提并重新判断影响，而不是仅因评级不准便丢弃报告。对于反复出现的误解，可以补充威胁模型文件并向 Anthropic 回复反馈。
披露规则、暂停和常见问题
每份报告都会触发 90 天披露倒计时吗？
不会。FAQ说明，未经验证的发现不会自动附带 90 天期限。如果 Anthropic 后续通过人工验证了某项发现，则可能按照 CVD 政策披露，相关期限从通知维护者“已经人工验证”时开始计算。这不代表漏洞永远不会公开。
可以暂停或退出吗？
可以。通过 PR 将配置设为 disabled: true 可暂停报告；删除项目的报名目录则可退出。退出后仍可能收到常规人工审核的 CVD 报告。FAQ 还说明，未来若改变披露政策，会事先通知并提供退出选项。
是否免费，能否替代其他安全检查？
Anthropic 承担获批项目的 OSS Scanner 扫描成本。本文建议继续保留依赖检查、测试和人工安全审查，因为已公布的证据不能证明扫描覆盖了全部漏洞。真正需要判断的是：团队能否把新增报告转化为经过审查的修复，而不让安全流程超出承受能力。
OmniaKey 在这个流程中的位置
对于单独的开发和修复工作，可以参考我们的 Claude Code 配置指南，并在模型目录中查看当前网关选项。OSS Scanner 仍需向 Anthropic 申请；OmniaKey 账号不提供该服务或其内部模型的访问权限。