LLM 把漏洞发现速度提到了架构撑不住的程度

Google Chrome 安全团队在最新博客《Stronger with every update》中坦率承认了一件过去很少听头部厂商主动讲的事:LLM 把漏洞发现的规模推到了传统修补流程撑不住的程度,正在倒逼浏览器从「打了补丁请用户重启」走向「不重启也能热替换」。

直接看数据:Chrome 149 和 150 两个里程碑修掉的 1072 个安全 bug,已经超过前 23 个里程碑修掉的 bug 总和。Google 在 2026 年 3 月单月收到的外部漏洞报告,比 2025 年全年加起来还多——而这还是在他们已经用 Big Sleep、CodeMender 等 AI Agent 主动挖掘漏洞之前。

Patch Gap:补丁到用户之间的危险窗口

这里面藏着一个业内很少公开讨论的安全指标:patch gap(补丁间隙)。漏洞被修复并不等于漏洞被堵住——从修复 commit 合并到 Chrome Stable 渠道,通常需要数周时间。在这两周里,任何能看到 Chromium 公开仓库的人——也就是攻击者——都能反向工程出新 commit,赶在大部分用户重启前利用它。这就是所谓的 N-day 攻击窗口。

过去业内对 patch gap 的容忍度建立在漏洞产出节奏慢的前提上——一周发现十个 bug,慢慢补也没事。LLM 把这个前提直接打穿:漏洞挖掘的吞吐量从「人」的速度切换到了「算力」的速度,留给防守方反应的时间窗口被极度压缩。

Chrome 的应对是三步并行:

  1. 把检测节奏从两周一次主版本升级到一周两次安全发布,目前正在试点一周两次安全 release。
  2. 引入动态补丁(dynamic patching),让浏览器在不重启的情况下热替换后台子进程(Renderer、GPU 等)的二进制文件。
  3. 利用 macOS 应用在窗口关闭后仍在后台运行的特性,在「零窗口」这种用户感知最小的时机自动重启应用。

动态补丁在工程上为什么难做

热替换浏览器子进程这件事听起来简单,但在 Chromium 这种多进程架构里有几道硬骨头:

  • 进程隔离:Renderer、GPU、Browser、Network 等进程是独立沙箱,任何热替换不能破坏现有的 sandbox 边界,否则补丁过程本身变成新的攻击面。
  • 状态保持:Renderer 进程里持有当前页面的 DOM、JS heap、布局树,简单 kill 重启会丢页面状态。动态补丁必须做到二进制替换后用户感知的页面继续运行。
  • 版本兼容性:补丁通常只替换几百 KB 的二进制差分,需要确保被替换的进程持有的共享库、IPC 协议版本与新二进制对齐。
  • 失败回滚:如果热替换过程中新二进制 crash 或 hang,必须能立刻回退到老版本,不能把用户锁死在半更新状态。

Google 给出的方案是**「顺序替换」**:利用 Chrome 现有的多进程模型,GPU 进程被 patch,Renderer 进程接着被 patch,新页面用新二进制渲染,旧页面继续用旧二进制直至关闭。整套过程对用户透明——不需要重启浏览器、不丢标签页、不需要重新登录。

Chrome 150 已经在 macOS 上做了类似的事:浏览器在零窗口状态下检测到待更新,自动触发重启,下一次打开时已经是新版本。这种「opportune restart」(机会主义式重启)的思路是动态补丁的过渡形态——先把最容易的时机抓出来,再做真正的热替换。

不只是 Chrome 的问题,而是 LLM 时代的防御栈重构

把视角拉远一点,Chrome 的故事其实是 LLM 时代整个防御栈被倒逼重写的缩影。

漏洞挖掘侧:Google 的三阶段演进值得注意——2023 年用 LLM 增强 fuzzing 覆盖率,2024 年和 Project Zero 合作 Naptime 给 LLM 漏洞研究工具,2025 年和 DeepMind 合作 Big Sleep 做出能自主挖 V8 引擎 bug 的 Agent,2026 年初把 Agent harness 部署到整个 Chromium 代码库。三年的演进路径清晰:从「LLM 帮忙做更好的 fuzzing」到「LLM 自己当研究员」。OpenAI、Anthropic 走的是类似的路径,Anthropic 前两天刚披露 Claude 在网络安全评测里误把仿真靶场当真网络,反向了三家真实机构的系统——LLM 已经能自主发现并尝试利用漏洞。

Triage 侧:Chrome 把原来 5-30 分钟的人工 triage 拆成四阶段自动化流水线(过滤垃圾、复现、补充元数据、自动派单),估计每月节省几百小时。fixing agent + critic agent 的多 Agent 代码评审模式,把「修 bug」本身也流水线化。

修复节奏侧:从两周一次主版本、一周一次安全更新,加速到试点一周两次安全 release。下一步是动态补丁让用户在浏览器开着的时候就能拿到修复。

留给我们的几个问题

Chrome 这一轮披露最值得关注的不是某个具体功能,而是承认了一件过去没人愿意公开讲的事:当漏洞发现的成本被 LLM 打到接近零,补丁交付的瓶颈就变成了 UX 边界——也就是「用户愿不愿意重启浏览器」这件事。传统软件安全的整套假设(发现慢、修复慢、用户有耐心打补丁)在 LLM 时代开始失效。

未来一两年我们大概率会看到:

  • 操作系统级别的热补丁成为标配,不只是浏览器——Linux 内核、Windows Server、macOS 都在朝这个方向走。
  • 「patch gap」会变成新的安全指标被公开追踪,就像现在大家盯着 CVE 数量和 MTTR 一样。
  • 防御侧 AI Agent 的能力上限会决定头部厂商的安全护城河——这是 Google、Microsoft、Anthropic 都在重金投入的方向。
  • N-day 攻击的时间窗口会进一步压缩,留给蓝队的反应时间从「天」变成「小时」,安全运营的值班节奏会被重写。

LLM 既是最强的攻击放大器,也是最强的工业级防御工具。Chrome 这篇博客把这件事讲得很明白:谁能先用 AI 把整条流水线跑通,谁就拿到了新一轮安全竞赛的入场券。