结论先行这个服务证明的不是「AI 会挖洞」而是「分诊才是瓶颈」——发现能力提上去之后工作量只是换了个地方。一、它是什么给出了什么数Anthropic 在 10 月 8 日上线 OSS Scanner免费、(opt-in)用自家最强的模型包括 Claude Mythos对已注册的开源代码库做定期审计。大致的形态可以类比 Google 的 OSS-Fuzz只是把模糊测试器换成了语言模型。关键运营数据据 Anthropic 公布口径与多家媒体转述项 数字 口径上线后 11 天 77 个严重级 803 个高危级发现 模型自评 severity非 CVE 评级 入选规模 114 个项目来自约 650 份申请截至 10 月 19 日 核心维护者提交 PR 注册需提供 Dockerfile 抽样复核 97 项严重/高危发现中 85 项88%达到协调漏洞披露门槛11 项与已知问题重复1 项为无效 Anthropic 请渗透测试员对 48 个项目做抽样 项目侧反馈 wolfSSL 收到 74 条报告其中 72 条有效产生了 5 个 CVE 项目方口径 已修复案例 curl 修复 CVE-2026-92392HTTP/2 上传的释放后重用High影响 8.12.0 至 8.22.08.23.0 修复10 月 14 日发布 curl 发布口径背景数字更值得看过去六个月里Anthropic 的模型产出超过 29,000 个候选漏洞人工审核员分诊了约 6,000 个另有近 5,000 份报告直接发给维护者。同期内部基准 CyberGym 上模型发现漏洞的比例从不足 20% 提升到超过 85%。二、为什么这样说这份服务的取舍写得很明白报告不经人工复核直接发给维护者。好处是快代价是把验证与定级的工作整体转移给了项目团队。抽样数据把这笔账摊开了88% 合规意味着每 100 条报告里有 12 条需要有人先去判断「这条要不要理」11% 的重复率意味着「这条我早就知道了」也要占一次工时。对一个由志愿者维护的项目来说这不是免费午餐这是实打实的分诊队列。所以这个产品真正解决的是发现端的产能没有解决验证端的产能。后者才是过去几年 AI 挖洞这条线上真正卡人的地方——单向能力的提升只会把瓶颈挤到下一个环节。三、用开源组件的团队该改三件事第一把「看到报告」从被动改成主动。依赖树里躺着 curl、wolfSSL 这类基础组件它们的 CVE 不会自动走到你的发布流程里。最低限度的动作是给制品仓库接上 SBOM 与 advisory 源做到上游公告当天能在依赖清单里被标红。第二给 severity 留一道自己的校准。模型自评的严重程度与现实可利用性之间是存在落差的本次抽样里约 11% 属于重复条目也有维护者反馈定级偏高。企业级做法是用自己的标尺——组件是否在出网面、是否处理外部输入、是否在默认放行的调用路径上——重排一次优先级。第三盯具体的修复版本号而不是每周摘要。本次 curl 的案例给了一个很好的样本影响范围是 8.12.0 至 8.22.0修复在 8.23.0。这类版本区间信息拿到手之后对照自家基线即可判断是否需要紧急发布不必等下游发行版的公告。四、一句话总结AI 把挖洞的边际成本压了下去接下来涨价的是 human-in-the-loop 的验证能力。谁先把自己的分诊流水线搭好谁才吃得到这波产能。把视角落到使用开源组件的团队这类基础组件通常不是自己引入的而是层层依赖带来的——以消息队列为例客户端与服务端依赖树往往比想象中更深一层镜像里能同时躺着三个版本的 TLS 库。这类工作在国内交付环境下还要顾虑另一件事基础镜像与依赖件要能在信创 CPU 架构与操作系统组合上重建输出结果要能留在内网审计系统里。金蝶天燕 Apusic 分布式消息队列 ADMQ 面对的是同一道题自研组件的依赖清单要交代得清楚上游公告进来之后要有明确的修复与验证窗口。能不能承接不看宣传口径看的是有没有把依赖树当成一张需要持续维护的表。留给你的一个具体问题你的依赖清单里curl / OpenSSL / wolfSSL 这些基础组件的当前版本是多少这个数字如果不能在十分钟内查出来接再多扫描器也只是多了一摞没人读的报告。