diff --git a/data.json b/data.json index a950dce3..5c2a06a9 100644 --- a/data.json +++ b/data.json @@ -27544,5 +27544,6 @@ "https://mp.weixin.qq.com/s/LLy5_UGSbruaFWXzTrhhOw": "极安破奕-给我一个txt，还你一个rce", "https://mp.weixin.qq.com/s/lA8ezIGnnW5Jz5DUoVlvLQ": "每周PDF资源：Atlassian曝严重漏洞；智能硬件企业CRA合规实践", "https://mp.weixin.qq.com/s/x6MFuNmAGqpBNXBCs0vrqw": "美国 (CISA) 警告：Zyxel GS1900 交换机漏洞已被积极用于攻击", - "https://mp.weixin.qq.com/s/c_f1XVcDeNXNyNgztkR_UA": "聚恒中台sendvalidatecode接口存在SQL注入  附POC" + "https://mp.weixin.qq.com/s/c_f1XVcDeNXNyNgztkR_UA": "聚恒中台sendvalidatecode接口存在SQL注入  附POC", + "https://mp.weixin.qq.com/s/Y62H54NR7HZQp15SF3hvEg": "面向开源生态的 AI 漏洞发现服务：Anthropic OSS Scanner 技术架构、数据效果与行业影响深度剖析" } \ No newline at end of file diff --git a/doc/2026-10/面向开源生态的 AI 漏洞发现服务：Anthropic OSS Scanner 技术架构、数据效果与行业影响深度剖析.md b/doc/2026-10/面向开源生态的 AI 漏洞发现服务：Anthropic OSS Scanner 技术架构、数据效果与行业影响深度剖析.md new file mode 100644 index 00000000..77815267 --- /dev/null +++ b/doc/2026-10/面向开源生态的 AI 漏洞发现服务：Anthropic OSS Scanner 技术架构、数据效果与行业影响深度剖析.md @@ -0,0 +1,644 @@ +# 面向开源生态的 AI 漏洞发现服务：Anthropic OSS Scanner 技术架构、数据效果与行业影响深度剖析 +原创 H + H AI安全推进计划 2026-10-11 23:14 + +1 +   +引言：为什么 OSS Scanner 值得深入研究 + +2026 年 10 月 8 日，Anthropic 发布 OSS Scanner——一个面向开源软件生态的、自愿加入（opt-in）的 AI 漏洞扫描服务。加入的开源项目将由 Anthropic 最强的模型（含尚未公开发布的 Claude Mythos）进行周期性的安全扫描，全部免费。 + +这件事本身并不复杂，但它同时释放了三重信号，值得任何关心软件供应链安全的人认真对待： + +● 攻击面信号：AI 发现漏洞的成本已经低到可以让一家商业公司对全行业免费提供——这说明「发现漏洞」这件事的边际成本正在趋近于零。 + +● 治理信号：Anthropic 明确表示这些报告不做人工复核、不设 90 天披露期、不主动公开。这在传统的协调漏洞披露（CVD）惯例上开了一个显著的例外。 + +● 生态信号：免费服务的对象是「对基础设施和用户安全有关键影响」的开源项目，其准入标准对标 Google 的 OSS-Fuzz。这是大厂以自身 AI 能力介入开源治理的又一实例。 +

十条核心判断

1. OSS Scanner 是 Project Glasswing 的「产品化外溢」，本质是把内部扫描能力向开源生态开放。                    
2. 它的技术核心不是「AI 能找漏洞」，而是「两阶段离线审计」这一工程架构——有网构建、断网审计。                    
3. 配置契约极简：一个 project.yaml + 一个 Dockerfile，可选 threat_model.md。                    
4. 「不做人工复核」是刻意设计，换来的是扫描频率和覆盖面，代价是误报风险由维护者承担。                    
5. 官方公布的漏斗数据（29,439 → 584）揭示了真正的瓶颈：不是发现，而是验证与修复。                    
6. 88% 的抽样验证通过率是在 97 条样本上的结果，样本量有限，不宜过度外推。                    
7. 维护者反馈总体积极（PostgreSQL/OpenSSL/wolfSSL/curl 均正面），但存在严重性评级争议。                    
8. 第三方实测显示单项目扫描成本约数美元级别，构建校验约数分钟，门槛显著低于传统渗透测试。                    
9. 治理争议集中在：无披露期 + 模型生成 + 不可溯源的责任边界。                    
10. 该服务的长期价值取决于「修复侧」能否同步提速，否则只会加剧维护者负担。

+  + +2 +   +背景溯源：从 Project Glasswing 到 OSS Scanner + +要理解 OSS Scanner，必须先理解它从哪来。它不是凭空出现的产品，而是 Anthropic 一系列安全计划在开源领域的一次能力外溢。 + +2.1 +   +AI 漏洞发现能力的跃升曲线 + +Anthropic 在公告中引用了一个具有标志意义的基准数据：在 CyberGym 这一学术漏洞发现基准上，大语言模型从 2025 年初只能发现不到 20% 的漏洞，到 2026 年已经能发现超过 85%。 + +这个变化带来的直接后果，公告里说得很直白：开源维护者「从过去主要收到 LLM 产生的低质量噪声，转变为收到高质量的缺陷报告」。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/8SYXzUAIerSwnoRgxg4nGLqyxvjajLd3DwT21ggDKdicOlMha25HshG6AUy2B5oInsgiaKfvuc15rqzPPOHKZiafTwWQwNQvIlqAN8lTtgdibMI/640?wx_fmt=png "") + +图 1 +   +AI 模型漏洞发现能力演进（CyberGym 学术基准）——官方仅给出两个端点 + +注：本图刻意只呈现官方原文给出的两个数据点。原文并未提供中间年份的连续数值，任何对中间过程的插值都属于推断，本报告不予呈现。 + +2.2 +   +Project Glasswing 的关键数据 + +2026 年 4 月，Anthropic 启动 Project Glasswing：一项与约 50 家合作伙伴协作、使用 Claude Mythos Preview 去发现全球最关键软件中漏洞的联合行动。 + +一个月内（截至 5 月 22 日首次更新），该计划交出了一组值得注意的数字： +

指标

数值

备注

发现的高危/严重漏洞

10,000+

由约 50 家合作伙伴共同提交

Cloudflare 发现缺陷

2,000 条

其中 400 条为高危/严重；误报率被其团队认为优于人工测试者

Mozilla Firefox 150 修复

271 个

为 Firefox 148 使用 Claude Opus 4.6 时的 10 倍以上

扫描的开源项目数

1,000+

覆盖支撑互联网的关键项目

总发现（含中低危）

23,019 条

模型自评口径

模型自评高危/严重

6,202 条

估计值，非人工确认

已由独立机构评审

1,752 条

六家独立安全研究机构（少量为 Anthropic 自评）

判定为有效真阳性

1,587 条

占已评审的 90.6%

确认达高危/严重

1,094 条

占已评审的 62.4%

+表 2-1 +   +Project Glasswing 开源扫描阶段的关键数据（2026-05-22） + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/8SYXzUAIerSwxFVjqItv7obhV1Kcic8GCR3LcUV25mW44UlnGVjGvk4MHE76wGShtctn7aictt6f5DYRicnWUk9B0KcL9lBH4F0ibSsEXPYx88g/640?wx_fmt=png "") + +图 2 +   +Project Glasswing 开源扫描阶段的关键指标（2026-05-22） + +这些数字中最值得注意的，不是「找到了多少」，而是「确认率」的落差：模型自评的高危漏洞中，经独立复核后只有 62.4% 被确认达到高危/严重。换句话说，模型对严重性的判断有约四成的向上偏移。这一点在后面讨论 OSS Scanner 时同样适用。 + +2.3 +   +瓶颈转移：从「找得到」到「修得完」 + +Glasswing 更新中有一句被反复引用的话： + +「软件安全领域的进展，过去受限于我们能多快发现新漏洞。现在，它受限于我们能多快验证、披露和修补 AI 发现的大量漏洞。」 + +这构成了理解 OSS Scanner 的钥匙。整个服务的设计逻辑，都是在为「验证与披露」这一环节做减法——因为这一环节严重依赖人力，而人力正是最稀缺的资源。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/8SYXzUAIerRtN9WAgyCEzbR6TCIttXJp1YVfKHQF7MIxfNAyYC8g47Kia9PJb45Lraq3NKc6k5bMpibjpwIBhNSEknT4WyHBuZAvTDbuXjXCg/640?wx_fmt=png "") + +图 3 +   +OSS Scanner 发展时间线 + +2.4 +   +Cyber Mission 与关键基础设施防御计划 + +与 OSS Scanner 同日（或接近）宣布的，还有 Anthropic 的 Cyber Mission 框架下的Critical Infrastructure Defense Program（关键基础设施防御计划），该计划有 11 家创始合作伙伴，目标是保护关键基础设施与开源软件。 + +Anthropic 对外的预测是：两年内，AI 在网络安全上将「有利于防御方」——更容易在软件出货前捕获缺陷、从零编写本质安全的软件、以及用模型主动防御系统。这个预测本身是一个立场表述，本报告将其作为「官方观点」呈现，而非既定事实。 + +2.5 +   +Cyber Verification Program 的分级模型访问 + +对于希望合规使用先进模型进行安全工作的从业者，Anthropic 提供了 Cyber Verification Program（CVP）。该计划的要义是：经过验证的安全专业人员，可以在减少「阻止分类器」（blocking classifiers）干扰的前提下使用高级能力。简单说，就是为正当的安全研究打开一条不必与安全护栏反复对抗的通道。 + +这一设计侧面反映了一个现实矛盾：模型厂商的安全护栏与安全研究者的实际工作需要之间存在张力。对红队与渗透测试团队而言，CVP 的可用性比 OSS Scanner 更值得关注。 + + +3 +   +产品解剖：OSS Scanner 究竟是什么 + +3.1 +   +定位、准入与免费模式 + +用一句话概括：OSS Scanner 是 Anthropic 提供的一项服务，对关键开源仓库进行周期性安全漏洞扫描，免费、自愿加入。 + +官方对「哪些项目可以加入」的口径与 Google 的 OSS-Fuzz 类似，核心判据是：项目应当具有「对基础设施和用户安全的关键影响」（critical impact on infrastructure and user security）。审核按个案处理，不是满足条件就自动通过。 + +免费这一点值得单独强调。传统上，对一个重量级开源项目做系统的安全审计，成本在人力与时间上都相当可观；而 OSS Scanner 把这一成本降到了零（对项目方而言）。这背后的商业逻辑是：Anthropic 用自身模型能力承担扫描成本，换取对真实世界代码库的大规模实战验证，以及生态影响力。对项目方而言，这几乎是一笔无条件的好交易——唯一的成本是配置工作量与误报处理负担。 + +3.2 +   +「不做人工复核」的设计取舍 + +这是 OSS Scanner 最具争议、也最具技术含量的一个设计决定。官方 README 的表述是： + +「报告由模型生成，未经人工复核。正因为如此，我们不对这些发现施加 90 天披露期，也不会将其公开。」 + +这里存在一个清晰的逻辑链条： + +● 因为不做人工复核 → 报告可能包含误报； + +● 因为可能包含误报 → 若采取 90 天强制披露，可能造成对维护者的不公（虚假警报被公开）； + +● 因此选择：不设披露期、不主动公开，把判断权完全交给维护者。 + +这是一个自洽的设计，但它把成本转移给了接收方。维护者收到的可能是未经确认的缺陷报告，需要自行判断真伪。对于人手本就紧张的开源项目，这既是帮助也是负担。我们将在第 7 章详细讨论这一取舍的利弊。 +

一个容易被忽略的例外条款

虽然 OSS Scanner 的报告本身不设披露期，但官方留了一个后门：如果某条报告后来通过Anthropic 现有的 CVD 程序被人工验证，则该漏洞将回归标准 CVD 政策，从「通知你该报告已被人工验证」之日起计 90 天披露。此外，官方表示随着对 OSS Scanner 表现的信心提升，未来可能对某些高危漏洞报告施加披露期。

+  + +3.3 +   +与传统 SCA 工具的本质差异 + +许多人第一次听到「漏洞扫描」会联想到 SCA（软件成分分析）工具，如 Dependabot、Snyk、Sonatype 等。但两者在技术路径上完全不同，不可互相替代。 +

维度

传统 SCA / 依赖组件分析

OSS Scanner（AI 驱动）

分析对象

依赖清单中的已知组件版本

项目自身源码的语义逻辑

发现来源

CVE 数据库 / 漏洞库比对

模型对代码语义与数据流的推理

典型产出

「你用的 X 库 1.2 版本有已知 CVE」

「这段处理逻辑存在可被触发的缺陷」

能否发现新漏洞

否（只能匹配已知漏洞）

是（可发现未经披露的原创缺陷）

候选补丁

通常无

有（模型生成可参考的 diff）

复现器

通常无

有（自包含、可在镜像内触发）

误报特征

版本误判、传递依赖噪音

语义误判、严重性评级偏高

成熟度与治理

高（生态成熟、报告规范）

早期（治理机制仍在演进）

+表 3-1 +   +两类「漏洞扫描」的本质差异 + +![](https://mmbiz.qpic.cn/mmbiz_png/8SYXzUAIerRgb5Gkicdof10GFia4IuibMQV3ibnH86cSGicWIVcIsYEa48edk8RmW5GamwkDcwnBibQCHpiaQkQPysniaXxaCb2BFdF1Qgl3T0bwbAk/640?wx_fmt=png "") + +图 4 +   +能力矩阵对照：AI 驱动扫描 vs 传统 SCA + +从图中可以清楚看到两者的互补性：传统 SCA 在「供应链组件覆盖」和「生态治理成熟度」上占据绝对优势，而 AI 驱动扫描在「语义级缺陷理解」「跨函数路径可达性」和「候选补丁生成」上具有压倒性的能力。理性的做法不是二选一，而是在工具链中同时部署，各司其职。 + +4 +   +技术架构：两阶段离线审计流水线 + +这一章是报告的技术核心。OSS Scanner 最值得学习的地方，不是「用 AI 找漏洞」这个口号，而是它如何用一个巧妙的工程架构，解决了「让 AI 在可信环境中审查任意项目」这一难题。 + +4.1 +   +有网构建 → 断网审计 + +整个流程被清晰地切成两个阶段，中间由一道「断网闸门」隔开： + +阶段一（有网）： +扫描器在隔离虚拟机中拉取项目源码，执行项目提供的 Dockerfile，安装依赖、编译项目、运行基础测试。这一阶段网络是开放的，目的是把构建所需的一切都获取到位。 + +阶段二（断网）： +构建完成后，虚拟机被迁移到一个无互联网访问的网络中，AI agent 才开始执行安全审计。 + +![](https://mmbiz.qpic.cn/mmbiz_png/8SYXzUAIerRMe8MA3kyCEERxOy2ACPGdIom06G8hnrokMOJo9jcic2xEickUkhqicN9xOZ4HQcfcrfYXjxaeG6vD4TJsDpYeiazv438qeBxzgibo/640?wx_fmt=png "") + +图 5 +   +OSS Scanner 两阶段离线审计流水线 + +这个设计的意义远超「省事」： + +● 安全隔离：被扫描的代码在审计阶段无法回连外部（不存在数据外泄或反向控制的网络通道）。 + +● 结果确定性：由于审计阶段无法下载新东西，任何复现行为都只能依赖镜像内已有的东西，这迫使 Dockerfile 必须完整声明依赖——复现性由此得到保证。 + +● 攻击面收敛：即使被测项目本身含恶意代码，它也失去了在审计阶段向外联络的能力。 + +官方 README 用一句话点出了这个设计的硬约束： + +「构建或测试所需的任何东西，都必须在最初的 Dockerfile 安装阶段获取完毕。」 + +4.2 +   +/src 契约与镜像形态 + +Dockerfile 模板中有一条注释，定义了扫描器与项目之间的一个隐含契约： + +# scanner contract: the checkout lives inside the image, at /src + +译：扫描器契约——代码检出（checkout）位于镜像内部的 /src 目录。这意味着，项目在编写 Dockerfile 时，必须保证源码被放置到 /src。模板通过 COPY . /src 与 WORKDIR /src 两行标准写法达成这一点。 + +4.3 +   +Dockerfile 工程契约逐行解读 + +官方 Dockerfile 模板（以 CMake 项目为例）看似平常，但每一处都藏着工程考虑。下面逐段拆解： +

片段

官方原文

工程意图

基础镜像

FROM debian:bookworm

选择稳定、体积适中的 Debian 基础镜像

环境变量

CC=clang                    
CXX=clang++

统一编译器，避免依赖 gcc 默认配置带来的差异

依赖安装

apt-get install -y --no-install-recommends                    
ca-certificates build-essential                    
clang cmake ninja-build pkg-config git python3

装入构建工具链与运行时；--no-install-recommends 控制体积

清理缓存

rm -rf /var/lib/apt/lists/*

减小镜像体积，加快搬运

源码放置

COPY . /src                    
WORKDIR /src

落实 /src 契约

构建配置

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo                    
-DCMAKE_C_FLAGS="-g -fno-omit-frame-pointer"

关键：带调试符号（-g）与帧指针，让 agent 能定位与调试崩溃

构建执行

cmake --build /src/build -j"$(nproc)"

并行构建；任何一步失败都视为构建失败并通知 contact

测试

ctest --output-on-failure -j$(nproc)                    
--timeout 300 || echo "WARNING: ctest reported failures"

跑便宜测试以确认镜像可用，但失败不中止构建

+表 4-1 +   +官方 Dockerfile 模板的逐段技术解读 + +其中有两个细节特别值得学习： + +● -g -fno-omit-frame-pointer：这不是常规发布构建的选择，而是为了调试。AI agent 在审计时需要能读懂崩溃现场、能下断点，因此刻意保留调试信息。 + +● 测试失败不中止构建：用 || echo 兜住 ctest 的失败返回码。原因是——很多项目的测试在受控环境中本来就会失败（缺少特定硬件、特定数据集等），若因此拒绝构建，会大量排除掉本该扫描的项目。这是「可用性优先」的务实选择。 + +4.4 +   +Agent 流水线的角色分工 + +进入断网环境后，执行的是一组协作的 agent。官方对报告产物的描述，反向揭示了这条流水线的构成： + +![](https://mmbiz.qpic.cn/mmbiz_png/8SYXzUAIerTMTl84vYe9kg6D1I2wJhUt8zKXLbW66rpKMrCYrY8RRDIvhfMs4icy0NwSf01kGBHOc6MVaodhdVcjWjVUficy4sianTKaickdtRU/640?wx_fmt=png "") + +图 6 +   +Agent 流水线的角色分工（结构性还原） + +需要说明的是，Anthropic 并未公开 agent 流水线的内部实现细节。上图是基于两款官方材料——一是对报告产物（复现器、解释、二分、补丁）的描述，二是 Glasswing 更新中对工具链「映射代码库、启动扫描子代理、分诊发现、撰写报告」的说明——所做的结构性还原，用于帮助理解工作逻辑，不代表官方架构。 + +4.5 +   +报告产物的四段式结构 + +每条合格的报告包含四个部分，这是一个相当完整的「可用缺陷报告」的标准形态： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/8SYXzUAIerQavVibUd1yomSVwG9HiaaLGJjUP0xzic0iaA6vDWAWTIcx5PzicC0obSzLSZLiaow6GoIIZj6cyqRqMVMPTXgqJp1nCqubZJBicmibGXA/640?wx_fmt=png "") + +图 7 +   +单条漏洞报告的四段式结构 +

组成部分

内容

对维护者的价值

自包含复现器

可在构建好的镜像内独立触发缺陷的操作序列

无需猜测如何复现，拿到即可验证

漏洞解释

缺陷成因、可达路径、影响面、利用前提

帮助判断是否真的可利用、影响范围多大

引入点二分

定位首个引入该缺陷的提交（bisection）

界定受影响版本区间，指导补丁回溯

候选补丁

可参考的修复 diff

降低修复门槛，但可用性由维护者判断

+表 4-2 +   +报告四段式结构及其价值 + +4.6 +   +本地工具链：validate / check / check --qemu + +为了让项目在提交 PR 前就能确认配置无误，官方提供了两个命令行工具： +

命令

作用

依赖要求

tools/validate.py

按注册规则校验 projects// 目录的合规性

Python 3 + PyYAML

tools/check

完全按扫描器的方式构建项目，并在构建完成的镜像中打开一个无网 shell；若测试能在该容器中通过，扫描器大概率也能正常工作

本机需安装 git、Docker、Python 3 + PyYAML

tools/check --qemu

在按扫描器布局构造的虚拟机内执行同样的检查

Linux x86-64 + QEMU（替代 Docker）

+表 4-3 +   +官方本地校验工具链 + +这套工具链体现了良好的工程实践：可本地验证、可复现、把「配置错误」的成本前置到提交前，而不是让它在扫描器的远端环境中失败。对希望接入的项目而言，这意味着接入过程本身是可控且可预期的。 + + +5 +   +配置机制：project.yaml 与 threat_model.md + +OSS Scanner 的接入门槛相当低。核心配置就是两个文件：一个 project.yaml 声明基本信息，一个 Dockerfile 描述如何构建。可选的 threat_model.md 则是提升扫描质量的杠杆。 + +5.1 +   +project.yaml 字段全解 + +官方的注册方式非常直接：向仓库提交一个 PR，新增一个目录 projects//，在其中放入 project.yaml。字段设计如下： +

字段

要求

说明

repo

必填

待扫描的 git 仓库 https 地址，可用 #branch / #tag 固定版本

primary_contact

必填

报告与构建失败通知的唯一主收件地址

dockerfile

条件必填

构建镜像的路径；若与 project.yaml 同目录放置可省略

threat_model

可选（强荐）

项目专属威胁模型的路径，用于约束扫描范围与评级

auto_ccs

可选

每封报告额外抄送的地址列表；与 pgp 互斥

homepage

可选

项目主页地址

pgp

可选

Armored OpenPGP 公钥；启用后报告仅发 primary_contact

disabled

可选

true 表示暂停报告但不移除注册

+表 5-1 +   +project.yaml 字段矩阵（依据官方模板逐字段核对） + +完整示例（官方模板形态）： +

repo: https://github.com/example/project#main   # 必填：待扫描的 git 仓库

primary_contact: security@example.org           # 必填：报告与构建问题发往此处

auto_ccs:                                        # 可选：每封报告额外抄送

  - maintainer@example.org

homepage: https://example.org                    # 可选

disabled: false                                  # 可选：true 暂停报告

dockerfile: .oss-scanner/Dockerfile              # 条件必填

threat_model: .oss-scanner/threat_model.md       # 可选（强荐）

+代码 5-1 +   +project.yaml 完整字段示例（源自官方模板） + +有三点必须注意： + +● repo 是「唯一」一个要扫描的仓库，不是多个。可用 #branch 或 #tag 固定版本。 + +● project.yaml 中的邮箱地址是公开的。官方明确提示「请使用你乐于被公开的地址，例如一个安全专用别名」。 + +● pgp 字段与 auto_ccs 互斥：一旦配置 PGP 加密，报告只发给 primary_contact 本人，因为加密后无法同时抄送多人（除非各自持有私钥）。 + +5.2 +   +Dockerfile 两种放置方式的权衡 + +Dockerfile 必须提供，但可以放在两个位置之一，这带来了一个明确的权衡： +

放置方式

写法

优点

缺点

放在自己仓库（推荐）

在 project.yaml 中设置 dockerfile: 路径

可在不提交 PR 到上游仓库的情况下自行更新构建方式

需要在项目中新增文件

放在注册仓库

放在 projects//Dockerfile，并删除 project.yaml 中的 dockerfile 键

不污染项目自身仓库

每次调整构建都需要向上游提交 PR

+表 5-2 +   +Dockerfile 两种放置方式的对比 + +官方推荐第一种——理由是「允许你在不必提交 PR 的情况下更新构建」。这个设计把「构建方式的迭代权」留给了项目维护者自己，减少了协作摩擦。threat_model.md 的放置逻辑与之完全相同。 + +5.3 +   +threat_model.md：把威胁模型喂给扫描器 + +如果说 Dockerfile 决定了「能扫什么」，那么 threat_model.md 决定了「扫描器在意什么」。这是 OSS Scanner 中提升结果质量最关键、却也最容易被忽视的配置。 + +官方对这个文件的价值有明确的表述：最有用的用法，是给出「如何评定报告严重性」的指引。官方举了几个非常具体的例子： + +● 认证后的 SQL 注入，你算高危还是严重？ + +● 没有演示出实际利用的缓冲区溢出，是否封顶为高危？ + +● 存储型 XSS 在什么条件下算中危、高危、严重？ + +这直接击中了 AI 扫描的一个核心痛点：模型并不了解你的业务语境。同一个缺陷，在一个内网工具里可能无关紧要，在一个面向公网的认证服务里则可能致命。通过 threat_model.md，项目可以把自身的威胁模型显式地传递给模型。 + +官方模板包含五个章节，问的都是直击要点的问题： +

模板章节

要回答的问题

官方示例

What this project does and where untrusted input enters

项目做什么，不可信输入从哪里进入？

「一个压缩库；我们假定所有输入都不可信」

Components that matter most / least

哪些组件最重要、哪些最不重要？

「解码器重要；压缩器次要但仍在范围内；contrib/ 是第三方，不在范围内」

How to exercise it

如何驱动它进行测试？

「examples/ 有小驱动程序；test/ 有回归语料库」

How you rate severity

你如何评定严重性？

「任何缓冲区溢出、UAF、double free 至少为高危；若可控并可能导致 RCE 则为严重；所有 DoS 为中危」

Anything to leave alone

有什么是不要碰的？

「不要报告 x86 上 SIMD 代码路径的未对齐访问」

+表 5-3 +   +threat_model.md 模板的五个章节 +

实践建议

对希望接入的项目，本报告建议把 threat_model.md 视为「必填」而非「可选」。它是解决「模型严重性评级偏高」这一已知问题的最低成本手段——与其事后逐条纠正误报的严重性，不如事前把评级标准写清楚。

+  + +5.4 +   +注册、变更与退出流程 + +整个生命周期管理被设计得相当轻量： +

操作

方式

注册项目

提交 PR 新增 projects//project.yaml（一个 PR 一个项目），           
先跑 tools/validate.py 与 tools/check，            
填写 PR 检查清单。只有项目核心维护者可以注册，官方合并前会核实身份。

变更配置

提交 PR 修改 projects//project.yaml。

暂停报告

设置 disabled: true——暂停报告但不移除注册。

完全退出

删除 projects// 目录。

签署 CLA

首次 PR 合并前需签署贡献者许可协议（CLA），由机器人在首个 PR 中给出指令，回复指定语句即可。只需签一次。

+表 5-4 +   +项目全生命周期操作 + +6 +   +数据与效果评估 + +这一章集中呈现可量化的证据，并对不同来源的数字做交叉核对。凡是无法溯源的数字，本报告一律标注或虚化。 + +6.1 +   +完整漏斗数据序列 + +Anthropic 公开了一个开源漏洞仪表盘，展示了从候选漏洞到分配标识符的完整漏斗。截至 2026 年 10 月 2 日，各阶段数据如下： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/8SYXzUAIerR2F4PuqSqU0yvpiboqicC5frwgDdGYwx0grltDMlnp5DmZUu0LGDoPZI8ZV2akYRB9wjKc7ESwibqhKZgxENrtwS3Br5b8haPajM/640?wx_fmt=png "") + +图 8 +   +开源漏洞「发现 → 修复」漏斗（截至 2026-10-02） +

阶段

数量

说明

扫描产生的候选漏洞

29,439

模型原始输出，未经验证

人工评审（去噪/复现）

6,123

人力成为瓶颈环节

确认为真实漏洞

5,674

占已评审的 92.7%

生成报告并通知维护者

6,157

覆盖 591 个项目

维护者确认收到

5,103

确认率约 82.9%

已修补（公开统计）

516

公开可统计的修补数

分配标识符（CVE/GHSA）

584

219 个 CVE + 365 个 GHSA

+表 6-1 +   +开源漏洞漏斗数据（源自官方仪表盘，截至 2026-10-02） + +这组数字最值得注意的是两个比值： + +● 评审覆盖率：29,439 条候选中，仅 6,123 条（约 21%）得到人工评审。换句话说，近八成的扫描产出尚未被人类看过——这就是「验证瓶颈」的量化体现。 + +● 修补落地率：5,103 条被确认收到的报告中，仅 516 条有公开可统计的修补，约 10%。官方对此给出了三点解释：仍在 90 天窗口早期、部分修补无公开公告导致漏计、以及安全生态本身已超载。 + +第三点解释尤其值得注意——官方自己承认：「即便以我们相对缓慢的披露节奏，Mythos Preview 也在给一个本已超负荷的安全生态增加负担。」这种坦率在厂商宣传材料中并不常见，也因此更有参考价值。 + +6.2 +   +88% 抽样验证实验 + +为验证早期版本 OSS Scanner 的质量，Anthropic 请其 CVD 流程中的专家渗透测试人员，对来自 48 个项目的 97 条高危/严重漏洞做了逐条复核。结果如下： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/8SYXzUAIerQkNibOkTtZolfYcVH9b2YOKW0zibvib0dgFnkRXJbnzgicDTrjfQzU0LEhetEziauY6yUiaHeb4VEkWiccXjtIJiaH79AbmhD2otY4QBs/640?wx_fmt=png "") + +图 9 +   +早期版本的抽样验证：97 条样本中 88% 达到 CVD 质量门槛 +

复核结果

数量

占比

达到 CVD 流程标准

85

87.6%

真实但属于重复问题

11

11.3%

误报（invalid）

1

1.0%

合计

97

100%

+表 6-2 +   +97 条高危/严重漏洞样本的专家复核结果 + +这组数字非常重要，但必须谨慎解读： + +● 样本量有限：97 条样本来自 48 个项目，且都是「高危/严重」这一子集，不能直接外推到全部 29,439 条候选漏洞。 + +● 仅 1 条被判定为误报，但 11 条属于重复——这意味着真实场景中「去重」可能是比「误报」更主要的噪声来源。 + +● 官方也承认：仍有维护者反馈严重性评级偏高、或扫描器误解了项目的威胁模型。这与 Glasswing 阶段 62.4% 的确认率相互印证。 + +6.3 +   +维护者一手反馈 + +官方公告引用了五位知名开源维护者的评价。这些引用是「官方挑选后呈现」的，因此本报告一并标注这一属性。为便于复核，原文引用如下： +

维护者

项目

官方引用原文（节选）

Noah Misch

PostgreSQL

「OSS Scanner 的发现中，PostgreSQL 缺陷占比异常之高。数份报告附带的修复几乎可以直接采用，快速通道访问让我们能在 GA 版本发布前解决最新问题。」

Anton Arapov

OpenSSL

「约 18 个月前、Glasswing 之前的早期 AI 报告令人震惊（质量差）。而从 Anthropic 收到的报告——包括原始模型输出——质量与人工报告相当，有时更好。尤其是当报告附带真实利用代码时，工程师几乎立刻就能验证。」

Todd Ouska

wolfSSL

「这些报告的信号很强：我们收到的 74 份报告中，除 2 份外全部有效，其中 5 份成为 CVE。附带补丁的报告能直接嵌入我们现有的验证与修复流程。我们希望收到更多。」

Eddie Kohler

HotCRP

「缺陷报告详尽清晰，对 HotCRP 复杂的权限模型有很强的理解，缺陷优先级排序也很好。」

Daniel Stenberg

curl

「我们使用所有可用的最先进工具来查找问题、强化产品……OSS Scanner 帮助我们发现了多个值得处理的 curl 问题，其中包括近几年最严重的 curl 漏洞之一。」

+表 6-3 +   +维护者反馈（源自 Anthropic 官方公告，为官方挑选后呈现） +

如何解读这些反馈

这些引用的价值在于提供了「可验证的第三方参照点」——例如 wolfSSL 的「74 份报告中 72 份有效、5 份成为 CVE」是一个具体可查的比值。但需注意：这是官方挑选的正面样本，不能据此认为所有维护者的体验都是正面的。第 7 章将呈现对立的观察。

+  + +6.4 +   +案例深挖：CVE-2026-5194 wolfSSL 证书伪造 + +在 Glasswing 更新中，官方点名了一个具体的、已修补的高危漏洞，作为能力展示的实例。本报告将其作为技术细节的锚点单独剖析。 +

项目

内容

CVE 编号

CVE-2026-5194

受影响项目

wolfSSL（知名开源密码学库，宣称用于全球数十亿设备）

漏洞类型

证书伪造（certificate forgery）——可伪造证书，进而在用户看来完全合法的网站上假冒银行或邮件服务商

CVSS 评分

Anthropic/通用口径 9.1；Red Hat 评定为 10（最高）

修复版本

wolfSSL 5.9.1

报告者

Nicholas Carlini（Anthropic Frontier Red Team）

根因（公开分析）

wc_SignatureVerify 未校验 digest 长度、未检查 OID

状态

已修补；官方表示将发布完整技术分析

+表 6-4 +   +CVE-2026-5194 关键信息（多来源交叉） + +这个案例的示范意义在于：它不是一个「配置错误」或「已知漏洞的变体」，而是一个需要理解密码学协议语义、并能构造出实际伪造证书的深度缺陷。模型不仅发现了它，还构造了可用的利用路径——这正是「可利用性判定」能力的具体体现。 + +同时也要保持审慎：这是一个被官方反复引用的标志性案例，属于「挑选出的最佳样本」。它能证明上限，但不能代表典型产出。 + +6.5 +   +数字口径矛盾点辨析 + +在交叉核对多个来源时，本报告发现了若干数字口径不一致之处。这些差异本身值得记录，因为它提示读者：面对 AI 安全效能数据时应保持核对习惯。 +

争议点

口径 A（官方原文）

口径 B（第三方转述）

本报告处理

Glasswing 已评审数量

1,752 条（Glasswing 更新原文）

1,726 条（部分第三方转述）

以官方原文 1,752 为准；差异可能源于转述时点或统计口径不同，本报告不采信第三方数字

候选漏洞总数

29,000+（公告表述）

29,439（仪表盘精确值）

两者不矛盾：前者为公告中的概数，后者为仪表盘精确计数

已通知维护者数量

近 5,000 条（公告）

6,157 条（仪表盘，含 591 项目）

时点不同：公告为发布日表述，仪表盘为 10-02 快照，后者更晚

高危/严重确认率

62.4%（占已评审）

常被误读为「全部高危中 62.4% 为真」

必须强调：分母是「已评审的 1,752 条」，不是全部发现

+表 6-5 +   +数字口径差异辨析 +

一条通用的数据阅读建议

AI 安全领域的效能数字，务必确认三件事：分子分母分别是什么、样本是否经过挑选、统计时点是何时。本报告在呈现任何数字时都尽量交代这三点；对无法交代的第三方数字，采取不采信或明确标注为「不可溯源」的处理方式。

+  + +7 +   +争议与第三方质疑 + +任何一份只呈现厂商自述的研究报告都是不完整的。这一章集中呈现独立的、来自厂商之外的观察与质疑，并尽可能标注其证据强度。 + +7.1 +   +「无人工复核」的双刃剑 + +这是围绕 OSS Scanner 最核心的争议。其利弊可以明确地分为两侧： +

视角

收益

代价

对 Anthropic

扫描频率与覆盖面大幅提升；不受限于人类审核产能；可对全行业免费提供服务

报告质量无兜底；误报可能损害品牌信誉；「免费提供未经确认的缺陷报告」在伦理上存在争议

对维护者

能更快拿到 AI 发现的所有线索（含未确认的）；可以要求「把你们有的一切都发给我」

需要自行判断真伪；在维护者本就超负荷的情况下进一步增加工作量；误报可能造成时间浪费与挫败感

对生态

加速漏洞的整体发现速度

若误报率不可控，可能引发「狼来了」效应，削弱维护者对 AI 报告的信任，反而降低整体效率

+表 7-1 +   +「无人工复核」的利弊矩阵 + +值得注意的是，官方对这一取舍是自觉的。Glasswing 更新中提到：部分维护者已明确表示「严重受限于产能」，甚至有人请求 Anthropic 放慢披露速度，以便有时间设计补丁。这既说明需求真实存在，也说明现有节奏已经超出生态承载能力。 + +7.2 +   +社区治理与 PR 接受率 + +根据 The Hacker News 报道，截至 2026 年 10 月 9 日，该仓库已提交 116 个 PR。而独立研究者观察到的一个现象值得关注：在早期阶段，提交的 PR 中全部未被立即接受。 + +这一观察需要谨慎对待：PR 未被接受可能有多种原因——项目本身不符合准入标准、配置存在问题、审阅排队、或 Anthropic 有意控制接入节奏。它不必然意味着治理失败。但它的确提示了一个现实：接入并非「提交即通过」，存在人工审核关卡。 + +7.3 +   +独立实测：成本、耗时与命中率 + +独立研究博客 rotecodefraktion.de 对 OSS Scanner 做了一次实测——以自己的 C 语言项目 f451 接入，观察完整流程。这是本报告能找到的最具参考价值的第三方一手数据。以下数据均标注为「单项目样本」。 + +![](https://mmbiz.qpic.cn/mmbiz_png/8SYXzUAIerRsCqiacfjiaYmaclhYLS4KZicXpKCRic1I1Z9e4LIfthZ0pKZZj8SG970Xe5C98LCiaiazT1702xYGY695GDLs3q4I523dekyfwkv18/640?wx_fmt=png "") + +图 10 +   +独立研究者对 OSS Scanner 的实测结果（单个中小型 C 项目） +

观察项

实测结果

说明

tools/check 构建校验耗时

约 3 分钟

本地环境实测

单次扫描的 agent 步数

55 步

Claude Code + Opus 5.5 环境

单次扫描模型开销

约 4.43 美元

按 API 计费口径估算

发现总数

7 条

4 高危 + 1 中危 + 1 低危 + 1 未确认

高危占比

4/7

与官方「严重性偏高」的观察一致

额外发现

存在未被确认的条目

说明报告确实包含需要维护者自行判断的项

+表 7-2 +   +独立研究者单项目实测数据（样本量 N=1，不具统计意义） + +这组数据的价值不在于精确性，而在于量级：一次完整的项目扫描，成本在数美元级别、耗时在分钟级别。对比传统人工渗透测试动辄数万到数十万元的成本，经济性差异是数量级的。这也解释了为什么厂商有能力「免费」提供这项服务——其边际成本对厂商而言极低。 + +7.4 +   +安全边界：tools/check 的网络与供应链风险 + +官方在 README 中主动披露了本工具链的两项风险，这种坦率值得记录，也应成为使用者必读的安全提示： +

官方明示的两项风险

风险一：tools/check 会像 docker build 一样，以网络访问权限运行项目自带的 Dockerfile。配合 --qemu 时，构建在虚拟机内进行，可避免触碰本地文件，但它仍可能访问你机器或本地网络上的服务。官方建议：只检查你信任的项目，或在一台「没什么可失去的」机器上运行。                    

风险二：tools/check 会把 Claude Code 安装进它构建的镜像（扫描器也这么做）。Claude Code 受其自身条款约束。

+  + +这两条提示的实际含义是：工具链本身引入了供应链信任假设。在本地校验一个不受信任的项目，等同于执行一段不受信任的构建脚本。对企业环境而言，建议在隔离的一次性沙箱（而非开发机）中执行校验。 + +7.5 +   +披露政策的模糊地带 + +OSS Scanner 的披露政策是「不设披露期、不主动公开」，但它与 Anthropic 既有的 CVD 政策存在交叠，构成了一个需要仔细辨析的地带。三种模式的时间线对比如下： + +![](https://mmbiz.qpic.cn/mmbiz_png/8SYXzUAIerRibXW2EbWZPM389SPZXBDkDqpTfVL6uKzJ3yAB4XYLWv6iaRBBadOsSibDd9k777EDBxCZCVRIRqKerpXyn3Nf5q6f84qu4RfqDI/640?wx_fmt=png "") + +图 11 +   +披露时间线的三种模式对照（天数） + +关键在于理解「触发条件」而非「时长」： + +● OSS Scanner 报告（未人工验证）：不设披露期，不公开。 + +● 若同一问题后来被 Anthropic 通过 CVD 程序人工验证：从「通知维护者该报告已被人工验证」之日起，回归标准 90 天披露窗口。 + +● 官方保留未来对某些高危报告施加披露期的权利。 + +这意味着：一条报告是否最终会被公开，取决于它事后是否被人工验证。对维护者而言，披露义务因此变得不完全可预测。这是一个需要行业持续观察的制度设计问题。 + + +8 +   +行业影响与竞争格局 + +8.1 +   +对开源维护者生态的冲击 + +OSS Scanner 揭示了一个结构性矛盾：AI 让「发现」变得廉价，却没有让「修复」变得更容易。而开源维护者的时间与精力，恰恰是最难以规模化的资源。 + +这可能产生几种后果： + +● 负担集中化：关键基础设施项目（如 curl、OpenSSL）本就承载巨大压力，AI 扫描会在短期内进一步放大其工作量。 + +● 筛选能力成为核心技能：维护者需要快速从大量报告中辨别出真正重要的几条，这本身是一项需要经验的能力。 + +● 支撑侧的响应：官方已与 Open Source Security Foundation 的 Alpha-Omega 项目合作，支持其帮助维护者处理与分诊缺陷报告的努力。这承认了「发现只是开始」。 + +8.2 +   +与商业 SCA / ASPM 厂商的关系 + +一个自然的疑问是：OSS Scanner 是否会冲击商业安全厂商？本报告的判断是：短期冲击有限，长期将重构部分价值链。 +

能力环节

是否被替代

原因

依赖组件的已知漏洞告警

否

OSS Scanner 不做组件版本比对，这是 SCA 的专长

源码级逻辑缺陷发现

部分

AI 扫描在此具备明显优势，可能挤压部分人工审计与部分静态分析工具的市场

可利用性判定与 PoC

部分

AI 可生成可利用性判断与复现器，对传统渗透测试的入门环节形成替代

修复方案与工程落地

否

仍高度依赖人工理解与工程判断

合规与审计证据链

否

监管合规要求可溯源、可追责的证据，AI 生成报告在此不占优势

+表 8-1 +   +OSS Scanner 对各能力环节的影响评估 + +8.3 +   +对甲方安全团队的行动建议 + +对于企业安全团队，本报告给出四条务实建议： + +● 不要把 OSS Scanner 当作 SCA 的替代：两者面向不同问题域，应当并行部署，并用统一的风险台账收敛结果。 + +● 在隔离环境中试用工具链：若计划本地跑 tools/check，务必在一次性沙箱中进行，不要在生产或开发机上执行不受信任项目的构建。 + +● 关注「修复侧」自动化：既然发现已变得廉价，投入应更多转向「自动分诊 + 自动补丁验证 + 回归测试」这一侧的能力建设。 + +● 建立 AI 报告的可信度分级：来自 AI 的报告与来自人工确认的报告，应使用不同的处理 SLA 与信任等级，避免把未确认的发现直接当作已确认漏洞跟踪。 + + +9 +   +结论与展望 + +9.1 +   +十点结论 + +01 +   +定位｜ +OSS Scanner 是 Project Glasswing 能力向开源生态的产品化外溢，以免费、opt-in 的形式提供服务，准入标准对标 OSS-Fuzz。 + +02 +   +技术核心｜ +其真正的技术价值在于「两阶段离线审计」架构——有网构建、断网审计，兼顾了安全隔离与结果可复现。 + +03 +   +配置门槛｜ +接入成本极低：一个 project.yaml + 一个 Dockerfile；threat_model.md 是提升结果质量的关键杠杆，建议视为必填。 + +04 +   +设计取舍｜ +「不做人工复核」是刻意的权衡结果，换来扫描频率与覆盖面，代价是误报风险由维护者承担。 + +05 +   +真实瓶颈｜ +漏斗数据（29,439 → 584）清晰揭示了真正的瓶颈：不是发现，而是验证与修复。评审覆盖率仅约 21%。 + +06 +   +效果证据｜ +88% 抽样通过率与维护者的正面反馈构成了质量支撑，但样本量为 97 条，且为官方挑选的正例，不宜过度外推。 + +07 +   +已知缺陷｜ +严重性评级偏高是反复出现的反馈（Glasswing 阶段高危确认率 62.4% 亦印证）。threat_model.md 是目前最低成本的缓解手段。 + +08 +   +成本量级｜ +独立实测显示单项目扫描成本在数美元、耗时在分钟级别，经济性较传统人工审计有数量级优势。 + +09 +   +治理风险｜ +无披露期 + 模型生成 + 不可溯源的组合，使责任边界模糊；工具链本身亦引入了供应链信任假设。 + +10 +   +长期关键｜ +该服务的生态价值取决于「修复侧」能否同步提速；否则只会把发现过快的问题转化为维护者的负担。 + +9.2 +   +关键分歧与待观察指标 + +本报告认为，以下四个问题尚未有定论，值得持续观察： +

待观察问题

观察指标

为何重要

误报的实际负担有多大？

维护者公开的误报率反馈；社区对 AI 报告态度的变化

决定「无人工复核」模式能否长期成立

修复侧能否跟上？

漏斗中「已修补」环节的增速；平均修复时长变化

决定该服务最终是净增益还是净负担

披露政策会否收紧？

官方对高危报告施加披露期的实际动作

影响维护者的合规义务与可预测性

能力会否外溢扩散？

其他模型厂商是否推出类似服务；开源替代方案的出现

决定这是 Anthropic 的独家优势还是行业基线

+表 9-1 +   +待观察的关键问题与指标 + +最后需要强调的是：OSS Scanner 的意义已经超出了它本身。无论这个具体服务最终如何演进，它都验证了一个不可逆的趋势——AI 已经能够以可接受的成本，在真实世界的代码库中发现高质量的原创缺陷。对防御方而言，问题不再是「这件事会不会发生」，而是「我们准备好了吗」。 + +10 +   +附录 + +附录 A +   +关键数据引用溯源表 + +为便于复核，下表列出本报告引用的关键数据及其来源。 +

数据点

数值

来源

CyberGym 基准能力跃升

< 20% → > 85%

Anthropic 公告（2026-10-08）

候选漏洞总数

29,000+ / 29,439

公告概数 / 官方仪表盘

人工复核数量

约 6,000 / 6,123

公告 / 官方仪表盘

直发维护者报告数

近 5,000 / 6,157

公告 / 官方仪表盘（10-02）

88% 抽样验证

97 样本中 85 条达标

Anthropic 公告（2026-10-08）

Glasswing 高危漏洞

10,000+

Glasswing 更新（2026-05-22）

OSS 扫描总发现

23,019

Glasswing 更新（2026-05-22）

模型自评高危

6,202

Glasswing 更新（2026-05-22）

已完成独立评审

1,752

Glasswing 更新（2026-05-22）

确认真阳性率

90.6% / 62.4%

Glasswing 更新（2026-05-22）

CVE-2026-5194

CVSS 9.1 / Red Hat 评 10

Glasswing 更新 + 多来源交叉

仪表盘漏斗序列

29,439 → 584

red.anthropic.com 仪表盘（10-02）

公告截至日公告数

584 个

The Hacker News（2026-10-09）

仓库 PR 数量

116 个

The Hacker News（2026-10-09）

单项目实测成本

约 $4.43 / 55 步

rotecodefraktion.de（独立实测，N=1）

单项目构建校验耗时

约 3 分钟

rotecodefraktion.de（独立实测，N=1）

+表 A-1 +   +关键数据溯源表 + +附录 B +   +project.yaml 配置速查 +

# project.yaml 最小可用配置

repo: https://github.com/your/project      # 必填

primary_contact: security@your.org         # 必填

dockerfile: .oss-scanner/Dockerfile        # 条件必填

 

# 建议补充（提升扫描质量）

threat_model: .oss-scanner/threat_model.md # 强烈建议

 

# 可选

auto_ccs:

  - maintainer@your.org

homepage: https://your.org

disabled: false

 

# 加密报告（与 auto_ccs 互斥）

# pgp: |

#   -----BEGIN PGP PUBLIC KEY BLOCK-----

#   ...

#   -----END PGP PUBLIC KEY BLOCK-----

+代码 B-1 +   +project.yaml 配置速查 + +附录 C +   +术语表 +

术语

全称 / 释义

CVD

Coordinated Vulnerability Disclosure，协调漏洞披露

CVP

Cyber Verification Program，Anthropic 的网络安全能力验证计划

OSS-Fuzz

Google 发起的开源软件模糊测试计划，OSS Scanner 准入标准参考对象

SCA

Software Composition Analysis，软件成分分析

ASPM

Application Security Posture Management，应用安全态势管理

PoC

Proof of Concept，概念验证（可触发缺陷的最小示例）

bisection

二分定位，通过二分搜索确定缺陷首次引入的提交

self-contained reproducer

自包含复现器，不依赖外部条件即可触发缺陷的程序

opt-in

自愿加入（与 opt-out 默认加入相对）

GHSA

GitHub Security Advisory，GitHub 安全公告标识符

+表 C-1 +   +术语表 + +— 报告完 — + +本报告基于截至 2026-10-09 的公开信息编制，所引用数据均标注来源；厂商自述数据与第三方观察已分别标识。 +