摘要： Google 於 7 月 30 日說明 Chrome 149 與 150 共修復 1,072 個安全漏洞，超過前 23 個版本的累計量。文章把成果歸因於 AI 輔助模糊測試、Naptime、Big Sleep 與 Gemini 代理工具鏈，其中包括潛伏超過 13 年的沙盒逃逸漏洞。Google 也自動化分診與修補，並加強護欄、更新節奏與記憶體安全。
Google 於 7 月 30 日在官方部落格公布 Chrome 進入 AI 時代後的資安成績：149 與 150 兩版合計修掉 1,072 個安全漏洞，數字已高於此前 23 版的累計修復量。同篇文章列出的其他節點同樣有分量——5 月時，嵌進 CI 的工具趕在漏洞進正式版之前擋下 20 多個，其中一個被評為 S1+ 等級重大問題；到 3 月，來自外部的回報數量已超越 2025 年一整年，Google 因此修改漏洞獎勵計畫（VRP）規則。外界不免直覺地問「漏洞是否暴增」，Google 答得乾脆：被找出來並修掉的漏洞變多，不等於失敗。
兩版抵過先前 23 版：1,072 這個數字在說什麼
要看懂這個數字，得先明白它量的是「團隊能挖出多少問題」的能力，程式碼品質只是其中一項變數。搜尋一旦從人工審查交到 AI 代理手上，同樣時間窗內能掃過的程式碼規模就是另一個量級，修復量隨之放大並不意外。Google 把這樣的流量讀作健康指標：管線中待處理的漏洞變多，說明沉默多年的缺陷總算進了有人負責清空的佇列。真正的危險向來不是修得太多，而是根本沒人去找。
三年一步步疊出的工具鏈：從模糊測試到 Big Sleep
這條鏈前後用了三年才拼齊。2023 年先引進 AI 輔助的模糊測試；2024 年 Project Zero 端出 Naptime，做法是由 LLM 循研究員的路子反覆嘗試觸發異常；2025 年與 DeepMind 聯手打造的 Big Sleep，在 V8 與圖形堆疊接連挖出真實漏洞。2026 年初，以 Gemini 為核心的代理工具鏈開始運作，直接掃描整個 Chrome 程式庫——其中一項戰果是潛伏超過 13 年的沙盒逃逸漏洞。這類又老、又深、又安靜的缺陷，正是傳統模糊測試最難碰到的死角。
AI 不只負責找，也下場修
修補這一端改由多個代理分工：修補代理撰寫 patch，「批評者」代理模擬程式碼審查、專職挑錯，另有代理負責補測試——Google 說這套編制最多能省下「數週工程師工時」。往上游看，自動分診接手過濾、重現、補中繼資料與路由，過去每筆回報得耗掉 5 至 30 分鐘以上人工處理的部分由系統取代，一個月省下數百小時。發現能力往上跳一級，瓶頸理所當然轉到修復與分診；Google 這次在管道兩端同時導入自動化。
護欄、更新節奏與記憶體安全三線並進
護欄界線劃得清楚：AI 只能讀取磁碟上未執行的原始碼，分析一律在隔離機器完成，對外網路請求會被攔下並依白名單放行，子代理不得更動系統，也不准跨出指定目錄。發布節奏也調整：大版本改為兩週一次，安全更新維持每週一次，另試辦每週兩次的安全版本。不必重啟就能替換背景程序的動態修補仍在研究階段；Chrome 150 已讓 macOS 上無視窗的背景程序自行重啟。記憶體安全走雙軌：MiraclePtr 與 MiracleObject 持續擴大覆蓋，目標對準 GPU 主執行緒上最多 90% 的釋放後使用漏洞；第一方程式碼已有 97% 能在嚴格 unsafe-buffer 警告下編譯；缺陷密度偏高的模組轉向 Rust。生態系也納入檢視：Chrome 內含超過 2,300 個第三方相依（約 1,700 個隨產品出貨），Google 捐款 1,250 萬美元給 Alpha-Omega，並共同發起 Akrites 專案。
開發者能帶走的四件事
首先，「AI 挖出大量漏洞」該當成日常狀態而非危機，預算要編給複審與修復，不是花在否認上。其次，真正值得省時間的地方在分診與測試自動化，不在找漏洞本身——每筆回報那 5 至 30 分鐘的人工成本才是支出大宗。第三，相依套件本身就是攻擊面：Chrome 那 1,700 個隨產品出貨的相依，這套檢視角度可套用於任何大型專案的供應鏈風險評估。第四，兩週一版加每週安全更新，代表升級測試必須做成持續流程，不能一季才跑一次。