← Latest reporting

Google’s paused bug bounty turns reproducibility into an intake skill

Google says most of a surge in automated open-source vulnerability reports was invalid. Security teams should meter evidence cost before treating submission volume as researcher productivity.

Work and Role ChangePolicy, Standards and Governance
A flat screen-printed queue of many rough vulnerability slips narrows through a reproducibility stencil into one traceable evidence path, with rejected fragments left visibly outside.
Conceptual illustration generated with AI under editorial direction; it does not depict a real event.

What happened

Google paused its Open Source Software Vulnerability Rewards Program on October 1 and said it would update the programme in the first quarter of 2027 after a rise in automated, mostly invalid submissions.

Why it matters

Automation can lower the cost of producing plausible reports faster than maintainers can reproduce them. Intake quality therefore depends on proof, triage cost and accountable escalation.

Google’s OSS VRP rules page states that the programme is paused. TechCrunch reported that the pause took effect October 1, with an update promised in the first quarter of 2027. Google attributed it to a significant rise in automated submissions, the vast majority of which were not valid.

That is evidence of an intake failure, not evidence that automation cannot find vulnerabilities. The report does not publish the number of submissions, the invalidity taxonomy, reviewer hours, false-negative rate or the share produced by particular tools. The pause also concerns one Google programme, not bug bounties generally.

Price the proof burden before opening the queue

Require every automated report to include a minimal reproducibility packet: affected version and commit, isolated trigger, expected versus observed behaviour, deterministic reproduction count, environment, impact boundary and a human submitter who can answer follow-up questions. Route unverified hypotheses to a separate low-priority lane rather than the reward queue.

Track reviewer minutes per accepted finding, duplicate rate, invalid reasons and time to safe closure. Preserve both accepted and rejected samples so later audits can test whether the gate filtered noise without hiding useful edge cases. A model that triples submissions while doubling accepted findings can still reduce programme capacity if reproduction cost rises faster.

The counterargument is that strict evidence requirements discourage novel reports. Preserve an exception lane for high-consequence hypotheses, but make a maintainer explicitly sponsor the extra investigation cost. The immediate decision is to pilot a costed proof gate on one vulnerability intake channel before reopening high-volume automation.