使用 AI 寻找授权漏洞
漏洞赏金计划正在发生变化。一些项目停止了奖励，另一些则削减了 80% 的赔付。原因并不是 AI 发现了太多漏洞，而是 AI 发现了太多“错误的漏洞”。审核团队正淹没在低质量的报告中。
在这种环境下，最重要的技能不再是寻找漏洞，而是证明漏洞并不存在。你必须找到正确的“负面结果”。
对于源码可见的目标，我使用一种两阶段法。
阶段 1：发散 (Fan-out)
使用廉价的 AI 模型来阅读代码。将目标拆分为细小的部分。要求模型寻找违反不变性的地方。寻找那些对象加载时没有进行所有者检查，或者安全门被跳过的位置。目标是高召回率。要预料会有很多错误。
阶段 2：对抗性验证 (Adversarial Verification)
使用昂贵的高推理模型来淘汰候选漏洞。假设每个候选漏洞都是错误的。只有当你能引用具体的代码行时，候选漏洞才能存活。你必须证明该路径是可达的，且没有其他检查会拦截它。
最有价值的产出是一份证伪清单。这份清单能建立起与审核人员之间的信任。
我测试了 Ory Kratos，一个开源身份服务器。我查看了设置流程。这个区域处理密码更改和电子邮件更新。这里的一个小错误就会导致账号接管。
第一阶段发现了一个诱人的漏洞。在 OIDC 策略中，某个特定的容器缺少身份绑定。如果你只寻找缺失的检查，你会将其报告为一个高危漏洞。
那会是一个错误。
缺失的绑定是不可利用的。系统通过活动的会话 Cookie 或签名令牌获取目标身份。容器特征永远不会应用于实际的写入目标。设计是稳固的。
报告这个会浪费时间并损害你的信誉。我提供的价值在于，我有信心不提交报告。
当我将同样的方法用于另一个目标时，我发现了一个真正的漏洞。一个备选入口点缺少了主路径强制执行的授权检查。一个被吊销的用户仍然可以通过“侧门”进入。这个漏洞影响巨大，且传统的扫描器无法发现。
把关人们正在筑起高墙来抵御海量的报告。想要成功，你的 AI 工作必须严谨。利用 AI 阅读比人类更多的代码。然后在点击提交之前，利用 AI 来证明自己是错的。
关注信号，而非数量。