技术拆解 024｜oss-scanner：Anthropic 官方漏洞扫描仓，5 天 960 星，里面却没有一行扫描器代码

10 月 8 日，Anthropic 官方账号 anthropics 在 GitHub 开了一个新仓 oss-scanner，五天攒下超过 960 颗星（10-14 快照，建仓 5 天），Pull Request 编号已经开到 #598。它的热度不来自社区讨论，而来自三样东西：官方发布、76 个重量级开源项目主动注册、以及 PostgreSQL、OpenSSL、wolfSSL、curl、HotCRP 维护者在发布文里的证言。更有意思的是仓库本身：翻遍 184 个文件，找不到一行执行漏洞扫描的代码。这是一个扫描服务的注册表，扫描器留在 Anthropic 的服务器上。昨天的 anatomy 拆的是 agent 生态的产出层，今天这个站在安全层，两期连看正好是 AI 公司介入开源基建的两个断面。本文按老规矩拆六段。

一、它是什么

先把核心判断放在最前面：oss-scanner 仓库本体不是扫描器代码，而是「注册表 + 配置协议 + 自检工具」三件套。扫描器本体在服务侧运行，不开源。开源的部分解决的是另一件事：一个开源项目如何把自己交给这台扫描器，以及交付前如何自查。

服务本身是 Anthropic 面向关键开源项目的免费漏洞扫描，opt-in 制，项目主动注册才扫，使用受 red.anthropic.com/oss-scanner 上的服务条款约束。官方发布文说得很直白，灵感来源是 Google 的 OSS-Fuzz，把 fuzzer 换成了最强的语言模型（含 Claude Mythos）。它的前身是 Anthropic 内部用 Claude 找漏洞的 Project Glasswing，以及已经人工复核过 6000 多份报告的 CVD 流程。与企业付费产品 Claude Security 的分工也划得清楚：OSS Scanner 免费给开源项目，商业客户走另一条线。

所以这个仓库的形态值得单独说一句：AI 公司做开源安全基建，开源出来的不是模型、不是扫描器，而是一份接入协议。这和传统安全工具「代码即产品」的开源方式完全不同。注册表公开意味着谁在被扫是可查的，扫描器封闭意味着怎么扫是黑箱，透明度被切成了两半。

二、仓库结构

仓库总共 184 个文件（不含 .git），其中 80 个 yaml、51 个 md、4 个 py，Apache-2.0 许可。

主体是 projects/ 下的 76 个项目目录，每个目录就是一份注册档案。名单成色很高：openssl、cpython、spidermonkey（Firefox 的 JS 引擎）、nss（Mozilla 加密库）、homebrew、drupal、grafana、rabbitmq、jupyterlab、nestjs、valkey（Redis 分叉）、uutils-coreutils、lvm2、cryptsetup；安全工具一类有 nuclei、grype、syft、zmap、radare2、ossec-hids、go-tuf、tinyssh、botan；AI 项目也来了几个，unsloth、autogpt、goose，连 Anthropic 自家的 claude-code-templates 也注册了。注意 curl 本体不在名单里，但发布文中有 curl 维护者 Daniel Stenberg 的证言。

每份档案的核心是 project.yaml，两个必填字段：repo（git 仓库地址，可用 #branch 锁定分支）和 primary_contact（收报告的邮箱）。可选项包括 dockerfile、threat_model、auto_ccs、pgp、disabled、homepage。openssl 的样例很有代表性：repo 指向 openssl/openssl 并锁定 master，primary_contact 用的是 openssl-security@ 组邮箱而非个人地址，这正是 README 强调的「邮箱会被公开，请用 security 别名」规则的示范。

工具代码集中在 tools/，约 1287 行 Python 加 142 行 shell：validate.py 261 行做配置规则校验，check_build.py 和 check_qemu.py 负责本地构建自检。templates/ 放配置模板。仓库对贡献的态度也写在 README 末尾：只接受 projects/ 下的注册 PR，tools 和 templates 的改动一概不收。五天 598 个 PR 编号，几乎全是项目排队进场。

三、机制拆解

整个服务的流程是四步：构建、断网、扫描、发邮件。项目提供 Dockerfile（放自己仓库里或放注册目录旁，二选一，前者更受推荐因为改构建不用提 PR），扫描器在隔离 VM 里构建项目，初始构建阶段有网络，进入安全审计阶段后完全断网，扫出的结果邮件发给 primary_contact。每份报告带三样东西：自包含的 reproducer、漏洞解释（含用 bisection 定位漏洞引入的时间点）、以及一份候选补丁。

报告分两条通道。一条是 CVD 通道，经过人工复核；另一条是 fast track，报告全模型生成、不经人工复核、随扫随发。发布文披露，已有近 5000 份未经验证的 fast track 报告直发给了主动索要全量报告的维护者（Anthropic 自报口径）。双通道设计把「验证产能」当成了稀缺资源来分配：要人工复核的走排队，等得起的自己先收生货。

断网审计这一步也有讲究。构建阶段放行网络是为了拉依赖，审计阶段掐断网络则是防止模型在分析过程中外联：既避免扫描环境把项目代码或漏洞细节泄露出去，也堵住模型自行下载东西干扰分析的口子。tools/check 忠实复刻了这个环境，这也是它作为自检工具的价值所在，你在本地看到的行为和服务侧一致。

注册前的本地自检是仓库里最实用的部分。tools/validate.py 把 README 的注册规则写成代码：字段白名单、https 校验、邮箱格式、PGP 公钥格式、文件大小上限，还会拦截 workflow、budget、cadence 这类只有服务运营方才能设置的字段。tools/check <name> 按扫描器的同款方式构建项目，在断网的成品镜像里开一个 shell，测试能在这个容器里通过，扫描器就大概率能用；—qemu 变体在 x86-64 Linux 上用 QEMU 复现扫描器的 VM 布局。validate.py 的文档字符串里还有一句诚实的自白：它与服务侧扫描器不共享代码，规则改动必须两边同步。

四、数字与验证

先看 Anthropic 自报的核心数字，以下全部为自报口径。过去 6 个月用最新模型扫描全球最重要的软件项目，发现超过 29,000 个候选漏洞，其中人工复核过的只有约 6,000 个，官方自己承认瓶颈在人不在模型。学术基准 CyberGym 上，LLM 的漏洞检出率从去年初的不足 20% 涨到今年的超过 85%。

验证实验是数字里最硬的一组：Anthropic 请来熟悉 CVD 流程的渗透测试专家，复核扫描器在 48 个项目报出的 97 个 critical/high 级漏洞，结果 85 个（88%）达到 CVD 标准；剩下 12 个里，11 个真实存在但属于重复报告，真正的假阳性只有 1 个（Anthropic 自报口径）。

短板官方也没有回避：部分维护者反馈严重度评级可能虚高，扫描器可能误解项目的威胁模型。

维护者证言来自 Anthropic 发布文，转述如下。PostgreSQL 的 Noah Misch 说，发现中异常高的比例是真实缺陷，多份报告附的修复几乎可以直接用。OpenSSL Corporation 的 Anton Arapov 对比说，18 个月前的 AI 漏洞报告糟糕透顶，这一批不亚于甚至好过人类报告，附真实 exploit 的报告对工程师等于活已干完。wolfSSL 的 Todd Ouska 给出的账目是 74 份报告仅 2 份无效、5 个成为 CVE。curl 的 Daniel Stenberg 提到近年最严重的 curl 漏洞之一就是这类扫描发现的。HotCRP 的 Eddie Kohler 也在背书名单里。这些证言全部出自 Anthropic 的发布文，属于单方转述，采信时需要打这个折扣。

五、判断

三处值得盯。

第一，披露政策的双重偏离。README 原话：报告是模型生成且未经人工复核，因此不设 90 天披露期、也不公开。传统漏洞披露惯例的两根柱子，这里都拆了。工程上有它的道理：报告未经验证，套用 90 天时钟等于逼维护者在假阳性上也倒计时；不公开则避免了未验证信息流入攻击者手里。但代价是外部世界永远无法审计这套系统报了什么、漏了什么，88% 的达标率只有 Anthropic 自己算得出来。

第二，triage 成本转移给了维护者。免费是真实的，但 README 通篇在说报告未经人工复核，服务面向的是有能力消化 verified 高危报告流的项目。对 OpenSSL、PostgreSQL 这类有专职安全团队的巨头，这是净收益；对人手紧张的项目，近 5000 份未验证报告的直发通道可能是净负担。76 个注册项目清一色是重型项目，这个名单构成本身就是服务定位的证据。这不是指控，是服务边界：它筛选的是有安全响应能力的项目，而这恰恰排除了最需要外部安全帮助的那批。

第三，配置校验的双实现漂移。validate.py 与服务侧扫描器不共享代码、规则两边手工同步，这在工程上是明确的技术债信号，规模越大越容易出「本地校验通过、服务侧导入失败」的裂缝。76 个项目、598 个 PR 的节奏下，这条规则每改一次都是两处代码的人工对齐。

往大处说，这个仓库代表一种新形态：AI 公司把安全能力做成服务，开源的只是接入协议和注册表。协议开放、能力封闭，和 OSS-Fuzz 那种「基建全开源」的上一代模式相比，透明度让位于迭代速度。对维护者来说这个交换是否划算，取决于你信不信 88% 达标率这组自报数字，以及你的安全队列还剩多少余量。

六、谁能用怎么用

资格门槛不低：需要核心维护者身份的人工验证，外加 OSS-Fuzz 式的资格审查，看项目是否处理不可信输入、下游用户量是否够大。流程本身简单：开一个 PR，加一个 projects/<name>/ 目录，放 project.yaml 和 Dockerfile（或指向自己仓库里的路径），合并后扫描器自动导入。

两个实用建议。其一，threat_model.md 虽然可选但强烈建议写，README 给出的正确用法是把严重度口径写清楚：认证后的 SQL 注入算 high 还是 critical、没有演示 exploit 的缓冲区溢出是否封顶 high、存储型 XSS 在什么条件下升级，这些恰好对着官方自认的「严重度虚高」短板。其二，注册前跑 tools/validate.py 和 tools/check，注意 check 会以联网方式执行项目的 Dockerfile，README 自己警告只检查你信任的项目，或者用一台无所谓损失的机器。收报告怕泄露可以配 pgp 加密，但加密后报告只发 primary_contact，不能与 auto_ccs 并用；想暂停不删档，把 disabled 设为 true。

至于普通开发者，这个仓库对你更是一本教材：76 份 project.yaml 是安全联系人配置的最佳实践样本，validate.py 的 261 行是「把文档规则写成校验器」的干净范例。

---

信息来源

• 仓库与文档：github.com/anthropics/oss-scanner 的 README、tools/validate.py、projects/ 目录清单与 openssl 样例配置（10-14 本地快照，文件数与代码行数为 find+wc 统计）
• 星数、PR 编号、项目数：GitHub 页面与 API，10-14 快照（建仓 2026-10-08）
• 核心数字（29,000/6,000/近 5,000/88%/97 中 1 假阳性/CyberGym 检出率）：anthropic.com 发布文《Launching an opt-in vulnerability-finding service for open-source software》（2026-10-08），均为 Anthropic 自报口径，正文已逐处标注
• 维护者证言（PostgreSQL/OpenSSL/wolfSSL/curl/HotCRP）：Anthropic 发布文中的维护者证言，正文按转述处理
• 披露政策、注册规则、自检工具用法：README 原文