如何驗證 AI 漏洞回報：開源漏洞賞金與人工審核指南

很多人第一個會先想到，AI 代理能不能找出更多漏洞；但更前面的問題是，提交內容能否在指定環境重現，並證明問題位於攻擊者可到達的程式路徑，且造成實際安全影響。

Google 自 2026 年 10 月 1 日起暫停旗下開源軟體漏洞獎勵計畫（Open Source Software Vulnerability Reward Program，OSS VRP）的產品漏洞新提交。供應鏈安全報告，以及暫停前已提交的案件，不受這次調整影響。這是特定計畫中一類新案件的暫停，不能簡化成 Google 所有漏洞賞金計畫都停止。

自動化工具能協助掃描程式碼、整理線索並產生報告，然而產生線索與證明漏洞成立是不同工作。程式碼看起來可疑，未必能被外部輸入觸發；即使確實有錯，也未必能越過專案的安全邊界或影響機密性、完整性、可用性。理解這次公告，應先分清楚計畫範圍，再檢視驗證證據如何把線索轉成可供審核的安全問題。

一、Google 暫停的是 OSS VRP 哪一類提交？

暫停範圍是 2026 年 10 月 1 日起送出的產品漏洞新提交；供應鏈報告與此前已提交的案件不在暫停範圍內，Google 表示會在 2027 年第一季提供後續更新。

OSS VRP 是 Google 針對其開源專案設立的漏洞獎勵計畫。此次公告指向「產品漏洞」（Product Vulnerabilities）類別的新提交，並非停止所有 Google 漏洞回報管道。Google 鼓勵研究者考慮其他漏洞獎勵計畫；但其他計畫有各自的適用產品、漏洞類別與回報規則。

不能因此假設某一份 OSS VRP 報告可直接改投別處，或原有獎勵條件照常適用。研究者應先檢查目標計畫的範圍與規則，再決定是否提交。

「這次暫停是因自動化提交顯著增加，其中絕大多數都無效。」— Google 對暫停原因的說明，經 TechCrunch 報導

這句說明呈現的是 Google 對案件品質與審核負荷的判斷，不能延伸成所有 AI 輔助研究都無效。公開說明沒有提供足以完整還原情況的提交總量、無效比例、審核工時或無效案件分類，因此不宜自行推算「AI 報告有幾成是假漏洞」，也不能把媒體或社群的估計當成 Google 的統計。

2027 年第一季是 Google 承諾提供計畫更新的時間，不是已宣布的重啟日期。更新可能交代後續安排，但目前不應預測提交何時恢復、會改成什麼門檻，或假設已經公布新的受理制度。對研究者來說，眼前可確認的是產品漏洞新案的暫停範圍，以及供應鏈報告和既有案件的例外；其他問題仍待官方後續說明。

二、AI 漏洞報告增加，為何沒有同步增加有效漏洞？

掃描與撰寫報告的成本下降，並未自動補上重現、可達性和安全影響的證明；因此產生的候選線索增加，不代表經驗證的漏洞也以相同幅度增加。

漏洞判斷至少要分清三個層次。第一是程式碼是否存在錯誤，例如長度檢查疏漏或緩衝區操作不當；第二是攻擊者能否在合理條件下觸發錯誤；第三是觸發後是否造成安全後果。報告若只指出某一行程式碼「看起來危險」，沒有說明輸入如何抵達該處、需要什麼權限、實際觀察到什麼結果，就仍停在候選線索，而非可供判級的安全問題。

Google 2026 年 3 月公布、4 月補充的 OSS VRP 規則更新，已描述兩種容易增加人工判讀負擔的情況：報告對漏洞觸發方式有錯誤敘述或幻覺；程式碼雖有缺陷，但依專案安全模型影響有限，或所在路徑實際不可達。這些例子說明，靜態掃描或模型生成的解釋不能代替執行驗證。若一份報告省略環境、輸入條件和觀察結果，審核者就必須先花時間補做研究者未完成的步驟。

人工審核的成本也不只在閱讀文字。審核者要確認專案是否在計畫範圍內、版本是否受影響、測試結果能否重現、問題是否已知或已修補，再判斷風險與後續處理。如果大量報告反覆提出沒有可驗證證據的猜測，即使其中確有少數重要線索，也會讓排序和回覆更困難。Google 沒有公開這些環節各自耗費的工時，較穩妥的說法是：低品質報告會增加分流負擔，至於負擔規模尚無完整公開數據可供量化。

三、一份可審核的漏洞回報需要哪些驗證證據？

至少交代受影響專案與版本、測試環境、最小重現步驟、觸發條件、可觀察結果，以及結果如何影響機密性、完整性或可用性。

先標示目標與環境。報告應寫清楚專案名稱、受影響版本或提交識別碼、作業系統、必要依賴和相關設定；若問題只在特定編譯選項或非預設設定下發生，也要明講。這些資訊讓維護者能知道自己要測什麼，而非猜測報告所用的程式版本與執行條件。若只在已過時版本重現，還需要說明目前仍受支援的版本是否受影響。

接著提供最小重現步驟。可行時附上精簡測試案例、命令、輸入檔或自動化概念驗證（proof of concept，PoC），並列出預期與實際結果。重現材料應只包含驗證問題所需的部分，避免貼上大量無關輸出或難以執行的完整專案。對模糊測試發現，應說明使用的測試目標、觸發輸入和錯誤輸出；若報告涉及記憶體破壞，也要依計畫規則提供要求的重現方式。

再把觸發條件與可達路徑說明白。輸入由哪個介面進入？攻擊者需要登入或取得何種權限？哪一段呼叫鏈把輸入帶到缺陷位置？是否必須由使用者點擊、啟用特殊設定或先控制另一個元件？以日誌、堆疊追蹤、網路回應、測試輸出或除錯器觀察結果支持敘述，能讓審核者檢查「可能」是否已成為「確實可觸發」。若程式路徑依設計永遠不會從不可信輸入抵達，需重新評估它是否構成安全漏洞。

最後說明安全影響，不只貼錯誤訊息。可用機密性、完整性、可用性三個面向整理：未授權者能讀取什麼資料、能修改哪項狀態、是否能讓服務中斷或資源耗盡？影響要連到實際威脅模型與前置條件，並區分已觀察到的結果和推測的可能後果。若只能證明程式崩潰，應如實寫成崩潰；不要在沒有證據時直接升格為遠端程式碼執行或資料外洩。

Google 的報告品質框架也把漏洞描述、攻擊前置條件、影響分析、重現步驟、目標資訊和重現輸出列為評估面向。這不是保證獲得獎勵的公式，計畫仍會依漏洞類別、專案層級和規則判斷；它提供的實務方向是讓報告可重現、可定位、可評估，而不是用長篇敘述取代證據。

「研究輔助工具的輸出需要在研究過程中驗證。」— Google Bug Hunters，OSS VRP 規則更新（譯文）

四、Google 先前如何提高 OSS VRP 的提交門檻？

2026 年規則依專案層級與漏洞類別調整受理及獎勵；例如 OT0、OT1 專案的記憶體破壞報告，須提供指定 OSS-Fuzz 重現步驟或已合併修補，低層級專案部分產品漏洞則不再受理獎勵與審查。

OSS-Fuzz 是 Google 推動的開源軟體模糊測試服務，透過大量自動產生的輸入尋找程式錯誤。Google 3 月的規則更新指出，OT0 與 OT1 專案的記憶體破壞報告，需要使用既有 fuzz target 提供精確的 OSS-Fuzz 重現步驟，或附上已合併的修補。這項要求針對特定專案層級與記憶體破壞報告，不能概括為每種漏洞都必須先有 OSS-Fuzz 案例或已合併修補。

同一份更新也說明 OT2、OT3 專案的產品漏洞和其他安全問題不再提供獎勵或認可，Google 安全團隊不會分流這些報告。規則另調整 OT2 供應鏈案件獎勵上限。這些是 2026 年 3 月發布、4 月補充的層級規則；10 月公告則是暫停 OSS VRP 產品漏洞新提交。兩者時間與作用不同，不能把較早的層級調整寫成 10 月暫停的全部新規則，也不能推論所有專案都適用同一套門檻。

這種分層設計有其流程含意：相同的技術現象，依專案重要性、受理類別和可證明的實際影響，可能有不同的審查與獎勵安排。研究者應直接核對當前規則與目標專案層級，不宜依論壇舊文推測案件是否受理。專案清單和規則可能調整，真正提交前應以 Google Bug Hunters 的現行說明為準。

五、研究者與開源維護者可以如何調整驗證流程？

研究者應先自行重現並呈現影響證據；維護者則可用固定欄位收集版本、環境、前置條件與輸出，再按嚴重性和可驗證程度分流。

研究者可在送出前做一輪「從乾淨環境重新跑一次」的檢查：依報告中的步驟重建環境，確認另一位研究者不必猜缺少的依賴或設定也能看到相同結果。接著刪除與重現無關的日誌和推論，清楚標出哪些是觀察、哪些是解釋。若使用 AI 代理整理程式碼或撰寫 PoC，需親自檢查路徑、函式名稱、輸入條件與輸出是否真實存在；模型生成的測試程式本身也要執行，不能只因文字完整就視為證據。

提交前還要確認回報管道、適用專案和目前規則。若目標計畫暫停某類新案，應遵循公告或選擇真正涵蓋該產品的其他負責管道，並尊重負責披露的規定。不要為了繞過暫停，把相同內容大量寄給不相關維護者；重複投遞會使責任歸屬和修補協調更複雜，也可能違反各計畫的提交規範。

對維護者而言，回報表單可要求必要但精簡的欄位：受影響版本、執行環境、前置條件、最小測試案例、輸出證據和影響說明。分流時先確認是否在專案範圍內，再看是否可重現、是否有可達路徑，最後評估可能影響；遇到資料不足的案件，可明確指出缺少哪項證據與如何補充，避免只回覆「無效」卻沒有可行的下一步。遇到疑似高風險且證據不完整的案件，也應依既有內部流程升級處理，不讓表單分數取代安全判斷。

維護者還可觀察回報中常見的失敗原因，例如無法重現、錯誤版本、誤讀呼叫路徑、影響與證據不相符等，再改善回報指引或測試環境。這是依維護流程提出的做法，並非 Google 已公布的 10 月新規，也沒有公開數據證明某種表單或工具能單獨解決分流問題。重點在於讓提交者更容易交出可檢查的材料，並讓審核端能快速指出缺口。

六、如何判斷漏洞回報是否值得進入人工審核？

依序確認計畫與專案範圍、受影響版本、能否重現、攻擊路徑是否可達，以及是否有具體安全影響；缺少其中一項時，應標明待補證據，而非把可能性當成已證實漏洞。

這些檢查點能幫助判斷報告目前到了哪一層，但不等於自動判決器。可重現性回答「現象是否真實」，可達性回答「攻擊條件是否成立」，影響分析回答「安全後果是什麼」，計畫範圍則回答「這個管道是否負責受理」。任何單一環節都不能代替整體判斷；例如重現出崩潰不一定代表能造成遠端攻擊，而影響看似重大也需要符合具體前置條件。

研究者送件時可用下列清單自我檢查；維護者也可將它作為初步分流欄位。它整理的是證據，不承諾案件一定受理、被評為有效或取得獎勵。

1. 範圍：確認專案、漏洞類別與提交管道目前適用，並記下查核的規則版本。
2. 版本與環境：列出受影響版本、必要設定、依賴與執行環境。
3. 重現：從乾淨環境按步驟執行，附最小測試案例與可觀察輸出。
4. 可達性：交代攻擊者如何提供輸入、需要哪些權限，以及程式路徑如何到達缺陷。
5. 影響：說明對機密性、完整性或可用性的具體後果，分開標示實測與推論。

Google 已承諾在 2027 年第一季提供 OSS VRP 後續更新，屆時可再確認產品漏洞提交安排是否改變。在此之前，研究者應先核對 Google Bug Hunters 的最新計畫說明，提交前確認範圍並保留可重現的證據。判斷一份漏洞回報品質時，回到四個問題即可：是否在適用範圍、能否重現、攻擊路徑是否可達、是否造成有證據支持的安全影響。

• 2026 年 10 月 1 日起，OSS VRP 暫停產品漏洞新提交；供應鏈報告和此前案件不受此公告影響。
• AI 可以協助發現線索，報告仍須證明版本、環境、重現步驟、可達路徑和具體安全影響。
• 2027 年第一季是 Google 承諾提供更新的時間，目前尚未公布重啟日期或後續受理方式。

常見問題

Q1：Google 是不是停止所有漏洞賞金計畫？

不是。公告針對 OSS VRP 的產品漏洞新提交。Google 表示供應鏈報告和暫停前已提交案件不受影響，其他計畫則須各自確認範圍與規則。

Q2：AI 找到程式碼缺陷，就算有效漏洞嗎？

不一定。還需要確認攻擊者能否觸發、程式路徑是否可達，以及是否造成具體安全影響。無法重現或只有理論推測的缺陷，證據尚不足以支持完整的漏洞判斷。

Q3：Google 何時會重新接受 OSS VRP 產品漏洞報告？

目前沒有公布重啟日期。Google 承諾在 2027 年第一季提供計畫更新；更新前應以官方計畫頁面為準。