AI 找漏洞已经不稀缺，验证才是下一堵墙

苹果的漏洞赏金通道，被 AI 生成的报告堵到开始限流了。

据 Financial Times 报道，苹果开始限制单个研究者能提交的报告数量，并设置 30 天冷却期。大量低质量、无法复现，甚至把不存在的问题写得像模像样的 AI 报告，正挤满审核队列。

然后荒诞的一幕来了。

意大利安全公司 Bynario 称，他们用 ChatGPT 找到一个可能让攻击者完全控制 macOS 机器的真实漏洞，却因为提交额度已经耗尽，一度没法把报告交进去。Bynario 首席执行官 Alfredo Pesoli 估计，这枚漏洞在黑市上值 10 万到 20 万美元。苹果后来主动联系了他们。这些细节来自 The Decoder 对 FT 报道的转述，10 万到 20 万美元是 Bynario 的估算，不是苹果给出的赏金定价。

好家伙，模型把找漏洞的成本打下来了，也顺手把报告通道打成了 429。

这事最值得聊的，并不是苹果会不会再多招一批审核员。它把一个更大的工程问题提前摊在了桌面上，当机器能批量制造候选答案，谁来证明哪一个值得人类停下手里的活。

堵住队列的不是漏洞

苹果的漏洞赏金页面写得很明确，提交时要有完整技术说明和 PoC，也就是 proof of concept，能够证明问题真的存在、真的能触发。苹果还引入了 Target Flags，用更客观的方式确认漏洞是否可利用。

规则其实不缺。缺的是机器规模和人类规模突然错位了。

一个模型可以同时扫几百个仓库，把静态分析告警、模糊测试崩溃、依赖版本差异和可疑调用链都包装成报告。每条报告只要看起来有七分像真的，接收方就得花时间搭环境、找版本、跑脚本、读日志，再判断它究竟是漏洞、重复项、配置错误，还是模型把一个正常分支脑补成了攻击链。

生成一条报告可能只要几分钟，证伪它却可能要半天。

不是哥们，这个账怎么算都不对。

很多做 agent 的朋友应该很熟悉这种局面。让模型提方案不难，让它一次吐二十个方案更不难。真正吃时间的是后面那串脏活，检查依赖能不能装、命令能不能复跑、测试是不是偷改了环境、结果是不是只在同一份上下文里自洽。安全报告只是把这类成本放大了，因为一条假阳性不只浪费 token，还会占掉真正漏洞的排队位置。

苹果这次遇到的不是简单的信息过载，而是低成本生成撞上高成本验收。入口不做背压，队列一定会爆。入口只做粗暴限流，真货又可能跟垃圾一起被挡在门外。

两头都疼。

三组数字，一条越来越窄的漏斗

VulnCheck 的 2026 年上半年报告给了另一组很扎眼的数据。他们汇总出 1,061 个归因于 AI 辅助发现的漏洞，确认已经在真实攻击中被利用的有 14 个，占 1.3%。这个比例与同期全部漏洞的确认利用率大致相当。

这里别急着得出「另外 1,047 个都是垃圾」这种结论。漏洞没有被观察到真实利用，不等于漏洞无效，更不等于不用修。公开后的利用证据也可能晚几个月才出现。

但这组数至少戳破了一个幻觉，发现数量不能直接替代风险优先级。

VulnCheck 还统计到，2026 年上半年有 495 个漏洞进入已知被利用范围，23.43% 在 CVE 发布当天或之前就已经出现利用证据。CVE 可以理解成漏洞的公开身份证。更麻烦的是，从 CVE 发布到确认被利用的中位时间，已经从 2025 年的 120 天缩到 80 天。

总量在涨，真正危险的窗口也在收紧。

AI 能放大发现量，但真实风险仍需要利用证据来排序

再看 Anthropic 的 Project Glasswing。Anthropic 在项目首轮更新里披露，Mythos Preview 扫描了 1,000 多个开源项目，得到 23,019 个发现，其中 6,202 个被模型估为高危或严重。六家独立安全研究机构已经仔细评估 1,752 个，确认 1,587 个是真阳性，最终确认 1,094 个达到高危或严重级别。

这个真阳性率其实很能打，厉害了。

可它同样说明，模型扫完不是结束，反而是昂贵部分的开始。23,019 条发现要穿过独立评估、协调披露、CVE 登记、补丁设计、回归测试和部署，每过一层，数量都在变少，人力密度都在变高。Anthropic 自己在那篇更新里也承认，进度过去受限于发现速度，现在受限于验证、披露和修补速度。

VulnCheck 对公开数据的后续追踪更狠。他们称，Project Glasswing 的发现中有 126 个形成公开 CVE，只有 1 个确认在真实环境被利用。这个口径来自 VulnCheck，不是 Anthropic 的官方转述，所以不能拿它去否定前面的真阳性率。两组数字回答的是两件事，一个问题是不是真的存在，另一个问题是它有没有走到公开编号并被攻击者实际使用。

来源为 Anthropic 公布的 Project Glasswing 首轮评估数据

你想想看，模型负责的那一头已经开始用万做单位，后面的审核、披露和修补还在按人头排班。漏斗最窄的地方，自然会变成整个系统的吞吐量。

发现模型不能给自己签字

很多团队看到这里，第一反应可能是再挂一个强模型做 reviewer。

方向没错，做法很容易翻车。

如果发现模型和验证模型读的是同一份描述、沿着同一条推理链、共享同样的盲点，第二个模型往往只是把第一个模型的话重新说得更像真的。它不是独立验证，更像同一个人在群里换头像给自己点赞。

安全流水线里，验证 agent 至少要换一种证据来源。发现 agent 说这里有越界读取，验证 agent 就不该继续写一篇语言更漂亮的解释，而要拿到指定版本，运行最小复现，保存崩溃产物，检查受影响地址范围，再做一个负向对照。把补丁或配置改掉以后，同一套脚本应当不再触发。

证据要从文字里长出来。

这也是 Anthropic 公开披露台账的价值。台账不是把模型生成的描述直接贴出来，而是先让外部安全研究机构验证，再对密封报告做哈希承诺。哈希可以理解成报告的数字指纹，它证明某份内容在那个时间点已经存在，同时不用在修复前公开攻击细节。

这个设计有点子牛逼的地方，不是用了什么高深模型，而是把「我发现了」和「有人独立确认了」拆成了两个责任主体。

做普通代码 agent 也一样。生成实现的 agent 不该是唯一验收人。至少要有确定性的编译、测试、类型检查、静态扫描和基准线。模型 reviewer 可以补盲区，却不能代替那些会明确返回 0 或 1 的闸门。

坦率讲，我自己的判断是，未来最值钱的 agent 不一定最会想，而是最会在正确的位置说「证据不够，先别进队列」。

让机器先过六道门

如果你正在做安全扫描、代码审查或者任何会批量生成告警的 agent，可以直接借这次事故改一下入口协议。

第一道门是版本。报告必须写清产品版本、提交哈希、操作系统和依赖环境。只写「最新版可能受影响」，直接退回。环境不确定，后面所有复现都是薛定谔的漏洞。

第二道门是最小复现。不是贴五屏模型推理，而是一段能运行的脚本、一条命令，或者最小输入样本。Apple Security Bounty 要求 PoC，不是形式主义，它是在压缩审核者的上下文切换成本。

第三道门是稳定性。同一个环境跑十次，成功几次，失败几次，超时几次。偶发崩溃可以是真的，但报告必须诚实交代概率。只截一次漂亮日志，谁都不知道它是发现还是抽卡。

第四道门是负向对照。换到未受影响版本是否消失，删掉关键输入是否不再触发，补丁后是否通过。没有负向对照，模型很容易把环境噪声认成因果关系。

第五道门是去重。对调用栈、触发路径、受影响组件和补丁位置做指纹，不只对标题做相似度。十份标题不同、根因相同的报告，不该占十个工单。

第六道门才是风险。把是否公网暴露、是否需要登录、利用复杂度、影响权限、是否已有攻击证据分开记录。VulnCheck 的数据提醒得很直接，发现数量和真实利用之间隔着很远，安全团队不能按报告声量排班。

这六道门最好大部分由机器执行，而且返回结构化结果。通过才进人工队列，失败就带着缺失字段退回生成端补证据。人类不该替模型整理作业格式，更不该从一篇三千字的推理里猜哪一行能复现。

怎么说呢，agent 时代的好接口，往往不是让模型更自由，而是让它更难把半成品伪装成完成品。

别再奖励报告数量

系统会长成指标奖励的样子。

如果安全产品的首页只展示本周发现 12,000 个问题，模型就会努力把一个根因拆成十二种说法。如果团队 KPI 是每月提交多少报告，验证成本就会被悄悄转嫁给下游。到头来看板一片繁荣，审核队列红得像线上事故。

更靠谱的指标应该换一组。有效报告率、独立复现成功率、重复率、从提交到首次复现的时间、从确认到补丁上线的时间、每个有效漏洞消耗的审核小时数。再狠一点，把被退回后仍重复提交的成本也算进生成端。

这话听着有点刺耳，但没有验收成本的发现数量，大概率只是库存，不是产出。

苹果的 30 天冷却期是一种很粗的背压。它能暂时保住审核队列，却可能让真正重要的报告一起等在门外。更好的系统不是无限收件，也不是一刀切限额，而是让高质量证据自动获得更高优先级，让历史有效率高的提交者拿到更大带宽，让只有一段模型描述的报告连队列号都领不到。

模型会继续变强，找漏洞也会继续变便宜。这个方向没有悬念。

真正决定安全有没有变好的，是发现之后那条窄路能不能拓宽。复现、去重、排序、披露、修补、部署，每一步都得有证据，每一步都得有人或确定性系统敢签字。

否则再多一个会找漏洞的 agent，也只是往已经满了的收件箱里，多塞一封看起来很专业的邮件。