AI 挖出 Chrome 漏洞后，代码安全流程该补哪 3 道门

六天，约 4 万美元模型计算，25 万美元奖励。

XBOW 昨天公开了一件挺硬的事。一位安全研究员和 AI 智能体一起做 Chrome 漏洞研究，最终拿到了 Google 今年首笔 25 万美元的全链奖励。官方公告称，Google 已复现、确认并发布修复，问题没有被用于攻击用户。

XBOW 官方公告主视觉，原图保留英文标题。

看新闻时最容易冒出的念头是，AI 已经会挖漏洞了，代码安全要失守了。

我更在意另一件事。模型把代码阅读、线索归纳和假设展开提速以后，团队最慢的地方，正在从发现问题，挪到确认、修复和交付。很多研发流程还停留在扫描器报一堆告警，人从里面挑几条看看的阶段。现在这条路会越来越不够用。

如果你的团队已经在用编码助手改 Bug、读 PR、升级依赖，别把这条新闻当成离自己很远的安全圈八卦。真正可以带走的，是把 AI 参与安全工作的入口，补成三道门。

第一扇门，先把授权范围写成机器也看得懂的话

安全工作最容易被一句“帮我看看有没有问题”带偏。

这句话对人已经够模糊了，对一个能连续调用工具、跨仓库检索、读取日志的 agent 更像一张空白支票。它会努力完成目标，却不会天然知道哪些代码、数据、环境和第三方服务不该碰。

所以第一件事不是挑更会推理的模型，而是给任务留一张范围单。允许研究的仓库、分支、依赖版本、测试环境、可访问的凭据类型，都要落成明确字段。生产环境、真实用户数据、未授权的外部资产，默认不在范围内。

这听起来像流程话，可它会直接影响工具怎么配。代码搜索能搜哪里，终端能跑什么命令，网络请求能去哪些域名，报告能发给谁，都应该从这张范围单里长出来。模型负责干活，权限边界不能靠模型临场猜。

Google 的 Chrome 漏洞奖励规则 把完整攻击链的最高奖励留给可验证、符合条件的研究结果。规则本身也提醒了一件朴素的事，研究能力和研究授权从来不是同一个问题。

对普通研发团队来说，可以先问三个很具体的问题。

• 这个 agent 只能读当前仓库，还是会顺手拿到整个公司的代码搜索权限
• 它是否会接触真实日志、客户附件或线上密钥
• 它发现可疑点以后，是否有明确的人和渠道接住，而不是自动继续扩大动作

能把这三句回答清楚，很多以后要靠事故复盘才能找回来的边界，今天就能先画上。

第二扇门，把模型结论变成可核验的证据包

模型很会给人一种已经找到问题的感觉。

它能引用文件，解释调用链，甚至把几个看上去普通的异常串成一个很完整的故事。可安全里最贵的错，不是漏掉一条猜测，而是把一条没核实的猜测当成高优先级事故，把工程师和产品团队全拉进错误的应急节奏。

XBOW 的公开材料里，研究员没有把模型输出直接当成结论。提交前还有 Google 的复现、确认和修复。人类专家做的那段验证，才让一串线索变成了能被平台接收的安全报告。

团队内部也该给 AI 的每个高风险结论配一份小证据包。它不需要写成厚厚的安全文档，至少要能说清四件事。

• 结论对应哪个提交、依赖版本或运行环境
• 模型基于哪些代码和日志做出判断
• 哪些影响已经在受控环境中被独立验证，哪些还只是推测
• 需要谁确认，确认后该进入修复、观察还是关闭

这四项里最容易被跳过的是第三项。大家赶着处理告警时，常常把“模型说得很像”误当成“事实已经成立”。把已验证和未验证分开写，会让讨论安静一点，也会让真正紧急的问题更快得到资源。

OpenAI 在一篇关于受治理安全研究的公开说明里，把持续推理、追踪组件关系、复现异常和判断影响列为真实漏洞研究的工作。读完反而更能看到模型的正确位置。它适合把可疑处翻出来，让人少在大代码库里摸黑，不适合替人跳过验证。

第三扇门，把修复速度当成新的安全指标

很多团队给 AI 上安全能力时，盯的是发现了多少问题。

这个数字很诱人，像日报里的战报。可模型一旦把候选问题翻得更快，告警数量很可能先涨。要是修复责任、测试资源和发布窗口没一起变快，最后只是把焦虑从安全同学的收件箱搬到了研发排期里。

更有用的指标，是从发现一个高可信问题，到完成修复、回归验证和受影响版本处理，需要多久。它不够酷，却能真实反映团队有没有接住 AI 带来的速度。

可以从一条很小的流水线开始。

模型生成候选问题后，自动补齐代码位置、受影响版本和证据引用。安全负责人做一次风险分级，明确是普通缺陷、需要加急的修复，还是仍待验证的线索。修复合并后，再安排一次针对性回归，并把结果回写到最初的报告里。

这里没有神秘武器，只有责任人、时间点和一份能回看的记录。可这正是多数团队现在缺的部分。扫描器、依赖告警和 AI 代码审查都能买到，能把结果稳定送到修复的人手里，才算真的提高了防护能力。

三道门不是拦住 AI，而是把它发现问题的速度送进可负责的研发流程。

别把这件事读成“模型替代安全工程师”

XBOW 的案例厉害，恰好是因为它没有这么简单。

公开说法里始终有一位研究员，有已授权的研究项目，有平台复现和补丁发布。模型参与的不是一场脱离规则的表演，而是一段被专家、范围和披露流程包住的工作。少掉任一段，新闻里的数字都没有意义。

对写业务代码的人，这也是个挺实际的提醒。以后 AI 在 PR 里指出安全隐患的频率会变高，安全团队给出的候选问题也会变多。你不必因此把每个 agent 都关掉，但该把“谁能让它查什么”“谁来证明这是真的”“修完后谁确认已经好”提前写清楚。

安全能力被模型拉快以后，最值得竞争的不是谁的告警更多，而是谁能更快地把一条经验证的问题送进修复，再平稳地送出发布。

如果让你给团队现有的 AI 代码流程补一扇门，你会先补授权范围、人工验证，还是修复交付？

小岛AI