Chrome 兩版修補 1,072 個安全問題：AI 找漏洞後，補丁速度也必須翻倍

編按：本文綜合整理自 Google Chrome Security Team 官方說明、NVD 漏洞資料庫、TechCrunch 與 WIRED 等公開資料，並加入 Siami 編輯部觀點與分析。

Google 公布一組足以改變瀏覽器資安節奏的數字：Chrome 149 與 Chrome 150 兩個版本，合計修補 1,072 個安全問題，數量超過此前 23 個主要版本的總和。

這不只是「Gemini 找到很多漏洞」的宣傳故事。真正的變化，是 AI 已被放進漏洞生命週期的每一站：找出可疑程式碼、重現攻擊、判定嚴重度、提出修補候選、撰寫測試，最後還迫使瀏覽器團隊重新思考更新頻率。

從找漏洞到補漏洞：AI 代理開始接管重複工作

Chrome 安全團隊表示，相關投入並非一夕形成。2023 年，團隊先把大型語言模型用於提高模糊測試的覆蓋率與效率；2024 年與 Project Zero 合作開發 Naptime，讓模型取得專門的漏洞研究工具；2025 年則與 Google DeepMind、Project Zero 推進 Big Sleep，鎖定 V8 JavaScript 引擎與圖形堆疊中的安全缺陷。

到了 2026 年初，Chrome 建立以 Gemini 為核心的代理框架，將掃描範圍擴展到更廣泛的程式碼庫。官方揭露，其中一個被找出的沙箱逃逸漏洞已潛伏超過 13 年；一旦渲染程序先遭攻陷，攻擊者可能藉此誘使瀏覽器讀取本機檔案。

這套系統不是單一聊天機器人讀完程式碼後直接改檔，而是由多個環節組成：

漏洞代理搭配開放權重與封閉模型，反覆掃描同一份程式碼。
知識庫納入歷史 CVE 與 Chrome 完整 Git 紀錄，補足模型訓練資料的時效落差。
SECURITY.md 用來描述信任邊界，協助模型判斷哪些行為真正構成安全問題。
修復代理一次提出多個候選方案，再由具有獨立上下文的批判代理評估。
測試代理先跨平台驗證，最後仍交由人類開發者審查。

Google 估計，自動分類流程每月可省下數百小時的開發工時。這項流程會先排除垃圾與重複通報，再重現概念驗證、補上堆疊追蹤、嚴重度與漏洞引入版本，最後把案件指派給正確的元件負責人。

1,072 個修補背後，真正瓶頸轉向「如何送到使用者手上」

Chrome 149 與 150 的 1,072 個安全修補，是最吸睛的成果；但這個數字也暴露新的工程問題：當發現速度提升數倍，分類、修補、測試和發布若沒有同步擴充，只會形成更長的漏洞待辦清單。

Chrome 團隊已把 DeepMind 與 Project Zero 的工具整合進持續整合系統，每 24 小時掃描一次所有變更。官方稱，光是 2026 年 5 月，這套機制就在程式碼進入正式環境前攔下超過 20 個漏洞，其中包含一個 S1+ 關鍵問題。

然而，修補程式寫好並不代表風險立即消失。修補進入公開原始碼後，攻擊者可能逆向分析差異，在穩定版到達使用者裝置前開發攻擊工具，形成所謂的「補丁落差」。

為縮短這段時間，Chrome 正進行幾項改變：

主要版本逐步改為每兩週發布一次。
安全更新維持每週節奏，並試行每週兩次安全發布。
研究動態替換 Renderer、GPU 等背景子程序，盡量免除完整重啟。
保存更多工作階段狀態，降低重啟對使用者工作的干擾。
在沒有開啟視窗等低干擾時機，自動完成重新啟動與更新套用。

數據解讀：修補數量暴增，不等於風險等比例下降

1,072 是修補數，不是 1,072 次已被利用的攻擊，也不是 1,072 個同等嚴重的零時差漏洞。大型軟體中的安全問題從低風險邏輯瑕疵到可遠端執行程式碼的漏洞都有，單一總數無法呈現風險分布。

這個數字也同時混合多種來源：內部 AI 掃描、外部研究人員通報、既有模糊測試，以及開發流程中提前攔截的問題。因而不能只用版本前後的修補總量，直接推論 AI 把 Chrome 變得安全多少。

較有意義的後續指標包括：

AI 找到的問題中，有多少經人工確認為有效漏洞？
自動產生的修補有多少被採用、回退或再次修正？
高風險漏洞從通報到穩定版發布，平均需要多少時間？
新版本是否因密集修補而增加崩潰或功能退化？
使用者實際重新啟動並套用更新的時間，是否真的縮短？

NVD 的 CVE-2026-11645 提供一個具體參照。該問題是 V8 的越界讀寫漏洞，影響 149.0.7827.103 以前版本，可能讓遠端攻擊者透過特製網頁在沙箱內執行任意程式碼；CISA 亦將它列入已知遭利用漏洞清單。這類有明確影響版本、攻擊條件與利用紀錄的資料，比單純的總修補量更能協助管理實際風險。

為什麼這件事重要

軟體資安正進入「發現能力過剩、交付能力不足」的新階段。過去安全團隊最怕找不到漏洞；當代理能每天掃描龐大程式庫後，新的瓶頸變成驗證品質、安排優先級、完成跨平台測試，並讓補丁真正抵達數十億台裝置。

Chrome 的案例尤其重要，因為 Chromium 不只影響 Chrome，也構成 Edge、Brave 與大量內嵌瀏覽器元件的基礎。上游修補節奏加快，企業 IT、瀏覽器供應商與應用程式封裝者都必須調整測試及部署流程。若組織仍以每月一次的節奏驗證瀏覽器版本，可能跟不上每週甚至每週兩次的安全發布。

另一方面，AI 防守與 AI 攻擊使用的是相近能力。防守方能快速尋找危險程式路徑，攻擊者也能更快閱讀公開修補差異、產生測試樣本並擴大掃描。這使「補丁落差」從維運細節升級成核心安全指標。

Google 對代理環境的限制同樣值得注意。官方表示，模型在沒有一般網路權限的鎖定環境中分析靜態原始碼，網路請求受攔截和白名單控制，子代理也不能任意讀取指定目錄以外的檔案。這顯示大型企業並未把自主代理直接丟進完整開發環境，而是以最小權限、隔離與人工審查包住效率提升。

社群質疑：成功數字之外，還缺哪些答案？

這項消息在 Hacker News 討論串引發大量回應。支持者認為，AI 最適合扮演專業人員的加速工具，而不是在沒有監督下取代整個工程流程；漏洞搜尋、依賴追蹤、測試產生與小型重構，都屬於較容易驗證的應用。

質疑者則集中在官方未揭露的品質數據：自動修補有多少遭到回退、代理誤報率多高、又有多少修補反而引入新缺陷。也有人追問，若軟體開發本身大量採用生成式 AI，新增漏洞與修補漏洞是否可能同時上升。

這些問題不否定 AI 輔助資安的價值，卻提醒讀者：漏洞修補總數是產能指標，不是完整的安全成績單。若 Google 未來能持續公布高風險漏洞比例、誤報率、修補採用率、回退率與平均交付時間，外界才有機會判斷效率提升是否轉化成更低的實際風險。

延伸觀看：Google Cloud 談受控環境中的 AI 安全代理

下方官方影片介紹如何在企業環境中使用 AI 安全代理，內容並非 Chrome 1,072 個修補的發布影片，但可補充理解「攻擊代理、權限控管與人工治理」如何落地。

使用者與企業現在可以做什麼

對一般使用者而言，最有效的動作仍然很樸素：確認 Chrome 已更新，並在看到重新啟動提示時盡快完成。自動下載補丁只是第一步，舊程序若一直不重啟，新的二進位檔仍無法全面接管。

企業管理者則應重新檢視瀏覽器更新政策：

設定重新啟動通知與合理的強制期限。
確認端點管理工具能追蹤實際執行版本，而非只看補丁是否下載。
對關鍵 Web 應用建立快速相容性測試，適應更頻繁的更新節奏。
將 CISA KEV、NVD 與供應商公告納入優先級，而不是只按漏洞總數排程。
為例外裝置設定明確期限，避免「暫緩更新」變成永久停留舊版。

AI 已讓找漏洞的速度跨過一個門檻，接下來真正決定安全成果的，將是修補品質、透明度與部署速度。Chrome 這次展示的不只是模型能力，而是一條為高頻漏洞時代重新設計的軟體供應鏈。