Google has paused its Vulnerability Reward Programme payouts for product security reports against a group of its open-source projects, according to reporting by The Hacker News, which attributes the change to a surge in invalid automated reports.
The Hacker News reports that the change took effect on 1 October. Researchers submitting security flaws in the code of projects including Go, Angular, and Protocol Buffers no longer receive a bounty for those reports through Google's programme. Two categories remain in scope, per that reporting: supply chain compromise reports, and submissions filed before 1 October, which remain under review.
Where the reports go now
Google has not publicly named a replacement intake path for product-level vulnerabilities in these projects. In the absence of a dedicated bounty queue, researchers holding unfiled findings are effectively routed to each project's own security reporting process — issue trackers and responsible-disclosure contacts that continue to accept reports but carry no financial incentive attached. Those project-level processes are unchanged by Google's decision.
The stated cause: a flood of invalid reports
According to The Hacker News, the trigger was a surge in invalid automated reports entering Google's triage pipeline. The reporting available to us does not disclose how many submissions were filed, how many were deemed invalid, or what proportion Google attributed to automated tooling. Without those figures, it is difficult to assess whether the pause addresses a manageable spam problem or a triage operation under structural strain.
The carve-outs that remain in scope offer one interpretive clue — though this is analysis, not a claim from Google. Supply chain compromise reports stay eligible; pre-1 October submissions stay under review; other product vulnerability reports do not. That pattern suggests Google may be re-rating the cost of adjudicating report types rather than the severity of the underlying flaws: supply chain reports tend to be more specific and more clearly consequential, and therefore cheaper to triage than a high-volume stream of low-signal submissions.
What this signals beyond Google
The broader issue — automated and AI-assisted tooling producing large volumes of vulnerability reports at near-zero marginal cost, against human triage capacity that does not scale with them — extends well beyond Google's programme. Volunteer maintainers of widely deployed open-source libraries generally have no formal triage capacity: no dedicated security team, no dedicated queue, no easy way to distinguish a genuine finding from machine-generated output at speed. A well-resourced vendor reporting its own programme as overwhelmed makes that bottleneck visible for projects downstream that have no budget to pause in the first place.
The pause also raises a question the research community is likely to debate for some time. Bug bounty programmes reward verified, triaged vulnerabilities; a report-flood environment rewards volume. Closing the reward channel in response to spam penalizes genuine researchers alongside those generating noise.
What to watch
Google has not said when, or on what terms, the affected programmes might resume. Whether restructured submissions face stricter requirements — such as proof-of-concept or reproduction evidence — remains an open question, as does whether pre-1 October submissions receive rewards at all. For researchers holding unfiled product vulnerabilities against these projects, the practical position for now is straightforward: report through the project's own channels, document the finding carefully, and treat the bounty layer as offline until Google indicates otherwise.
據 The Hacker News 報導，Google 已暫停其漏洞獎勵計劃（Vulnerability Reward Programme）的發放，不再就一組開源項目的產品安全報告提供賞金，原因是無效的自動化報告大量湧現。
The Hacker News 報道指，該項變更已於 10 月 1 日生效。研究人員如就 Go、Angular 及 Protocol Buffers 等項目的代碼漏洞提交安全報告，將不再透過 Google 的計劃獲得賞金。據該報道所述，仍有兩類內容在受理範圍之內：涉及供應鏈（supply chain）入侵的報告，以及 10 月 1 日之前提交、目前仍在審核中的報告。
報告現在改由什麼渠道提交
Google 並未在公開層面為這些項目的產品層級漏洞指定一個替代的收件途徑。在沒有專門的賞金隊列之下，持有尚未提交發現的研究人員，事實上只能改走各項目自己的安全報告流程——包括 issue tracker 及負責披露（responsible disclosure）聯絡人，這些渠道仍會受理報告，但並沒有附帶任何經濟獎勵。這些項目層級的流程並未因 Google 的決定而改變。
官方所述的原因：無效報告湧現
據 The Hacker News 報導，導火線是大量無效的自動化報告湧入 Google 的 triage 流水線。現有報道並未披露收到多少份提交、其中多少份被判定為無效，以及 Google 認為有多大比例來自自動化工具。在缺乏這些數據的情況下，難以評估這次暫停應對的是一個可以處理的垃圾報告問題，還是一個結構上承受壓力的 triage 操作。
仍保留受理範圍的豁免項目，為解讀事件提供了一點線索——儘管以下屬分析性推論，並非 Google 的官方說法：供應鏈入侵報告仍獲受理；10 月 1 日前提交的報告仍在審核；其餘產品漏洞報告則不再受理。這個模式暗示，Google 可能正在重新評估審核不同類型報告的成本，而非重新評估漏洞本身的嚴重程度：供應鏈報告往往更為具體，後果亦更明確，因此 triage 成本比大量低訊號（low-signal）提交為低。
這件事超出 Google 範圍的啟示
更廣泛的問題——自動化及 AI 輔助工具以近乎零邊際成本產生大量漏洞報告，而人工 triage 能力卻無法隨之擴張——遠不止影響 Google 的計劃。廣泛採用的開源函式庫的義工維護者，一般缺乏任何正式的 triage 能力：沒有專職安全團隊，沒有專門的隊列，亦難以在短時間內分辨真實發現與機器生成輸出的虛實。一家資源充裕的供應商聲稱自己的計劃已不勝負荷，令這個瓶頸對下游項目清晰可見，而這些項目本來就沒有任何預算可供暫停計劃。
這次暫停亦引發一個研究社群相信會爭論一段時間的問題。漏洞獎勵計劃獎勵的是經過驗證、完成 triage 的漏洞；而報告洪流的環境則獎勵數量。以關閉獎勵渠道來應對垃圾報告，會令提交真實發現的研究人員與製造噪音者一同受罰。
接下來值得關注的事項
Google 並未透露相關計劃何時、以及會以什麼條件恢復運作。重構後的提交要求是否會更嚴格——例如要求提供概念驗證（proof-of-concept）或重現證據——仍屬未知之數，10 月 1 日前的提交是否仍會獲得獎勵同樣未有定論。對於手上有尚未提交產品漏洞的研究人員，目前的實際建議很簡單——透過項目自身的渠道提交，仔細記錄細節，並在 Google 另行通知之前，視賞金層面為離線狀態。