English Article
Google has stopped accepting new submissions to its Open Source Software Vulnerability Rewards Program (OSS VRP), pointing to a flood of AI-generated vulnerability reports that has overwhelmed triage — a shift first reported by BleepingComputer.
The pause is a concrete, high-profile signal that generative AI has rewritten the economics of vulnerability disclosure at the intake layer. What was once a skill-based pipeline — researchers demonstrating that they understood a codebase well enough to surface a real flaw — has turned into a volume problem. When the marginal cost of producing a plausible-looking report collapses toward zero, programme operators must spend escalating effort simply to establish whether a submission reflects genuine analysis at all.
According to BleepingComputer's coverage of the announcement, Google characterised the suspension as temporary, said existing valid submissions would still be paid out, and confirmed that its other reward programmes — including those covering Android and Google Cloud — are unaffected. The company has not said when OSS VRP intake will resume, what criteria might govern a reopening, or whether proof-of-concept requirements or submission caps will change. It has indicated that triage tooling is under development.
Two details matter to the open-source community beyond the headline. First, the programme targets vulnerabilities in open-source projects broadly, not just Google's own code — it exists precisely because critical shared infrastructure often rests on libraries and maintainers operating with thin resources. Second, the failure mode here is not fraud in the traditional sense. Much of the influx is likely opportunistic rather than adversarial: automated reports assembled from public vulnerability databases, static-analysis output pasted into an LLM, or templated submissions aimed at whichever programme currently accepts intake. The outcome is the same regardless — engineer-hours burned separating signal from noise, and a programme shuttered by spam volume.
What this means for maintainers
For open-source maintainers in Hong Kong and the wider region, the practical question is narrower than Google's: what do you do when the same dynamic lands in the inbox of a project that has no bounty programme at all? Libraries used as defaults in regional startups receive a steady stream of "responsible disclosure" emails, and a growing share of those are synthetic.
The response is triage hygiene, not gatekeeping. Treat inbound vulnerability claims as presumptively synthetic until proven otherwise, and require three things before committing any engineering time: a reproducible proof of concept against a pinned version, evidence that the reporter actually analysed the code rather than merely scanning it, and an impact description grounded in how the software is realistically deployed. Maintainers should also publish a security policy that states these requirements explicitly — both to deter lazy submissions and to give genuine reporters a clear path. None of this requires new tooling; it requires deciding in advance what evidence is non-negotiable.
What this means for bounty-dependent researchers
Researchers whose income leans heavily on a single vendor programme are structurally exposed to risk when that programme closes without warning. The diversification playbook is straightforward: institutional grants and maintainer funds, paid maintainership roles, sponsorship, and paid support arrangements running alongside bounties. Strategically, it also pays to prioritise work that automated report generation cannot easily fabricate — novel exploit chains, hardware and protocol attacks, deep remediation of complicated codebases, and programmes that keep human validation in the loop at every stage.
The policy thread
The OpenSSF and similar groups have long argued for pooled, sustained funding of upstream open-source infrastructure, contending that market-driven incentives under-provision for shared dependencies. A bounty programme that can be brought to a halt by spam volume makes the same point from a different direction: reward programmes are only as durable as their intake design, and programmes reliant on researcher goodwill alone have very limited operating room. If automated submissions stay cheap while human verification stays expensive, more programmes will look for ways to throttle or close intake — leaving genuinely novel research to be funded by other means.
Google has not announced resumption terms for the OSS VRP. The story is worth revisiting when it does — and worth monitoring if other major schemes tighten their rules in response to the same AI-spam dynamic.
中文文章（繁體・香港用語）
Google 已停止接受其開源軟件漏洞獎勵計劃（OSS VRP）的新提交，指大量 AI 生成的漏洞報告令審核流程不勝負荷 —— 這一轉變由 BleepingComputer 首先報道。
這次暫停是一個具體、備受矚目的信號，顯示生成式人工智能已改寫漏洞披露在收件層面的經濟。原本以技能為基礎的管道 —— 研究人員證明他們對代碼庫的了解足以發現真實缺陷 —— 如今變成數量問題。當生成一份看似合理報告的邊際成本趨近於零時，計劃營運方單是判斷一份提交是否反映真實分析，就已須投入大量工夫。
根據 BleepingComputer 對該公告的報道，Google 將這次暫停描述為暫時性，表示仍然有效的提交仍會支付獎金，並確認其其他獎勵計劃（包括涵蓋 Android 和 Google Cloud 的計劃）不受影響。Google 尚未說明 OSS VRP 何時會恢復收件、恢復的條件為何，或概念驗證（proof-of-concept）要求與提交上限是否會改變。公司已表示審核工具（triage tooling）正在開發中。
對開源社群而言，除了標題之外還有兩個細節值得注意。第一，該計劃涵蓋的範圍是廣泛的開源項目，而非僅限 Google 自身的代碼 —— 它之所以存在，是因為關鍵的共享基礎設施往往依賴資源有限的代碼庫和維護者。第二，這裡的失效模式並非傳統意義上的欺詐。大量湧入的報告很可能是機會性而非對抗性的：從公開漏洞資料庫自動拼湊的報告、靜態分析輸出貼入 LLM、或以現時仍接受收件的計劃為目標的模板化提交。無論如何，結果都一樣 —— 工程師時數耗費在分辨信號與噪音之上，而計劃則因垃圾訊息的數量而被迫關閉。
這對維護者意味著甚麼
對香港及整個地區的開源維護者而言，實際問題比 Google 面對的更窄：當同樣的動態出現在一個根本沒有賞金計劃的項目收件箱時，你該怎麼做？被區域初創公司預設採用的函式庫（library）經常收到大量「負責任披露」的電郵，其中合成的比例正不斷上升。
回應方式是審核衛生，而非設關卡。在證明之前，應假設收到的漏洞報告是合成的，並在投入任何工程時間前要求三項條件：針對已鎖定版本的可重現概念驗證、報告人實際分析代碼（而非僅僅掃描）的證據、以及以軟件實際部署方式為基礎的影響描述。維護者（maintainer）亦應公開一份安全政策，明確說明這些要求 —— 既能阻止偷懶的提交，也讓真正的報告人有清晰的路徑。這些都不需要新工具；需要的是事先決定哪些證據是不可妥協的。
這對依賴賞金收入的研究人員意味著甚麼
收入高度依賴單一廠商計劃的研究人員，在該計劃毫無預警關閉時，在結構上便直接暴露於風險之中。分散風險的方法很直接：機構資助與維護者基金（maintainer funds）、受薪維護職位、贊助，以及與賞金並行的付費支援安排。從策略上講，優先處理自動化報告生成難以偽造的工作也大有裨益 —— 新穎的漏洞利用鏈、硬件與協議攻擊、複雜代碼庫的深度修復，以及在每個環節都保持人工驗證的計劃。
這對政策脈絡意味著甚麼
OpenSSF 等組織長期主張對上游開源基礎設施進行集中、持續的資金支持，認為以市場為主的誘因對共享相依項目（shared dependencies）的供應不足。一個能因垃圾訊息數量而停擺的賞金計劃，從另一個角度說明了同樣的道理：獎勵計劃的耐久性取決於其收件設計，而僅依賴研究人員善意的計劃，其運作空間本已極為有限。如果自動化提交仍然便宜而人工驗證仍然昂貴，更多計劃將尋找方法限制或關閉收件 —— 真正新穎的研究將只能依靠其他方式資助。
Google 尚未公布 OSS VRP 的恢復條款。這則新聞值得在它公布時重新審視 —— 若其他主要計劃因同樣的 AI 垃圾訊息動態而收緊規則，也值得持續關注。
中文文章（繁體・香港用語）
Google 已停止接受其開源軟件漏洞獎勵計劃（OSS VRP）的新提交，指大量 AI 生成的漏洞報告令審核流程不勝負荷 —— 這一轉變由 BleepingComputer 首先報道。
這次暫停是一個具體、備受矚目的信號，顯示生成式人工智能已改寫漏洞披露在收件層面的經濟。原本以技能為基礎的管道 —— 研究人員證明他們對代碼庫的了解足以發現真實缺陷 —— 如今變成數量問題。當生成一份看似合理報告的邊際成本趨近於零時，計劃營運方單是判斷一份提交是否反映真實分析，就已須投入大量工夫。
根據 BleepingComputer 對該公告的報道，Google 將這次暫停描述為暫時性，表示仍然有效的提交仍會支付獎金，並確認其其他獎勵計劃（包括涵蓋 Android 和 Google Cloud 的計劃）不受影響。Google 尚未說明 OSS VRP 何時會恢復收件、恢復的條件為何，或概念驗證（proof-of-concept）要求與提交上限是否會改變。公司已表示審核工具（triage tooling）正在開發中。
對開源社群而言，除了標題之外還有兩個細節值得注意。第一，該計劃涵蓋的範圍是廣泛的開源項目，而非僅限 Google 自身的代碼 —— 它之所以存在，是因為關鍵的共享基礎設施往往依賴資源有限的代碼庫（library）和維護者（maintainer）。第二，這裡的失效模式並非傳統意義上的欺詐。大量湧入的報告很可能是 opportunistic（機會性）而非對抗性的：從公開漏洞資料庫自動拼湊的報告、靜態分析（static analysis）輸出貼入 LLM、或以現時仍接受收件的計劃為目標的模板化提交。無論如何，結果都一樣 —— 工程師時數耗費在分辨信號與噪音之上，而計劃則因垃圾訊息的數量而被迫關閉。
這對維護者意味著甚麼
對香港及整個地區的開源維護者而言，實際問題比 Google 面對的更窄：當同樣的動態出現在一個根本沒有賞金計劃的項目收件箱（inbox）時，你該怎麼做？被區域初創公司預設採用的函式庫（library）經常收到大量「負責任披露」（responsible disclosure）的電郵，其中由 AI 合成的比例正不斷上升。
回應方式是審核衛生（triage hygiene），而非設關卡。在證明之前，應假設收到的漏洞報告是合成的，並在投入任何工程時間前要求三項條件：針對已鎖定版本（pinned version）的可重現概念驗證（proof of concept）、報告人實際分析代碼（而非僅僅掃描）的證據、以及以軟件實際部署方式為基礎的影響描述。維護者（maintainer）亦應公開一份安全政策（security policy），明確說明這些要求 —— 既能阻止偷懶的提交，也讓真正的報告人有清晰的路徑。這些都不需要新工具；需要的是事先決定哪些證據是不可妥協的。
這對依賴賞金收入的研究人員意味著甚麼
收入高度依賴單一廠商計劃的研究人員，在該計劃毫無預警關閉時，在結構上便直接暴露於風險之中。分散風險的方法很直接：機構資助與維護者基金（maintainer funds）、受薪維護職位、贊助，以及與賞金並行的付費支援安排。從策略上講，優先處理自動化報告生成難以偽造的工作也大有裨益 —— 新穎的漏洞利用鏈（exploit chain）、硬件與協議攻擊、複雜代碼庫的深度修復，以及在每個環節都保持人工驗證的計劃。
這對政策脈絡意味著甚麼
OpenSSF 等組織長期主張對上游開源基礎設施進行集中、持續的資金支持，認為以市場為主的誘因對共享相依項目（shared dependencies）的供應不足。一個能因垃圾訊息數量而停擺的賞金計劃，從另一個角度說明了同樣的道理：獎勵計劃的耐久性取決於其收件設計，而僅依賴研究人員善意的計劃，其運作空間本已極為有限。如果自動化提交仍然便宜而人工驗證仍然昂貴，更多計劃將尋找方法限制或關閉收件 —— 真正新穎的研究將只能依靠其他方式資助。
Google 尚未公布 OSS VRP 的恢復條款。這則新聞值得在它公布時重新審視 —— 若其他主要計劃因同樣的 AI 垃圾訊息動態而收緊規則，也值得持續關注。