Google 開發出能主動搜尋並確認自身於網站應用程式中安全漏洞的自主型 AI

目錄

• 你可能想知道的事
• 主要議題
• 關鍵見解表
• 後續…

你可能想知道的事

AI 能否可靠地只偵測出真實的安全缺陷，而不是產生誤報？當偵測與自動修補建議結合時會發生什麼事？

主要議題

Google 近日揭露了一個內部系統，名為 PageBreak，由其產品安全團隊開發，用以自主搜尋公司自家第一方網路應用程式中可被利用的漏洞。與許多會產生大量可疑或不正確報告的自動化掃描器不同，PageBreak 的設計會在任何人類審查者看到發現之前，透過對應用程式的運行實例嘗試主動利用來驗證疑似問題。此方法旨在減少誤報數量，並優先處理僅經確認且可採取行動的漏洞。

PageBreak 背後的理由回應了安全團隊日益嚴重的痛點：現代 AI 工具會產生許多聽起來合理但實際上不可利用的錯誤漏洞報告。區分真正的安全缺陷與業界所稱的 AI「幻覺」已變得既耗時又易出錯。透過將每個假設交由專門的驗證器，在運行中的應用程式副本上嘗試真實利用，PageBreak 根據 Google 的描述能產生幾乎為零誤報率的結果。

在運作層面，PageBreak 建構於 Google 的內部大型模型之上，並於 2025 年 11 月開始試點，然後在 2026 年 1 月擴展為完整專案。該系統已發現數百個可利用的問題：例如，它在 Google 的第一方網路資產中找到超過 500 個跨站指令碼（XSS）漏洞。XSS 漏洞可能讓攻擊者劫持會話、竊取資料或以已驗證使用者的身分執行操作，因此這些發現對使用者安全具有實質意義。

PageBreak 的結果也彰顯了更安全應用框架的有效性。當代理程式針對建立於 Google 較新且高保障的網頁框架（這些框架被設計為從結構上使整類漏洞不可行）的應用程式執行時，它僅偵測到兩個漏洞。該對比強調了一個簡單的安全教訓：從根本構建更安全的系統，可減少事後尋找漏洞與修補的需求。

該專案在 AI 與安全議題日益升高的背景下亦具代表性。過去一年中，多起由 AI 啟用的安全事件與研究示範已顯示 AI 如何被用來自動化或加速攻擊。PageBreak 則站在防禦的一端：不是讓 AI 促成入侵，而是主動用來在惡意行動者之前發現並確認弱點。

Google 提醒，PageBreak 受益於許多組織所不具備的資源，例如貫穿數十億行程式碼的單一統一內部程式碼庫以及多年的成熟內部掃描基礎設施。這些優勢意味著具體實作可能不易在較小組織重現，但概念上的轉變——優先採信經驗證的利用而非原始 AI 標示的假設——提供了一個可移植的策略以改進安全工作流程。

展望未來，Google 計劃將 PageBreak 與另一個內部專案 CodeMender 整合，該專案會生成自動化修補建議。一旦連接，透過 PageBreak 發現且確認的漏洞可以附帶由 CodeMender 撰寫的修復建議，讓工程師審查並核准改動，而不是從頭開始著手修補。這種組合可能實質縮短從發現到解決的時間，同時減少安全與工程團隊的手動勞務。

這項關鍵見解顯著影響了對自動化安全測試的理解：在報告之前以實際利用嘗試來驗證潛在缺陷，可以大幅降低誤報並將人力注意力集中在真實風險上。此模式將努力從分流（triage）轉向驗證與修復，能提升修補速度與整體安全成效。

倫理與運作上的考量仍然重要。即使在受控環境中執行利用嘗試，也需要謹慎的防護措施以避免非預期的副作用或資料外洩。此外，自動化發現與建議修補必須保留人為監督以確保正確性並避免引入回歸。Google 的做法突顯了自動化、可靠性與安全工具治理需求之間的實務取捨。

關鍵見解表

後續…

展望未來，有數個技術方向值得進一步探索以推進軟體安全的防禦型 AI。首先，研究安全且可稽核的利用驗證技術將有助於確保主動測試不會造成附帶傷害。其次，為 AI 生成的修復建立標準——例如對自動提議修補的可驗證測試套件——將降低自動修補導致回歸的風險。第三，更廣泛採用高保障框架與以安全為設計原則的做法，可以減少攻擊面並降低對被動補救措施的需求。

最後，結合機器學習、程式分析與安全工程實務的跨領域工作將至關重要。 強調可驗證結果、透明決策日誌與人為審查介入的工具 能使自動化安全系統既更有效也更值得信賴。隨著 AI 能力提升，專注於驗證、可解釋性以及與既有工程工作流程的整合，將有助於確保這些工具強化而非複雜化組織安全。