Google暫停部分開源漏洞獎勵：AI通報潮考驗人工驗證

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-05

Google 漏洞賞金獵人平台 Bug Hunters 據 iThome 報道在 10 月 2 日宣布，暫停接收開源軟件漏洞獎勵計畫（OSS VRP）的產品漏洞通報。觸發決定的直接原因，是自動化提交量大增，當中絕大部分並非有效漏洞，令原本應用於確認、重現與修補風險的人工審核時間被大量消耗。對開源維護者、資安研究員，以及依賴相關項目的開發團隊而言，影響不只在於獎勵渠道暫停，更在於漏洞情報的可信度和分流方式正要重新設計。

這項暫停有清楚邊界，不能解讀成 Google 停止處理所有開源安全問題。iThome 指出，OSS VRP 仍會接收供應鏈相關漏洞；涉及 Google Cloud 產品的開源程式碼庫，仍可經 Cloud VRP 提交產品漏洞。研究員亦可轉往 Google 其他漏洞獎勵計畫或 Patch Rewards Program。對香港採用 Google 開源技術的開發與資安團隊來說，應先分辨問題屬於產品缺陷、供應鏈風險，還是雲端產品範圍，避免把通報送到暫停受理的渠道。

暫停的是產品通報，供應鏈風險仍在受理

OSS VRP 在 2022 年推出，目的是鼓勵研究人員尋找 Google 旗下開源項目的安全漏洞，涵蓋 Bazel、Angular 與 Golang 等項目。iThome 報道稱，計畫本來同時覆蓋開源產品自身漏洞，以及會影響原始碼、建置流程和套件發布機制的供應鏈安全問題。今次調整針對前一類的產品漏洞報告，保留後一類的受理安排，反映平台正嘗試在審核資源不足時，優先保留可能波及程式碼來源與發布鏈的風險入口。

Google 預計在 2027 年第一季公布機制調整的後續進展。這段空窗期意味著研究人員不能只依賴原有提交習慣；開發團隊亦不宜把「暫停產品通報」誤當作風險消失。若發現問題，首先要按受影響項目、攻擊路徑及安全後果整理證據，再核對可用的計畫範圍。對需要處理第三方套件、建置工具和發布流程的團隊而言，供應鏈通報仍可受理尤其重要，因為這類問題往往牽涉較廣泛的下游使用者。

AI 令找錯更快，也令驗證更昂貴

問題核心不在於報告由人或 AI 撰寫，而是提交內容有沒有足以讓維護者驗證的證據。iThome 指出，Google 在今年 3 月已因 AI 生成漏洞報告激增而收緊 OSS VRP 規則；常見問題包括錯誤資訊、虛構的漏洞觸發方式，以及雖然發現程式錯誤、實際安全影響卻很低的個案。生成式 AI 能快速讀取程式碼、歸納可疑模式和產生大量文字，但它同樣能把未經驗證的推測包裝成看似完整的漏洞敘述。

對審核者來說，每份報告的成本並非讀完幾段文字便結束。維護者要確認受影響版本、建立相同環境、依步驟重現、判斷攻擊者能否真正利用，還要評估權限、資料或系統完整性的實際後果。一份只有表面合理、但無法重現的報告，可能耗用與真漏洞相近的前期時間。當大量這類通報同時湧入，最先被擠壓的往往是高價值報告的處理速度；這是由來源事實作出的實務推論，並非 Google 已公開的量化評估。

iThome 亦提到，Google 在 3 月已提高高優先級項目的驗證門檻，並停止就部分較低層級項目的產品漏洞提供獎勵或進行審查。這顯示平台早前已嘗試用範圍與門檻控制流量，但自動化無效報告的壓力仍然持續。Curl 維護者今年 1 月終止抓蟲獎勵計畫，以及 ProjectDiscovery 的 OSS Bounty Program 在 9 月下架，也說明此類負擔並不限於單一機構；問題在於，大量 AI 生成報告的湧入速度，已超過人工驗證和分流的能力。

研究員應交付可驗證證據，而非只交付敘述

較可靠的 AI 輔助漏洞驗證流程，第一步是把 AI 的輸出視為研究假設，而非提交結論。研究員可用它協助定位可疑程式路徑、整理文件或生成測試方向，但在送出報告前，應由人手確認受影響版本和前置條件，並在隔離環境完成最小可重現驗證。報告要清楚交代輸入、預期與實際結果、影響範圍和所需權限；若無法重現，就應繼續查證而非以流暢文字補足空白。

第二步是將「程式行為不合預期」與「具有可利用的安全影響」分開處理。程式錯誤未必構成安全漏洞，研究員需要說明攻擊者如何抵達相關路徑、可造成甚麼損害，以及既有權限或設定會否限制風險。這能幫助維護者較快決定優先次序，也減少把一般品質問題送入資安渠道。AI 可以協助建立測試矩陣，但最終風險判斷仍須基於實際環境和證據，不能只依賴模型推斷。

維護團隊則可把初步分流設計為「證據優先」：先檢查受影響版本、重現步驟、攻擊前提和影響描述是否齊全，再安排深入技術審核。這不是要排除 AI 輔助研究，而是令有限的人手優先處理可驗證的線索。對重複或證據不足的報告，提供明確退件理由與補件要求，可令研究員知道需要補甚麼，而不是把同一猜測換個說法再次提交。長遠而言，提交表格、重現模板和範圍說明都應反映這些最低要求。

下一步看受理機制能否保留有效線索

Google 到 2027 年第一季才會交代 OSS VRP 產品通報機制的下一步，外界值得觀察的將是新安排如何同時降低垃圾流量與避免錯過真正漏洞。門檻過低會繼續消耗維護資源；門檻過高則可能令獨立研究員難以通報早期發現。較可行的方向，是讓自動化工具服務於證據整理、去重和初步檢查，而把可利用性與安全影響的判定保留給能追溯、能重現的人手流程。

對採用開源組件的開發團隊，今次事件亦是一個提醒：外部漏洞獎勵計畫只是生態的一環，內部仍要保留套件盤點、建置流程審視和漏洞驗證能力。短期內，最受影響的是需要提交產品漏洞的研究員與相關項目維護者；較長期則要看平台能否將高質素通報更快送到合適審核者手上，讓 AI 提升研究效率，同時避免大量低質報告拖慢審核隊列。