每份報告都要人來驗：Google凍結OSS VRP，AI把漏洞懸賞的篩選成本推爆了

2026年10月1日，Google正式凍結其開源軟體漏洞懸賞計畫（Open Source Software Vulnerability Reward Program, OSS VRP）的產品漏洞提報。公司在公告中承諾於2027年第一季提供更新，期間調整計畫設計，並建議現有參與者轉向其他懸賞項目。原因很直接：大量由大型語言模型與自動化腳本產生的低品質報告湧入，Google與開源專案維護者的驗證人力被拖垮。

結構拆解：懸賞計畫的帳本原本怎麼記

Bug bounty的經濟模型建立在單價可控的前提上。發包方支付兩類成本：一是成功報告的獎金，二是每份進件的人工審查時間。獎金是變動成本、有上限，審查工時卻隨提報量線性放大。模型假設提報者有篩選誘因，因為亂提一通拿不到錢，自己也要花時間。

生成式AI把這個前提拆掉了。用LLM掃描程式碼、批次產出「疑似漏洞」報告的邊際成本接近零，提報方幾乎不用承擔篩選責任，驗證負擔整個移到接收端。結果是報告量暴增、有效比率下滑，而審查端必須逐份看過才能判定無效。Google與各開源專案維護者等於在為零成本的提報行為支付高單位工時，OSS VRP的成本結構因此失衡。

影響推演：誰受惠、誰承壓

承壓最直接的是開源維護者。他們不領Google的獎金，卻要消化湧入的報告。來源描述的場景是維護者把時間耗在驗證無效通報上，真正需要修補的問題反而排不上隊。這是典型的劣幣驅逐：雜訊量上升，等於對認真做漏洞研究的白帽駭客變相加稅，因為他們的報告被埋在大量AI產出的提報裡。

Google自身的短期損失有限。凍結的是提報管道，不是獎金支出，實際上是把無法負荷的審查成本先止血。真正的問題在計畫重啟後的門檻設計：若要求提報者附上可重現的攻擊路徑、環境與影響評估，篩選成本會回到提報端，但也會壓低參與量。

受惠的一方，理論上是能提供高品質驗證服務的中介者。如果人工驗證成為稀缺環節，具備可信審查能力的第三方平臺與專業資安團隊的議價能力會上升，企業客戶也更傾向購買經過人工複核的漏洞情報，而非自行消化原始提報流。

同類的篩選失衡並非首例。先前網易雷火AI Coding筆試的分數擠帶現象顯示，當自動化產出介入一個以人工標準設計的評分管線時，成本會卡在驗證那一端。懸賞計畫與筆試評分規模不同，傳導機制卻是同一條：產出端邊際成本趨零，審查端產能固定。

收束判斷

來源也指出整個資安懸賞行業都面臨相同問題，這代表Google的凍結更可能是一次行業級的價格重設，而非單一公司的退場。2027年第一季更新之前，可以觀察的變數有二：Google會以什麼形式的提報證明門檻重啟，以及其他大型懸賞平臺是否跟進收緊。若兩者發生，漏洞研究的報酬結構將向「可驗證的深度發現」集中，批量提交模式的套利空間會被壓縮。目前這些僅為依機制推演的方向，具體方案仍待Google公布的更新內容。