AREX Feed Article
Anthropic 公布 OSS Scanner 首轮扫描结果：77 个 critical、803 个 high 级模型评级发现
10 月 19 日，Anthropic 的 Claude 开发者账号 发帖称，OSS Scanner 已上线，为关键开源项目提供来自其最强模型的免费、定期漏洞扫描。首批扫描已向维护者报告 77 个 critical 级和 803 个 high 级发现，合计 880 条，且仍在扫描更多项目。帖文说，每条发现都附带概念验证（proof-of-concept），并在可能时附带补丁。
这些数字是 Anthropic 的单方公布。帖文把这些发现称为「模型评级」（model-rated）：报告由模型生成，没有经过 Anthropic 的逐条人工复核。OSS Scanner 的也说明，这类报告可能包含误报。它们只是模型标记的数量；维护者确认、修复了多少条，是另一回事。
Anthropic 把模型报告直接发给维护者
10 月 8 日，Anthropic 的研究博客发布了 OSS Scanner 的。Punit Shah 在 10 月 19 日的里也说，团队在发帖前 11 天上线了 OSS Scanner。随后，@ClaudeDevs 的帖文引用了这份更新，并给出相同的首轮数字。
Anthropic 在上线说明里解释了为什么要让报告绕过人工复核：过去六个月，它用模型扫描重要开源项目，发现超过 29,000 条候选漏洞，但人工只复核了约 6,000 条。有维护者直接要求把未验证的报告和补丁一起发来，至今已有近 5,000 份报告这样直接发送。OSS Scanner 把这个流程做成了一项服务：项目申请加入后，报告由模型生成，不再先经过人工分诊，直接发到维护者邮箱。
扫描管线并不只有一次模型调用。服务页面说，管线中的自动化代理会复核缺陷（bug）、提出补丁、做根因分析，最后把一组报告用邮件发给维护者；首轮扫描后还会定期重扫，找新引入的和此前漏掉的问题。重扫频率没有固定值，页面说取决于管线中的项目数量、服务使用广度等因素。
Punit 给出的参与规模是：约 650 个项目申请，114 个被接受。免费扫描仍要经过审核。
Anthropic 用 97 条抽查验证早期版本
这些发现按设计不经过人工复核。Anthropic 公开的一组准确性数据，来自对早期版本的一次抽查。上线说明说，公司请负责复核协同漏洞披露（CVD）发现的渗透测试专家检查了 48 个项目中的 97 个 critical 和 high 级发现，其中 85 个（88%）达到了其 CVD 流程的标准；其余 12 个里，11 个是真实问题但属于重复或已知发现，只有 1 个是误报。
这次抽查针对早期版本；它不能替代对这 880 条的全量验证。
Anthropic 也转述了维护者的反馈：有人觉得严重性评级偏高，或者扫描器误解了项目的威胁模型。项目可以在 threat_model.md 里写自己的评级标准；不提供时，扫描器会自行猜测。早期样本的表现不能直接换算成首轮报告的准确率。
curl 修好了 CVE-2026-92392
一个具体的修复案例是 curl。Punit 在线程里说，curl 修复了 CVE-2026-92392：一个 high 级的内存安全漏洞，由 OSS Scanner 的早期版本发现。他引用 curl 团队的说法，称这是 curl 近年来最严重的漏洞之一，即便最可能的结果只是崩溃。
10 月 14 日，Daniel Stenberg 在 curl 博客里写了：它出现在 HTTP/2 上传路径，属于释放后使用（use-after-free），curl 将其定为 HIGH；修复随 curl 8.23.0 发布。博文说，漏洞由 Anthropic 的 Luna Tong 通过新的 OSS Scanner 发现并报告；curl 安全团队在 9 月 15 日收到提交后数小时内确认，随后把原定八周的发布周期缩短到六周。
要触发这个漏洞，受害者得向恶意服务器上传数据，上传大小要接近 135KB，攻击者还要知道 curl 的架构并满足一串内存分配条件。博文说，成功利用的概率很低，最可能的结果是崩溃。
这是一条已确认、已修复的漏洞，但它来自 OSS Scanner 的早期版本，不能代表这批 880 条的命中率。它说明模型报告里至少有一条能走到 CVE 和正式补丁。
维护者用 pull request 报名，扫描在断网 VM 里
想加入的项目，核心维护者要向 Anthropic 的 提交一个 pull request（PR），在 projects/<project>/ 下放一份 project.yaml。必填项包括要克隆的 git 仓库、主要联系人邮箱；还要提供构建环境的 Dockerfile。还可以选填额外抄送地址、项目主页、威胁模型文件和 GPG 公钥（用于加密报告邮件）。
扫描器会先在能联网的隔离虚拟机（VM）里构建项目，然后把 VM 移到没有网络的环境里跑审计；报告只发给通过审核的主要联系人，如果项目指定了抄送地址，也会一并发送。Anthropic 说，每一份加入申请都会有人工审核，确认申请者确实是核心维护者，并在发送结果前再次核对联系人。
门槛参照 OSS-Fuzz：项目要对基础设施和用户安全有 critical 影响，暴露于远程攻击、被大量项目依赖是重要考量；全新的项目和大多数分支项目（fork）通常不在范围内。服务页面还说，它更适合已经能跟上已确认的 high/critical 报告、现在想进一步加固代码的项目。
Anthropic 不对未验证报告设 90 天窗口
OSS Scanner 的报告不适用 Anthropic 常规 CVD 流程的 90 天披露期。服务页面说，因为这些发现可能是误报，Anthropic 不愿在尚未逐条复核时要求维护者仔细阅读每条发现，所以不会对未验证报告设 90 天窗口；GitHub 仓库的说明更直接：报告由模型生成，因此不设 90 天披露期，也不会把这些发现公开。
如果 Anthropic 之后通过现有 CVD 流程人工验证了其中某条报告，才可能按 CVD 政策披露，时间从维护者被告知「这条已由人工验证」起算 90 天。页面还说，随着对 OSS Scanner 表现更有信心，未来可能对部分 high 级报告设披露期，但会提前通知，并允许项目选择退出。
维护者可以随时在配置里写 disabled: true 暂停报告，或删掉项目目录完全退出；退出后回到常规 CVD 流程。报告也可以要求用 GPG 加密，但加密后不能再加抄送地址。
服务页面承认，很多项目已经被报告数量压得喘不过气，因此它面向的是能跟上已确认 high/critical 报告的项目。
维护者确认与修复的拆分仍待核对
下一步可核对的是这 880 条里有多少被维护者确认、多少是重复、多少已经合并补丁。Punit 说「还没有扫描所有项目」，在更多项目完成扫描之前，首轮数字仍可能变化。