Google Paused a Bug Bounty Over an AI Report Flood, and Triage Is Now the Bottleneck

For most of the last decade the scarce resource in vulnerability management was discovery. Finding a real flaw took skill and time, which is why companies paid bounties for it. That has inverted. On October 1 Google suspended its open-source bug bounty, and the reason it gave was not that researchers had stopped finding things. It was that machines had started finding too many things, most of which were not real.

The scarce resource is now validation: an engineer confirming that the flawed code exists, that an attacker can reach it, and that the impact is worth a maintenance window. AI has made reports cheap to produce. It has not made them cheaper to check.

Three Programmes, One Problem

Google's statement, reported by Infosecurity Magazine, pointed to “a significant rise in automated submissions, the vast majority of which are not valid.” The programme, launched in August 2022, paid between $100 and $31,337 for flaws in Google-owned open-source repositories and their GitHub configurations. Supply-chain reports and anything already submitted are unaffected, and Google says it plans to reformat the programme with an update in the first quarter of 2027.

The pause was the end of a sequence rather than a sudden decision. CSO Online notes that Google tightened its open-source rules in March after a sharp rise in AI-generated submissions, started demanding reproducible results or accepted patches for some vulnerability classes, and stopped rewarding certain lower-tier reports. Some submissions made incorrect claims about how a flaw could be triggered. Others flagged genuine coding defects with little practical security impact.

GitHub took a different route to the same place. In July it restructured its programme into two tiers to deal with what it called “low-effort and AI-generated reports.” Public payouts fell to $250 for a low-severity finding and a maximum of $10,000 for a critical one, down from up to $30,000. An invite-only tier keeps the high rewards for researchers with a record of valid findings, and newcomers get up to four submissions before a signal requirement applies. The stated goal was “reducing the noise so we can focus on the signal.”

Vercel shows the scale on a smaller canvas. During a two-week challenge for its Sandbox environment in September it received 1,285 vulnerability reports, automated parts of the triage, and validated dozens. That is a usable outcome, but only because Vercel built a filter before the reports arrived.

The Real Findings Are Rising Too

It would be convenient to treat all of this as spam. It is not. AI-assisted discovery is also producing a lot of genuine vulnerabilities. In an analysis of the top 20 CVE numbering authorities, VulnCheck recorded year-to-date increases in published CVEs of 563% for Chrome, 476% for GitHub's open-source advisories, 181% for VMware and 170% for Apache. The same analysis carries a caution: curl's maintainer reviewed five “confirmed” vulnerabilities reported by an AI model and found that only one held up as a valid CVE.

Both trends land on the same desk. Every true positive needs a fix, and every false positive needs a human to prove it false. And the code those fixes go into is increasingly machine-written. Veracode's 2026 GenAI Code Security Report found roughly 44% of AI code-generation tasks introduced a risky vulnerability, with an average security pass rate of 56% that has barely moved since the first edition. Citing its own State of Software Security data, Veracode puts security debt at 82% of organizations, with critical debt at 60% and high-risk vulnerabilities up 36% year on year.

“The next competitive advantage will not come from finding more vulnerabilities faster. It will come from determining more quickly which ones pose a real risk and which ones do not.”

Sunil Varkey, CISO, speaking to CSO Online

Why This Is an Enterprise Problem, Not Just Google's

Few enterprises run a public bounty at Google's scale, but most now run something that behaves like one: an AI code scanner, an AI-assisted penetration test, a vulnerability disclosure inbox, or a vendor feed that grew several times larger this year. IDC research director Sakshi Grover told CSO Online that “a larger findings dashboard is not, by itself, evidence of better security,” and that CISOs should judge AI tools by actionable findings and validation effort rather than raw counts.

There is a security angle as well as a workload one. Bhupendra Chopra of Kanerika warned that an unfiltered reporting channel could let attackers consume a team's capacity on purpose, and Grover flagged that malicious reports could carry prompt-injection instructions aimed at the AI agents now doing first-pass triage. A submission is untrusted input. If an agent reads it with access to anything that matters, the intake queue has become an attack surface.

The warning sign Chopra describes is easy to measure and rarely tracked: analysts spending more time rejecting weak findings while confirmed high-risk vulnerabilities stay open longer.

What Security and Engineering Leaders Should Do Now

• Measure validation effort, not finding counts. Track the hours spent confirming or rejecting each finding and the age of confirmed high-risk exposures. Those two numbers show whether a new AI tool is helping or simply adding volume.
• Require evidence at intake. Follow Google's lead and ask for a reproducible proof or a reachable code path before a report enters the queue. A claim without a reproduction is a hypothesis, and it should be ranked like one.
• Treat every submission as untrusted input. Keep AI triage agents away from production systems and credentials, and have a person confirm any action an agent recommends on the basis of submitted text or code.
• Reward proven reporters. GitHub's two-tier model concentrates money and attention on researchers with a record of valid findings. The same logic applies to internal tooling: weight sources by their historical precision.
• Rank by reachability and exposure. A lower-severity flaw on an exposed, business-critical system can deserve faster action than a critical one in code that is never deployed.
• Budget remediation alongside discovery. More findings do not create more engineering capacity or maintenance windows. Any spend on AI discovery that is not matched by fix capacity grows the security debt instead.

Google did not pause its programme because AI failed to find bugs. It paused because finding bugs stopped being the hard part, and the organizations that adjust fastest will be the ones that start measuring the part that still is.