2026-10-08，Anthropic 上线了 OSS Scanner。给开源项目免费做安全扫描，opt-in，灵感来自谷歌的 OSS-Fuzz。同一天发布的还有 Anthropic Cyber Mission。
值得留意的不是 AI 会找漏洞这件事，是公告里那句自述：输出完全由模型生成，没有人工审阅，也没有人工分类，原文 "fully model-generated, without human review or triage"。紧接着还补了一句——报告有可能是错的，也可能是无效的。
把没验过写进产品说明书，看着像自曝。放进工程语境看，它是一次接口契约的换轨。
签字成了瓶颈
过去六个月，扫出超过 29,000 个候选漏洞。能被人工审阅和分类的，约 6,000 个。剩下的没压着，近 5,000 份未验证报告已经直接发给了维护者——前提是维护者自己先说了全都要。
另外别把它和 Claude Security 混成一条线。后者是面向企业的通用代码扫描与修补产品，OSS Scanner 只对开源项目、只免费。
官方对瓶颈的交代很直接：卡在人工验证这些发现的能力上。模型不是不够准，是人不够快。
另一侧的时间刻度是原文那句 "exploits can now be developed in minutes"。攻击方按分钟计时，验证方按队列排期。等人工验完再发这套流程，本身就成了风险源。
比值摆出来之后只剩两条路：
- 卡住不签发，等人工排期。等不起。
- 不签字，把接收方验得动的材料一次性交齐。验证权移交。
Anthropic 选了第二条。
交付物的字段结构
这条路能不能成立，看报告里装了什么。官方给的清单是三样：一个可自足复现的复现器（self-contained reproducer）、一段漏洞解释（含用 bisection 定位这个 bug 是什么时候引入的，在可行的情况下）、一个候选补丁。
当成结构体看大概是这样：
finding_report
├─ reproducer # self-contained，不依赖扫描侧运行环境
├─ explanation # 成因；可行时附 bisection 结果
│ └─ introduced_at # 由哪次提交引入
├─ candidate_patch # 候选补丁，不是定稿
└─ provenance # 口径字段
├─ generator : model-only
├─ human_review : false
└─ sampled_hit_rate: { sampled: 97, passed_cvd: 85, sampler: "Anthropic 委托的外部渗透测试员" }
前三个字段提供输入，provenance 提供信任预算。没有它，接收方只能二选一：全信，或者全不信。
OpenSSL 的 Anton Arapov 给了个很硬的判据。18 个月前的早期 AI 报告被他评价为糟透了，这一次收到的报告，包括原始模型输出在内，和人写的一样好，有时更好。他的理由落在结构上：特别是当一份报告附带一个真实可用的利用代码时，对工程师来说基本就是活干完了，因为你可以立刻验证。
变化发生在哪？模型的措辞没什么魔法，是交付物里多了 reproducer。
provenance 里最容易写错的一项
官方公布的抽样表现是这样：请外部渗透测试专家复核 48 个项目的 97 个严重/高危漏洞，85 个达到 CVD 标准（88%）；剩下 12 个里 11 个是真实但重复的已知问题，仅 1 个是无效误报。wolfSSL 收到 74 份报告，除 2 份外全部有效，5 个最终成为 CVE。
这两个数字都不能写成经独立第三方验证。97 个的复核者是 Anthropic 自己请的、为它 CVD 流程做复核的渗透测试员；wolfSSL 那组出自项目方在官方页面上的反馈。它们的信息量是当事方公布的抽样表现，够用来估先验概率，不够用来替代本地复现。
落到 changelog 上，写法大概是这种：
来源 : Anthropic OSS Scanner (2026-10-08)
人工复核 : 无（官方明示 fully model-generated, without human review or triage）
抽样表现 : 97 → 85 达 CVD，11 重复已知，1 误报（当事方委托复核，非独立审计）
本机验证 : pending / owner / deadline
再说 bisection 这个字段。它的作用是把结论从是什么压到从什么时候开始是。边界写出来看着像示弱，其实是让结论可被推翻的前提。可证伪这条原则写在报告里，比写在论文里具体得多。
还有一个字段不能照抄：严重性评级。官方页面上留了维护者的反馈，评级可能被高估，威胁模型也可能被误读。这一栏在验收流程里是待重算的估计值，不是结论。
官方自己留的那段余地
页面上还写着三件事：继续通过 CVD 流程人工披露人工验证过的报告，尤其是自己没人力分拣的项目；有维护者反馈严重性评级可能被高估、扫描器可能误解项目的威胁模型；以及一句我们无法保证扫描器是完美的。
这段自曝不是公关话术，它是 sampled_hit_rate 的校验码。承认存在 1 例误报的 88%，比没交代抽样方法的 99% 更可用——前者允许你估算该投多少人力去验，后者只要求你信。
许教授曾这样描述人面对 AI 输出时的犹豫：
「你不会拿豆包的答案去给你的客户交付吧？会吗？不敢，不敢，对吧？没法验证——因为它是你免费白嫖来的。」
口径声明：该句素材覆盖时点为 2026-08-08，早于 2026-10-08 的 OSS Scanner 发布，其本人未就该事件公开发表意见。此处引用后的延展属框架推演，不代表本人对本案表态。
他卡住的地方不是准不准，是没法验。这批报告补的正是这个位置：不是让输出变得更客观——客观没法测量——是让它变得可复算。
换到你自己的流水线上
签字这个动作没消失，只是从信任的前提退化成了效率的包袱。产出速度超过签字速度时，这个退化就会发生，和是不是 AI 关系不大。
下次设计交付物，可以先把 provenance 那栏填上再看别的：生成器是谁、有没有人工复核、抽样过多少、抽样由谁执行、接收方本地怎么验。填不满的那几项，就是这份交付物眼下还没给到对方的东西。
