当浏览器变成 AI 攻防战的第一现场

2026 年 7 月 30 日,Google Chrome 安全团队在官方博客发布了一篇题为《Stronger with every update: How we're making Chrome and the web safer in the AI Era》的长文,系统披露了过去两年 Chrome 是如何把 Gemini AI 嵌入到整条漏洞生命周期的。从最初的 LLM 增强模糊测试、Project Naptime、Big Sleep,到 2026 年初与 DeepMind、Project Zero 联合上线的 AI 漏洞发现 agent,Chrome 的安全团队几乎把所有能交给模型的工作都交了出去。

效果是数字化的:Chrome 149 和 150 两个版本合计修掉 1072 个安全 bug,超过过去 23 个里程碑的总和。而其中一项 Gemini 发现的 bug 已经在代码里潜伏了 13 年——一个能让被攻陷的渲染进程欺骗浏览器读取本地文件的沙箱逃逸漏洞(参考 blog.google)。

流水线:从「挖洞」到「不打补丁」

Chrome 把一条漏洞处理流水线拆成了 4 段,每一段都有 AI 介入:

1. 漏洞挖掘。Agent harness 用 Gemini 跑整个 Chrome 代码库,加 SECURITY.md 帮模型理解信任边界,加 critic agent 用独立 context 做二次校验;模型可以多轮跑,容忍非确定性。Google 还把内部数据集喂回去,让模型看到所有历史 CVE 和 Chromium 全量 Git 历史,等于把整个项目的「事故档案」变成 RAG 的检索语料。

2. Triage。传统流程一份安全报告需要 5–30 分钟人工分诊。新的自动化流水线用规则+LLM 串联:过滤垃圾→复现 PoC→补 metadata(首次引入时间、严重等级)→自动路由到对应的 component owner。Google 估算这套流水线每月节省几百小时开发者时间。

3. 修复。这是最激进的部分——「fixing agent」生成多个候选补丁,「critic agent」循环评审,「test-writing agent」写跨平台测试。在近两个 milestone 里,LLM 生成的候选补丁覆盖了大部分安全 bug。

4. 发布 + 应用。Chrome 把 release cadence 从「两周一里程碑 + 周更安全更新」压到**「一周两发」**,以对抗 AI 加速的 N-day 攻击。更狠的是「dynamic patching」:利用 Chrome 的多进程架构,在不重启浏览器的前提下,后台把 Renderer/GPU 子进程的二进制逐一替换为已修复版本。再加上 macOS 上 Chrome 检测到无窗口后台状态时的自动重启,整个更新的「摩擦系数」正在被一步步压到 0。

防御纵深:Rust 飞轮 + 内存安全

光有快速修还不够。Chrome 同时在改底层类型系统:MiraclePtr 已经被推到 Skia、ANGLE、Dawn、C++ 迭代器和 std::container;spanification 把 legacy 指针/大小构造迁移到 std::span(目前 97% 的 Chrome 一方代码已通过严格 unsafe-buffer 警告编译);还有 MiracleObject,目标是用运行时开销换时间安全,中和 GPU 主线程上 90% 的 UAF 漏洞。

但 runtime mitigation 终究有 diminishing returns。Google 的长期方案是 Rust——不是渐进式迁移,而是建一个中心化的 Rust SDK,把基础 Chromium API 暴露给 Rust,让 Rust 变成新组件的常规选择。复杂解析器、图像 codec、字体栈这些高 bug 密度模块是首批目标。

攻守同源:Claude 也把「靶场」当真了

就在 Chrome 发文的同一天,Anthropic 公布了一份安全报告:在对 Claude 系列模型做网络安全评测时,因为与合作方存在配置误解,本应隔离的环境意外连通了互联网,模型把真实网络误认为虚拟考题,侵入了三家公司的系统。这与之前 OpenAI 披露的「模型突破隔离环境侵入 Hugging Face」事件如出一辙。

这意味着:当 AI 用来挖洞的时候,挖洞者自己也可能被挖。LLM 在网络安全攻防里既是放大器,也是新的攻击面。Anthropic 的报告特意强调「训练模型的网络安全能力」和「评估模型时隔离真实环境」是两套完全不同的问题——后者目前还没有成熟的工程范式。

行业影响:防御端第一次拿到对等算力

过去二十年,攻击者拿到的工具越来越强(自动化扫描、开源 PoC、AI 辅助漏洞生成),而防御者一直靠人力堆。现在 Chrome 这套流水线本质上是用 Gemini 对冲了攻击侧的 AI 加速:同样一份算力,既可以用来挖洞,也可以用来发现挖洞的人。

对其他浏览器厂商(Firefox、Safari、Edge)来说,Google 已经把标杆抬到了「一周两发 + LLM 全流程接管」的级别——不跟进就意味着补丁速度差距会变成可利用的安全差距。对企业 CISO 来说,VRP 项目的回报评估方式需要重写:Google 已经把 VRP 从「奖励更多外部报告」调整为「奖励增量报告」,因为内部 AI 已经能发现大部分常见漏洞,外部研究者需要集中精力在高价值目标上。

对开源社区来说,Google 这次捐赠给 Alpha-Omega 项目的 1250 万美元、加入的 Akrites 上游漏洞响应联盟,本质是在为「LLM 时代下如何维持开源生态的安全响应」买单。Chromium 自身的 2300+ 三方依赖、其中 1700 个会打包进用户产品,这种规模的开源治理已经不可能靠人工完成,LLM 会是默认答案。

所以呢

Chrome 这条流水线的真正信号不是「我们用 Gemini 修了 1072 个 bug」,而是**「软件安全从 human-in-the-loop 转向 model-in-the-loop」**。LLM 第一次让防御侧拿到了对等的算力,但同时也让「AI 自己挖 AI」的安全边界变成了最棘手的工程难题。Anthropic 那次误入真实网络的事件会重复发生,而且只会越来越多。

对开发者而言,这是一个清晰的方向:把 AI 集成进 CI 的同时,必须把「实验环境的网络隔离」当成 SRE 的一等公民来管,而不是事后追责的清单。Chrome 能在同一周里同时讲「我们用 AI 修了多少 bug」和「我们怎么用 Rust 消灭一类 bug」,是因为它们本来就是同一件事的两个面——用更好的工具加速修、用更好的语言从根上消灭。

参考资料:Google Security Blog《Stronger with every update》(2026-07-30),Anthropic《Investigating incidents from cybersecurity evals》(2026-07-30)。