Google 由 10 月 1 日起暫停接收開源軟件漏洞獎勵計劃（OSS VRP）的產品漏洞報告，並預告在 2027 年第 1 季公布更新，直接原因是人工智能生成的自動化提交大量湧入而且絕大部分不成立，2026 年內 curl、Nextcloud 與互聯網漏洞賞金計劃（Internet Bug Bounty）相繼停發或暫停獎金，Linux 核心的保安通報名單也因重複報告幾乎無法運作，反映漏洞發現成本急跌之後，審核與修補能力才是開源生態的真正樽頸，賞金制度亦由按數量計酬轉向按證據與修補成果計酬。
Google 凍結產品漏洞報告至 2027 年
Google 在 10 月 1 日透過 X 與計劃網站宣布，針對其公開程式庫的產品漏洞報告即日暫停，涵蓋程式缺陷、邏輯漏洞與設計問題；10 月 1 日前已提交的報告照常處理，供應鏈類報告不受影響，部分雲端產品程式庫則可能改由雲端漏洞獎勵計劃接收，Google 表示自動化提交顯著增加而且絕大部分只是誤報，有報道指出工程師與維護人員要處理數以千計的報告，不少內容是虛構而無法利用的缺陷。
早在 3 月 Google 已宣布這個計劃不再接受人工智能生成的提交，因為不少報告虛構漏洞的觸發方式，或所報缺陷幾乎沒有保安影響，同期 Google、Anthropic、AWS、Microsoft 與 OpenAI 合共向 Linux Foundation 注資 1,250 萬美元（約港幣 9,750 萬元），用於向維護人員提供處理報告洪流的人工智能工具，Linux 核心維護人員 Greg Kroah-Hartman 卻直言單靠撥款解決不了問題。
生成報告只需數秒，驗證真偽卻要資深工程師逐行追查
curl 的經歷最能說明這種成本失衡，這個項目自 2019 年起透過 HackerOne 發放賞金，累計支付約 86,000 美元（約港幣 HK$670,800），卻在 2026 年 1 月 31 日終止，創辦人 Daniel Stenberg 的理由是要拿走令人提交粗疏報告的誘因，不論報告是否由人工智能生成，他在公告中提到終止前一星期收到 7 份報告，部分確實指出程式缺陷卻沒有一份屬於保安漏洞。專案 Nextcloud 其後由 4 月 22 日起停發獎金，Bugcrowd 平台的提交量則在 3 月內的三星期增至逾四倍，當中很多缺乏可信度。
大型語言模型生成的垃圾報告之所以難纏，在於內容看上去相當專業，會引用具體函數與程式碼路徑並描述聽來合理的攻擊情境，維護人員必須閱讀原始碼與嘗試重現才能確認漏洞是否存在，賞金正正把生成與驗證之間的成本差距變成可供套利的空間。
重複通報令保密機制失去意義
問題並不限於虛構內容，因為人工智能的漏洞發掘能力在 2026 年上半年明顯提升，湧入信箱的報告愈來愈多是真的，科技媒體 LWN 在 4 月報道 Stenberg 在 2 月還批評人工智能報告質素低劣，兩個月後卻每日花數小時處理水準很高的同類報告。
Linux 核心的保安通報名單最能反映這種壓力，維護人員 Willy Tarreau 在 3 月表示名單兩年前每星期收到 2 至 3 份報告，當時已增至每日 5 至 10 份，Linus Torvalds 在 5 月更形容名單幾乎無法管理，因為不同研究人員用相同的人工智能工具掃描同一批程式碼而提交大量重複發現，Linux 7.1 新增的檔案於是規定人工智能找到的缺陷原則上按公開問題處理，直接交給相關維護人員，報告須簡潔、以純文字撰寫並附上經驗證的重現方法，只有嚴重而且正遭利用的漏洞才走私下通報。數量的轉變同樣顯眼，Kroah-Hartman 的簡報顯示每個核心版本的 CVE 數目正逼近 2,000 個。
互聯網漏洞賞金計劃自 2012 年運作，累計發放逾 150 萬美元（約港幣 1,170 萬元），在 3 月底暫停接收新提交，營運方 HackerOne 的解釋與垃圾報告無關：人工智能輔助研究令發現漏洞的覆蓋面與速度同時上升，開源項目的發現數量與修補能力之間的平衡已經實質改變。
賞金制度轉向要求證明、重現步驟與修補方案
各方的調整方向相當一致就是提高提交門檻，要求報告者拿出人工智能難以偽造的東西，Google 在 5 月改革 Chrome 與 Android 的漏洞獎勵計劃，把重點放在漏洞確實存在的具體證明，鼓勵附帶可行利用示範以至修補建議的報告，記憶體安全問題的基本獎金調整為 500 美元（約港幣 HK$3,900），再按可觸及程度與可利用程度乘以倍數。Linux 核心、Nextcloud 與 Google 的做法指向相同路線，報告不能只描述懷疑而要附上可重現的證據，最好連修補程式一併提交，令維護人員的工作由驗證主張變成審閱成品。
防守一方亦開始把人工智能前移到程式碼合併之前，Google 開發的代理式審查系統 Sashiko 據報在 4 月於 Linux 核心某個子系統中，找出人手審查漏掉的釋放後使用漏洞。
企業要預留修補與分流能力
對依賴開源元件的企業來說，漏洞公告的節奏已經改變，7 月 19 日至 20 日 Linux 核心在約 24 小時內發出逾 400 個漏洞的修補，涉及無線網絡、藍牙、檔案系統與虛擬化等範疇，Red Hat、Ubuntu 與 Amazon Linux 等發行商再把這批 CVE 對應到各自的套件版本。
這反映軟件團隊的樽頸同樣落在修補而非發現，企業需要把弱點掃描結果按可觸及性自動分級，優先處理實際執行到的程式碼路徑，並預先安排核心升級與向後移植的測試流程；有餘力的機構亦可考慮直接資助維護人員的審核與修補工作，因為上游一旦停止收報告，下游最終要自行承擔風險。
由找出漏洞到自動分流與快速修補
Google 預告的 2027 年第 1 季更新，很可能成為漏洞賞金制度重新定價的參考點，因為現行模式假設發現漏洞既稀有又昂貴，這個前提在人工智能面前已經失效，可預見的路向有三條：
- 報告者須提供經驗證的重現步驟，甚至附帶修補程式，才能進入獎勵流程
- 平台引入人工智能去重與分流，在報告抵達維護人員之前先行篩走重複與虛構內容
- 獎金由按發現計酬逐步轉為資助修補與維護，與互聯網漏洞賞金計劃重新思考的方向吻合
漏洞獎勵計劃的暫停看似是行政安排，背後卻是同一趨勢的兩端：生成報告的成本向零靠攏，驗證與修補的成本仍由人力承擔，攻擊者又無需任何獎金誘因便會使用同樣的工具，誰能令修補速度追上發現速度，誰就掌握開源保安的主導權。
來源：TechCrunch
