Google Chrome AI 驅動的安全漏洞修復
Google 已在 Chrome 瀏覽器的整個漏洞生命週期中整合了大型語言模型（LLM），以擴大安全漏洞的發現與修復規模。在 Chrome Stable 版本里程碑 149 與 150 中，Google 修復了 1,072 個安全漏洞，這一數量超過了前 23 個里程碑合計修復的安全漏洞總數。
AI 驅動的漏洞發現
Google 採用多層次的 AI 方法來識別傳統模糊測試可能遺漏的漏洞。此方法包括使用專門的代理程式與完整的知識庫，以提升偵測精確度並減少誤報。
發現流程
- 代理利用: Google 利用 Gemini 驅動的代理程式掃描更廣泛的 Chrome 程式碼庫。此方法成功發現了一個已在程式碼庫中存在超過 13 年的沙箱逃逸漏洞。
- 知識整合: 為了將 LLM 的推理能力延伸至其初始訓練資料之外，Google 建立了一個知識庫，涵蓋所有先前已識別的 CVE 以及 Chrome 的完整 Git 歷史。
- 情境指導: 團隊鼓勵使用
SECURITY.md檔案，以協助模型了解信任邊界與威脅模型。專門的「critic」代理會讀取這些檔案以驗證發現。 - 模型互操作性: 系統同時支援開放權重模型與專有模型，以利用不同架構的獨特優勢。
安全防護措施
為防止 AI 行為異常，Google 採取嚴格的環境控制：
- 隔離執行: AI 嚴格在鎖定的機器上離線分析原始碼，且不具備一般的網際網路存取。
- 網路攔截: 所有網路請求皆被攔截，並根據發起應用程式與目的地透過嚴格的白名單過濾。
- 受限存取: 子代理被禁止修改本機系統或存取指定原始碼目錄之外的檔案。
自動化分流與修復
隨著發現漏洞的數量增加，Google 從以人為本的分流（先前每份報告需 5 至 30 分鐘）轉向結合規則系統與 AI 的自動化流程。
四階段分流流程
- 噪聲過濾: 自動檢查垃圾訊息、重複項目與基本漏洞條件。
- 重現: 系統在受影響的作業系統與瀏覽器版本上驗證概念驗證（PoC），並將堆疊追蹤附加至報告。
- 中繼資料豐富: AI 指派嚴重性等級，並根據明確的嚴重性指引辨識漏洞首次出現的時間。
- 自動指派: 問題被導向至相應的元件與負責人。
多代理修復工作流程
Google 使用一系列專門的代理程式來產生與驗證修復：
- 修復代理: 根據問題情境產生多個候選修復方案。
- 評論代理: 評估候選修復的功能性與是否符合 Chromium 與 Google 的風格指南。
- 測試編寫代理: 在人類開發者審查修復之前，自動為所有支援平台與組態產生測試，可能節省數週的手動工作。
縮短「修補差距」
為減輕「N 天」攻擊——攻擊者在修補公開後、使用者尚未套用前利用漏洞——Google 正加速其發布節奏。
- 發布頻率: Google 正試行每週兩次安全發布，並朝主要里程碑兩週一次的節奏前進。
- 動態修補: Google 正研究「動態修補」，即時以更新的二進位檔取代背景子程序（如 Renderer 與 GPU），免除整個瀏覽器重新啟動的需求。
- 自動重新啟動優化: 在 macOS 上，Chrome 150 現在會在應用程式處於「無視窗」狀態（背景執行且所有視窗關閉）時自動重新啟動以套用更新。
長期結構性防禦
Google 正將 AI 驅動的修補與消除整類漏洞的策略結合，特別聚焦於記憶體安全。
C++ 強化
- MiraclePtr 與 MiracleObject: 這些工具用於中和使用後釋放（UAF）漏洞。MiracleObject 目標是中和 GPU 主執行緒上高達 90% 的 UAF 漏洞。
- Spanification（Span 化）: Chrome 正將傳統的指標與大小構造遷移至
std::span類型，以消除越界（OOB）錯誤；97% 的第一方程式碼現在在嚴格的 unsafe-buffer 警告下編譯。
向 Rust 過渡
Google 正策略性地將高風險程式碼段（如影像編解碼器與字型堆疊）以 Rust 取代，以提供編譯時的記憶體安全保證，減少對執行時緩解措施與沙箱的依賴。
社群觀點與批評
雖然 Google 報告了顯著的生產力提升，技術社群卻提出了多項關於依賴 AI 於安全的反對意見：
「那些自動修復有多少被還原？有多少引入了新錯誤？發現代理的誤報率是多少？文章只列出所有成功的數字，卻沒有提及可能出錯的情況。」
其他批評者認為，漏洞激增是 C++ 本身缺陷的症狀，而非 AI 的勝利，暗示唯一永久的解決方案是全面遷移至記憶體安全的語言。亦有人擔心「打地鼠」效應，即 AI 在修復舊漏洞的同時可能引入新漏洞，以及 Google 內部的 AI 能力最終可能削弱開源、群眾協作的漏洞挖掘動機。