Mythos 之后：为什么漏洞赏金现在需要更硬的证据

几周前，我写过 Anthropic Mythos 和 Project Glasswing。当时重点主要是大方向：如果模型真的更擅长发现旧漏洞、组合 exploit 路径，并理解整个 codebase，那么 vulnerability research 就会改变。

Sophos 关于 Mythos 时代漏洞赏金的新文章，现在展示了这件事的运营层面。

问题不再只是 AI 是否能找到更好的漏洞。问题是漏洞赏金项目、security 团队和 engineering 组织，是否还能足够快地区分垃圾内容、听起来合理的说法，以及真实的安全问题。

真正的问题不只是 AI slop

谈到 AI 和漏洞赏金，人们现在很容易想到 slop：自动生成的报告、只理解了一半的错误信息、编造的 exploit 链、无法复现的说法，以及大量没有多少实质的文字。

这是真实存在的。对 maintainer、product security 团队和做 triage 的人来说，也非常烦人。

但这只是其中一面。

另一面更危险：优秀研究人员可以用同样的模型更快地发现真实漏洞，在更大的 codebase 上测试假设，并系统性地遍历一个模式的各种变体。过去需要几天甚至几周手工完成的工作，以后可能几小时内就进入队列。

于是问题发生了变化。过去常见的问题是：我们是否获得了足够多的高质量外部 findings？现在更像是：在噪声同时增加的情况下，我们是否能足够快地识别、验证、排序，并把真实 findings 转化为 fixes？

为什么 Sophos 是一个有意思的来源

Sophos 的文章不是一篇泛泛而谈的 AI 评论。Sophos 回顾了自己的漏洞赏金项目，并给出了具体数字。

根据 Sophos 的说法，其公开项目自 2017 年 12 月起在 Bugcrowd 上运行。Sophos 写道，截至文章发布时，已有 1,343 个漏洞获得奖励，总提交量为 7,091，累计支付 599,695 美元。

对于 2025 年，Sophos 提到：

• 超过 52 份报告获得 59,400 美元支付
• 约 420 名研究人员参与
• Intercept X Endpoint 在特定条件下最高 80,000 美元
• Sophos Central 最高 50,000 美元
• Sophos Firewall 最高 50,000 美元
• 2025 年 Sophos Firewall 有 13 个有效 bug，总支付 21,500 美元
• 2025 年 Sophos Central 有 13 个有效 bug，总支付 11,650 美元

这些数字并不夸张，但正因为如此才有意思。它们展示了一个相对成熟的项目背后有多少筛选工作。数千次提交并不自动意味着数千个相关安全问题。而 AI 很可能不会让这个比例更轻松。

它会让事情变得更难。

可复现性会成为入场券

在我看来，最重要的后果很简单，但不舒服：没有清晰可复现性的 security report 会变得更不值钱。

不是因为 triage 团队懒。而是因为他们的时间会变得更紧张。

如果一份报告声称展示了 remote code execution、auth bypass 或关键数据泄露，它必须清楚证明：

• 哪个版本受影响
• 需要什么配置
• 攻击者需要什么权限
• 哪些步骤可以可复现地得到结果
• 哪些 logs、requests、traces 或 screenshots 支持这个说法
• 实际证明了什么 impact
• 推测和证据之间的边界在哪里

这听起来严格。确实严格。但如果 security 团队不想淹没在听起来合理的文本中，这就会成为必要条件。

AI 生成的报告在语言上可以非常有说服力。它可以引用代码、写得像 CVE，并伪装出整洁的结构。但这不代表它是真的。反过来，一份简短、干燥但带有良好 proof of concept 的报告，可能极其有价值。

新的货币不是措辞。新的货币是证据。

AI 会让 authorization bugs 变得特别麻烦

Sophos 文章里有一点我觉得特别贴近实践：AI 可以帮助把已经发现的 authorization bypass 扩展到更大的 scope 表面。

这很符合真实 SaaS 环境中的情况。Authorization 很少是一个单独开关。它存在于 roles、tenants、object IDs、subdomains、API versions、admin surfaces、mobile endpoints、legacy routes，以及迁移了一半的 features 中。

如果研究人员发现了一个模式，AI 可以帮助系统性地检查它的变体：

• 这个 bypass 只适用于一个 endpoint，还是整个 endpoint family？
• 它只在一个 tenant 内有效，还是可以跨 tenant？
• 同样的逻辑是否存在于旧 API 和新 API 中？
• admin 和 user roles 是否真的在所有地方都干净分离？
• 即使 UI 不会显示，一个 object 是否仍能通过直接 ID 加载？

正是在这里，AI 变得危险地有用。不是作为神奇的 hacker，而是作为无聊、广泛、系统性检查的加速器。

对于那些安全性高度依赖“没人有时间把所有无聊变体都测一遍”的组织来说，这不是好消息。

漏洞赏金不是 PR 邮箱

很多公司仍然半把漏洞赏金当作形象工程：我们有一个项目，所以我们开放、现代、重视 security。

这已经不够了。

漏洞赏金项目是一个生产系统。它需要清晰规则、良好 triage、技术复现、贴近产品、engineering 责任，以及与 incident response 的连接。否则，它只是一个公开邮箱，让外部研究人员、AI slop 和真实攻击者共用同一个入口。

Sophos 在文章中把两个不舒服的点放在一起：

第一：优秀研究人员有帮助。外部视角、不同思维方式和持续压力都很有价值。

第二：一个涉及金钱和信任的系统也可能被滥用。Sophos 提到 Pacific Rim、Asnarök 和 Personal Panda 相关经验，在这些案例中，主动 exploitation 和后续漏洞赏金报告之间的时间接近性至少提出了一些问题。Sophos 明确没有说每份此类报告都是恶意的。但运营层面的重点仍然存在：漏洞赏金项目不能天真地设计。

具体来说：

• Reports 应该与 telemetry 关联。
• 新 finding 也应能够触发回溯性的 threat hunts。
• Triage 必须知道是否已经看到类似 exploit 尝试。
• 研究人员声誉有帮助，但不能取代技术检查。
• Safe harbor 很重要，但不能取代滥用检测。

这就是冷静的现实：漏洞赏金是 Secure by Design 的一部分，而不是替代品。

更硬的证据也意味着更重的责任

这里存在一种不能轻描淡写的张力。

传统上，人们经常告诉研究人员：请足够早地停下。展示 bug，但不要深入太多。不要接触客户数据。不要 lateral movement。不要破坏性操作。

这是正确的。

与此同时，举证责任会上升。如果 AI 大量生成看似合理但错误的 reports，项目会要求更多 evidence。于是出现了一个困难问题：研究人员如何更强地证明 impact，同时不滑向危险行为？

答案不能是：“那就多做一点。” 答案必须变得更受控：

• 更清晰的 Rules of Engagement
• 专用 test environments
• 安全 reproduction paths
• 约定好的 impact proof 边界
• 更好的 sandbox 和 lab systems
• 自动化的 proof of concept replay

对大型厂商来说，这几乎会成为必需。既然认真支付高额 bounty，就应该有基础设施来干净、快速地验证 reports。

对较小项目来说，这更苦。他们会收到同样的 slop 浪潮，却没有同样的资源。也正因为如此，一些项目会减少付费 bug bounty，甚至完全关闭。不是因为他们不重视安全，而是因为运营项目本身变成了负担。

Admin 和 MSP 可以学到什么

有人可能会说：这只影响厂商和 Bugcrowd 项目。

我不这么认为。

同样的机制也会影响 MSP、内部 IT 团队和 security 负责人。任何需要评估外部或内部 findings 的地方，压力都会增加：

• Scanners 提供更多 findings。
• AI assistants 更有说服力地解释 findings。
• Developers 带来 AI-generated security notes。
• Customers 在了解上下文之前就询问 CVEs。
• Management 想知道风险是真实的，还是只是声音大。

实际答案不是忽略一切。答案是更硬的验证流程。

对我来说，至少包括这些问题：

1. 问题是否可复现？
2. 受影响 scope 是否清楚？
3. 是否存在现实的 attacker path？
4. Impact 是技术上证明的，还是只是声称的？
5. 是否有 logs 或 telemetry 可以显示 exploitation？
6. Fix 是 patch、configuration、workaround，还是只是临时补丁？
7. 是否需要回溯搜索，确认它是否已经被利用？

这听起来像更多工作。确实如此。但这比对每一份写得很好的报告都慌忙反应要好。

为什么这和 Mythos 很契合

对我来说，Mythos 的关键点从来不只是：“哇，一个模型找到了 bugs。”

关键点是：如果这些能力变得更真实，那么从发现、理解、复现到利用之间的时间会缩短。正是在这里，漏洞赏金项目会受到影响。它们位于 research、attack potential、engineering 和 responsibility 的交叉点。

Sophos 在自己的文章里也以类似方式表达：问题不是如何阻止 AI submissions。问题是当好的研究和噪声都能以机器速度产生时，如何保持 trust 和 signal。

对我来说，这是对问题最干净的总结。

不是每个组织都需要自己的大型漏洞赏金项目。但每个组织都需要更好的机制来检查技术主张。因为 security information 的洪水不会变小。它会变得更快、更吵，也写得更好。

我的判断

我认为 Sophos 这篇文章是 Mythos 的一个有意义 follow-up，因为它把讨论从模型室带到了运营室。

Mythos 是那个醒目的信号。Bug bounty triage 是工作台，在那里才能看出 security processes 是否跟得上。

我的观点很简单：

• 只收集更多 reports 的人会输。
• 要求可复现 evidence 的人会更好地排序。
• 把 bug bounty、telemetry、engineering 和 incident response 连接起来的人会反应更快。
• 只把 AI 理解为 text generator 的人低估了它对系统性 security work 的价值。
• 不过滤 AI slop 的人，会消耗本该解决真实问题的人的时间。

这听起来不如 frontier model 找到 zero-days 那么华丽。但正是在这里，决定了安全收益是到达 defenders，还是所有人都淹没在更多噪声里。

下次见，
Joe