Google PageBreak 能取代漏洞掃描嗎？先看驗證流程

很多人在看到 Google PageBreak 發現逾 500 個跨站指令碼（Cross-Site Scripting，XSS）漏洞後，會先問 AI 代理能不能取代傳統掃描。這個問題要先定義清楚：工具提出的漏洞假設，如何在實際執行環境中確認？Google 公開的設計重點，是讓代理找出候選問題，再交給非 AI 撰寫的專用驗證器測試。這能協助安全團隊擴大探索，但採用價值仍取決於測試範圍、驗證覆蓋和後續處理流程。

PageBreak 的新資訊是什麼：Google 公布內部代理的 XSS 發現成果

Google 表示，內部安全代理 PageBreak 在自家第一方 Web 應用中發現逾 500 個 XSS 漏洞。這是 Google 對其內部工具與應用的成果說明，不能直接當成其他組織的效能保證。

逾 500 個漏洞是 Google 對自家第一方應用的說法

Google 產品安全團隊在 2026 年 9 月公開 PageBreak，稱這套內部 AI 代理的試行計畫始於 2025 年 11 月，之後成為正式專案。它的工作目標，是在自家 Web 應用中擴大漏洞探索，同時減少安全人員逐項搜尋的負擔。Google 說明，PageBreak 可以搭配不同模型，內部大多數使用情境則採用 Gemini 系列模型。

數字的意義要和範圍一起讀。逾 500 個是 Google 所稱在其第一方應用發現的 XSS 數量，不代表經外部研究團隊獨立重測，也沒有提供可直接換算成一般企業命中率的基準。應用數量、程式架構、授權資料、登入狀態、測試時間、漏洞去重方式，都會影響結果。某組織若拿這個數字估算預算或人力，會把特定環境的產出誤認成通用指標。

企業解讀這類成果時，可先把「發現數」拆成幾個問題：納入多少應用與功能、哪些使用者角色可供測試、代理實際走過哪些流程，以及一筆漏洞如何計算。若同一根因出現在多個頁面，是算一筆共通缺陷，還是依受影響端點分開記錄，會大幅改變數字。報告也應列出測試期間、排除的資產和無法測試的功能，讓讀者知道結果涵蓋到哪裡。缺少這些條件時，數字適合描述專案規模，不適合作為不同工具或不同團隊的直接排名。

Google 也稱其驗證策略帶來「接近零」的誤報率。這項描述同樣屬於廠商自述；公開文章並未完整列出計算方法、樣本母體或第三方驗證，因此比較適合視為設計目標與內部回饋，而非可直接引用的獨立評測結果。安全團隊若評估類似工具，應另行記錄自己的真陽性、誤報與漏報，並說清楚分母如何定義。

發現數字不等於其他環境的預期成效

不同系統的表單、前端框架、登入權限、測試資料與防護設定不一樣，同一代理能看到的輸入點也會不同。若工具只能存取公開頁面，和能以測試帳號進入完整流程、讀取程式脈絡相比，候選漏洞範圍便不相同。漏洞是否算一筆、相似問題如何合併，也會改變統計結果。

因此，評估重點應由「它找出幾筆」移到「在什麼條件下找到、每筆如何驗證、漏掉什麼、團隊花多少時間處理」。測試結果必須附帶資產清單、測試環境、驗證狀態、風險等級與修補狀態，才有辦法和既有流程比較。只看總數，無法判斷是否找到高影響弱點，也無法知道修補是否完成。

觀察結果時還要區分探索覆蓋與確認品質。探索覆蓋可以記錄已測試的主機、路徑、表單與使用者角色，並和預先核准的範圍清單核對；確認品質則要回看報告是否附有可重現的條件、驗證器狀態和人工判定。工具沒有回報問題，只能說本次測試沒有提出候選，不能證明未涵蓋的頁面或狀態不存在漏洞。若有已知測試案例，可在同一隔離環境確認流程是否能辨認它們，並把無法重現或結果不一致的案例另列，避免將測試覆蓋不足誤讀成風險降低。

Google 說明，代理提出潛在問題後，會把假設交給專用驗證器測試；驗證器的涵蓋範圍仍有限。

PageBreak 如何把 AI 提示轉成可驗證的漏洞

依 Google 公開說明，PageBreak 先提出漏洞假設，再由非 AI 撰寫的驗證器在執行環境檢查特定條件是否成立。以 XSS 為例，驗證器會監測注入的 JavaScript 是否真的在測試頁面執行。

代理提出假設，專用驗證器測試漏洞是否可重現

大型語言模型擅長依照程式或應用行為提出可能的問題，但文字看起來合理，不等於漏洞已經存在。若掃描器只交付一段程式碼路徑推論，工程師仍得自行確認輸入是否能到達危險位置、資料是否受到適當處理，以及瀏覽器或伺服器端是否真的出現安全影響。候選報告太多，反而可能擠壓修補時間。

PageBreak 的分工是將「找線索」和「確認結果」拆成兩個環節。代理探索應用並形成假設，專用驗證器則依漏洞類型，在被授權的執行環境檢查能否重現。Google 描述的驗證器以明確輸入、動作和結果判準執行檢查，代理負責探索，驗證器負責測試。若條件吻合，團隊會取得比單純文字推論更具體的證據；若驗證器沒有覆蓋該情境，結果也可能停留在未確認狀態。

這套設計不會自動證明所有候選都真、所有真漏洞都能找到。Google 的文章也指出，現有確定性驗證器尚未涵蓋每種漏洞與複雜情境，可能漏掉一些由非確定性方法發現的問題。換言之，驗證器能降低某些未經證實的回報進入修補佇列，卻可能因能力邊界形成漏報。團隊需要知道「已確認」「待人工檢查」「無法驗證」分別代表什麼，不能把未驗證直接標成安全。

實務上，狀態名稱要連到明確的下一步。「已確認」表示指定測試條件下觀察到預期安全影響，仍待人員判斷嚴重度與處置；「待人工檢查」表示候選有合理線索，但自動檢查尚未能判定；「無法驗證」則可能是測試環境、登入狀態或驗證器條件不符，需確認是重跑、補充權限還是關閉該筆。每種狀態都應有負責角色和處理時限，否則未完成的候選容易在儀表板上被當成已處理。關閉問題時也要記下判定理由，讓後續稽核能分辨誤報、重複項、環境限制與已修正缺陷。

以 XSS 為例，觀察注入程式碼是否實際執行

XSS 常見成因之一，是應用把使用者可控制的資料放入網頁時，沒有依輸出所在的脈絡正確編碼或清理，瀏覽器於是把資料當成可執行內容。風險不只在文字被顯示；若攻擊者能讓其他使用者的瀏覽器執行非預期程式碼，可能進一步影響帳號操作、頁面內容或敏感資料。實際風險仍取決於應用功能、使用者權限和防護設計。

同一份輸入在不同位置呈現，瀏覽器處理方式可能不同。資料若進入一般文字節點、HTML 屬性、網址或腳本脈絡，所需的安全處理並不相同；只檢查字串有沒有原樣出現在回應中，無法說明它最後如何被解析。測試報告應指出輸入從哪個功能送入、在哪個頁面或元件呈現，以及觀察到的執行結果，而不必把可直接重用的利用內容散布給所有收件人。這種脈絡也協助修補者找到適當的輸出處理位置，而不是只針對單一測試字串加上例外規則。

依 Google 說法，PageBreak 的 XSS 驗證器會在測試環境載入指定頁面，監測注入的 JavaScript 是否執行。防禦性測試應使用隔離環境與受控測試資料，避免影響真實使用者或未授權服務。OWASP 的測試指南也將輸入點、回應處理和執行結果列為檢查脈絡，提醒團隊不能只看到輸入被回傳，就認定漏洞已成立。

驗證成功回答的是「這個測試案例在這個環境可重現嗎」，不會單獨回答「風險有多高、是否需要立即修補、是否影響所有使用者」。人員仍須查看受影響頁面、資料敏感度、權限邊界和利用前提，再決定優先序。修補後也要使用原先的驗證條件複測，並補上能防止回歸的測試。

這類代理適合放在程式安全流程的哪一段？

AI 代理較適合補足候選漏洞探索與重複檢查，再把結果交給既有掃描、人工判讀和修補程序。它與靜態分析、動態測試及滲透測試的輸入條件和檢查深度不同，應按風險分工。

與靜態掃描、動態測試及人工複核的分工

靜態應用程式安全測試（SAST）主要分析程式碼或建置產物，能在執行前指出可疑資料流、危險呼叫或依賴問題；但它可能無法掌握實際部署設定、登入後流程或商業邏輯。動態應用程式安全測試（DAST）從執行中的應用送出測試輸入，觀察回應與行為，適合檢查部署後可見的弱點，但測試範圍會受爬取能力、帳號權限和路徑覆蓋限制。兩者都需人員判讀結果與確認影響。

這些差異會影響何時安排檢查。程式碼變更時，靜態分析可在建置或合併前提供線索；可部署的測試環境則適合用動態方式觀察實際回應。代理型探索可能需要有效帳號、穩定測試資料及更完整的互動流程，若應用具有多角色或狀態轉換，準備這些條件本身就是導入成本。對高度依賴業務規則的功能，掃描結果還要交由熟悉流程的人員檢視，判斷測試是否走到真正敏感的操作。團隊可以按開發階段安排不同方法，並讓結果回到同一個漏洞管理程序，減少不同工具各自建立無法追蹤的待辦。

人工滲透測試則由具備技術與脈絡知識的人員，按明確授權探索系統，能追問流程設計、權限組合與業務規則等較難標準化的問題。它的深度仰賴測試者經驗和投入時間，不能只用自動掃描數量比較。AI 代理可以探索更多候選路徑或生成測試假設，確定性驗證器再協助確認部分結果；人員負責判斷風險、處置與根因。這些做法相互補充，不能以單一分數排出絕對高下。

選擇方法時，可先問團隊要回答的是哪一類問題：程式中是否存在可疑資料流、目前部署是否有可觀察的弱點，還是特定角色能否跨越預期權限邊界。前兩類問題較容易轉成規則或可重複的測試；涉及多步驟工作流程、例外權限或使用者意圖的情境，通常仍需要人員理解業務脈絡。相同資產也可能需要多種檢查，因為程式碼分析看得到的內容和執行環境暴露的行為並不重疊。方法配置應考量更新頻率、資產重要性、團隊能否及時分流，以及修補後能否回歸驗證，並定期檢視是否有一類結果長期無人處理。

檢查方式	主要觀察對象	結果如何確認	人員的工作
靜態掃描（SAST）	程式碼、資料流、已知危險模式	規則或分析引擎提出線索，需檢視程式脈絡	排除不適用結果，確認程式修正及回歸測試
動態測試（DAST）	執行中的應用與可到達頁面	觀察送入測試資料後的回應或行為	提供測試帳號與範圍，判斷實際影響
AI 代理加驗證器	代理探索到的候選路徑與漏洞假設	專用驗證器在指定環境重現部分問題	管理授權，複核影響，處理未覆蓋或待確認項目
人工滲透測試	系統、流程、權限與業務邏輯	測試者以證據記錄可重現性與風險	設定範圍、評估嚴重度並追蹤修補

OWASP 將自動化工具定位為可納入開發與測試流程的檢查方式，同時指出測試範圍、資產分類、整合測試和風險判斷都需要依組織情境處理。這讓 PageBreak 類工具的比較焦點回到流程：它能不能接入既有資產盤點、漏洞管理系統、程式碼修補與發版關卡？若結果只能寄出一封報告，卻沒有負責人和處理時限，探索規模增加也可能只是擴大待辦清單。

導入前先定義範圍、授權與複核責任

先以書面界定可測資產、測試帳號、允許的動作和停止條件，再指定誰複核漏洞、誰修補、誰負責複測。未經授權的服務不得測試，能執行驗證也不代表已完成風險處置。

限定測試資產與環境，避免影響正式服務

代理可能主動操作應用、改變測試狀態或觸發驗證器，因此授權應涵蓋網域、API、帳號、測試時段、資料種類、允許的請求頻率與禁止動作。測試環境宜與正式資料及使用者隔離，並預先確認備份、監控和中止方式。若只能在正式服務測試，必須有系統擁有者同意、明確的流量上限及事故聯絡人。

代理需要的權限也應從最低必要開始。不要為了提高探索率，就提供可讀取真實個資、跨租戶資料或修改正式帳務的憑證。測試輸出若含程式片段、請求紀錄或使用者資料，儲存位置、保留期限、可讀取人員及刪除流程都要一併確認。若工具會呼叫外部模型服務，還要確認資料是否離開組織邊界，以及合約和政策是否允許。

授權最好由資產負責人和安全負責人共同確認，並保留測試目的、核准範圍、帳號用途、有效期間及緊急聯絡方式。測試執行者應能在開始前查到核准紀錄，遇到範圍外的網域、真實客戶資料或非預期狀態變更時，知道如何停止並通報。外部服務的資料處理條款也需交由組織內負責隱私、採購或法務的人員依既有程序評估，不能由測試者自行假定資料可上傳。若日誌或截圖含識別資訊，應在分享前遮蔽，並限制下載、轉寄與保存副本；保留足以讓修補者完成調查的證據即可，不需廣泛複製原始資料。

建立漏洞分流、修補與複測紀錄

每一筆回報至少要區分候選、驗證器確認、人工確認、重複項、無法驗證和已修補待複測等狀態。負責人要能查看觸發條件、受影響元件、證據摘要、測試環境和建議修復方向；必要資訊應足以重現，但不可把敏感資料或可直接利用的細節廣泛散布。風險排序需考量可利用性、暴露程度、資料敏感度與業務影響，不能照報告出現順序處理。

重現證據應放在組織核准的漏洞管理系統或受控案件空間，只開放給獲授權的修補、複核和事件處理人員。報告中可用遮蔽後的請求摘要、受影響元件識別碼與重現前提，讓工程師定位問題；完整紀錄若確有調查需要，再依權限流程取用。管理者也要定義證據保存期限、案件結束後的刪除方式，以及在工具或外部服務中留下的副本如何清除。若同一問題會影響多個產品，應以權限控管的案件連結串接處理進度，不需把敏感細節複製到一般聊天頻道或廣泛寄送的郵件。

一次小範圍試行應先建立基準線，再以相同資產、期間和計算定義對照既有流程；可依下列項目記錄成效：

1. 列出已授權的測試資產、帳號、資料與停止條件，並記下資產版本、測試期間及不納入的功能。
2. 試行前記錄既有掃描或人工檢查的候選數、確認數、處理時間與投入人力；明確定義候選、確認、誤報和重複項的計算方式。
3. 以同一批資產和可比的測試期間執行新舊流程，記錄代理提出的候選數、驗證器確認數、人工確認數、重複數及無法驗證數，明確標示各項分母。
4. 為每個確認問題指派風險等級、修補負責人和期限；證據存放在授權的漏洞管理系統，只讓必要處理人員存取，分享前遮蔽敏感資料。
5. 在隔離環境重跑原測試，確認漏洞已修復，並將防止回歸的檢查納入開發流程；記錄從發現到修補和複測各階段的耗時。
6. 比較新舊流程的確認問題數、未處理積案、單筆人工成本和覆蓋限制，再決定維持、調整或擴大範圍。若期間遇到版本、權限或測試資料變動，需註明差異，不把不可比的結果合併計算。

成效指標不只看發現數量，也可記錄從發現到確認、修補和複測所需時間，以及每筆報告的人工處理成本。若候選變多，卻讓工程師花更多時間排除誤報，工具未必改善整體安全產能。反過來，若驗證器能提供穩定證據並縮短分流時間，也要持續檢查未被驗證器涵蓋的漏洞類型，避免團隊只信任可自動確認的問題。

比較時應固定觀察窗口，並分開列出工具執行時間和人員等待、複核、修補的時間。若試行期間恰逢重大版本上線，或新增了測試帳號與資產，候選數上升可能來自覆蓋擴大，不一定代表工具本身更有效。報告宜同時列出確認問題中高風險項目的比例、未能確認候選的後續處理方式，以及修補逾期情況。即使指標改善，也需檢查團隊是否因自動化而減少原有檢查，或新增了無法承接的警示量；只有把品質、覆蓋和處理負擔放在一起，試行結果才足以支持下一階段決策。

OWASP 的 XSS 防護指南列出多種防護措施，應依資料輸出的情境採用。

為什麼發現工具之外，安全設計仍是根本

掃描與代理負責發現問題，安全設計則從程式撰寫和架構選擇降低同類缺陷反覆出現的機會。兩者處理不同階段，必須與修補和回歸測試一起運作。

檢查工具負責找問題，安全架構降低問題反覆出現

若多個頁面反覆出現相似 XSS，修補每個輸出點固然必要，還要追查資料如何流入頁面、框架的自動編碼是否被繞過、哪些共用元件允許未清理的 HTML，以及程式碼審查或測試為何沒有攔下問題。OWASP 的防護指南建議依輸出脈絡處理資料，並提醒現代框架仍可能因不安全的使用方式留下缺口。把安全預設放進共用元件、限制危險操作並建立回歸測試，能降低相同根因在新功能再次出現的可能。

Google 另以其高保證 Web 框架作為對照，表示截至 2026 年 9 月 4 日，PageBreak 在數百個採用該框架的應用只辨識出兩個 XSS，且落在內部應用或除錯端點的強化缺口。這仍是 Google 公布的內部數據，不能當成獨立驗證或所有框架的比較結論；但它指出一個值得檢視的根因問題：讓安全規則成為框架預設，和事後掃描漏洞，分別作用在缺陷形成前後。

安全代理適合協助發現和驗證部分漏洞候選，但安全團隊仍需管理權限、測試範圍、資料保護、風險判斷和修補責任。採用時先挑一組明確授權的測試資產，記下代理假設、驗證器結果、人工判定與修補狀態，再依確認品質及流程成本決定是否擴大。這樣才能把「找到更多線索」轉成可追蹤的安全改善。

常見問題：PageBreak 是否公開、是否能取代滲透測試？

Google 公開的是 PageBreak 的設計與內部成果說明；公開文章未表示外部組織可直接取得或部署這套內部工具。它也不能單獨取代滲透測試、靜態分析、動態測試或人工風險判斷。

常見問題

Q1：Google PageBreak 是一般企業可以下載的產品嗎？

Google 將 PageBreak 描述為產品安全團隊的內部 AI 代理。公開文章說明其設計和內部應用成果，並未宣告它是可供一般企業下載或採購的產品；使用者不應只憑研究文章推定其開放狀態。

Q2：逾 500 個 XSS 代表 PageBreak 的準確率很高嗎？

這個數字代表 Google 所稱在自家第一方 Web 應用發現的數量，單靠總數無法推算準確率。判斷準確度還需要知道候選總數、驗證方式、去重規則、測試範圍及漏報情況；Google 所稱的「接近零」誤報率也應標示為其自述。

Q3：AI 代理可以取代人工滲透測試嗎？

不能直接如此推論。代理可增加探索與重複檢查的規模，驗證器可確認涵蓋範圍內的特定行為；人工測試者仍需評估業務邏輯、權限組合、影響和修補優先順序。兩者的角色和證據深度不同。

Q4：團隊第一次評估 AI 安全代理，應從哪裡開始？

從明確授權、可隔離且風險較低的測試資產開始，先確認測試帳號、資料、停止條件和負責人。試行期間分開記錄候選、驗證、人工判定、修補與複測結果，再依品質和處理成本決定下一步。

• Google 公布的逾 500 個 XSS，是其內部代理在自家第一方應用的成果自述。
• PageBreak 將代理提出的候選假設交給專用驗證器測試，仍有驗證器未覆蓋與可能漏報的情境。
• 導入評估需同時記錄授權範圍、驗證品質、人工複核、修補與複測成本。