7 月 30 日，Google 在官方部落格交出 Chrome 的 AI 資安成績單：Chrome 149 與 150 兩個版本合計修復 1,072 個安全漏洞，超過此前 23 個版本修復量的總和。同一篇文章給出的時間線同樣醒目：5 月，整合進 CI 的工具攔下 20 多個尚未進入正式版的漏洞，其中包括一個 S1+ 級嚴重問題；3 月，外部漏洞回報量已超過 2025 全年，Google 為此調整了漏洞獎勵計畫（VRP）的規則。面對「漏洞暴增」的直觀擔憂，Google 的說法是：找到並修復的漏洞增加，不是失敗的跡象。
1,072 個漏洞：兩個版本超越過去 23 個版本的總和
先把數字放進脈絡。漏洞的「產量」取決於找出它的能力，而不只是程式碼的品質。當找漏洞的工具從人工審查換成 AI 代理，單位時間能掃過的程式碼面積完全不同，修復數自然爆發。Google 把這份成績單當健康指標來展示：管道裡流動的漏洞變多，代表過去沉默多年的缺陷終於進入可處理的佇列。真正的風險從來不是修太多，而是沒人找。
從模糊測試到 Big Sleep：找漏洞的 AI 工具鏈
這條工具鏈是三年疊出來的。2023 年是 AI 輔助模糊測試；2024 年 Project Zero 推出 Naptime，讓 LLM 像研究員一樣反覆嘗試觸發異常；2025 年與 DeepMind 合作的 Big Sleep 開始在 V8 與圖形堆疊裡挖出真實漏洞。2026 年初上線的 Gemini 代理工具鏈直接掃描整個 Chrome 程式庫，成果之一是一個存活超過 13 年的沙盒逃逸漏洞——這類「老、深、靜」的缺陷，正是傳統模糊測試最難碰到的角落。
AI 不只找漏洞，也開始修漏洞
修復端同樣變成多代理流程：一個修復代理寫修補，一個模仿程式碼審查的「批評者」代理挑毛病，還有代理專門補測試，Google 稱最多省下「數週的工程師時間」。前端的自動分診——過濾、重現、補中繼資料、路由——取代了每筆回報 5 到 30 分鐘以上的人工處理，每個月省下數百小時。找漏洞的能力升級之後，瓶頸本來就會移到修復與分診；這次 Google 把兩端一起自動化了。
護欄、節奏與記憶體安全
護欄方面，AI 只分析存放在磁碟上、未執行狀態的原始碼，過程在隔離機器上進行，網路請求被攔截並套用白名單，子代理不能修改系統、也不能離開指定目錄。發布節奏同步調整：大版本轉向兩週一發、安全更新每週一次，並試行一週兩次安全版；動態修補（不重啟就汰換背景程序）還在研究中，Chrome 150 已讓 macOS 上的無視窗背景程序自動重啟。記憶體安全則雙軌並行：MiraclePtr 與 MiracleObject 擴大覆蓋，目標是 GPU 主執行緒上最多 90% 的釋放後使用漏洞；97% 的第一方程式已能在嚴格的 unsafe-buffer 警告下編譯；高缺陷密度模組改用 Rust。生態系部分，Chrome 有超過 2,300 個第三方相依套件（約 1,700 個隨產品出貨），Google 捐給 Alpha-Omega 1,250 萬美元，並共同發起 Akrites 專案。
對開發者的啟示
四件事。第一，把「AI 找到大量漏洞」當成常態而非危機，預算要留給複審與修復，而不是留給否認。第二，真正省時間的地方在分診與測試自動化，不在找漏洞本身——每筆回報 5 到 30 分鐘的人工成本才是大頭。第三，相依套件就是攻擊面：Chrome 的 1,700 個出貨相依套件，適用於任何大型專案的供應鏈風險評估。第四，兩週版本加每週安全更新的節奏，代表升級測試得做成持續流程，而不是季度任務。
參考來源
- Chrome, stronger with every update — Google
- Using Large Language Models to Catch Vulnerabilities — Google Project Zero
本文由 AI 協助自上述來源整理，經人工審核後發布。