Cybersecurity and AI · Google OSS VRP case
Google paused rewards for flaws in open-source software: too many reports to check
When someone finds a security flaw in open-source software, Google used to pay a reward for it. Since October 1, that payment for product flaws has been paused. The reason is a curiosity with consequences: it became too easy to send reports, and checking them is still human work.
In 30 seconds
- Since Oct 1, 2026, Google has not accepted new product flaw reports in the OSS VRP, the open-source software reward program created in August 2022. The news became public on Oct 5.
- The reason, according to Google (in a post on X cited by the press): a significant increase in automated submissions, the vast majority of them invalid. The translation is ours.
- The pause is temporary. Google promises an update in Q1 2027. Reports sent before Oct 1, supply chain reports, Patch Rewards (up to $15,000) and the Cloud VRP remain in force.
- Our reading: the cost of generating a report plummeted, and the cost of checking it did not. The one who checks is a person.
- Decision for the next 30 days: which open-source components underpin the company's systems, and who follows their security notices?
What happened
A bug bounty program works like this: a company promises to pay whoever finds a security defect and warns it before a criminal exploits it. The OSS VRP (Open Source Software Vulnerability Reward Program) is Google's version for open-source projects it maintains. It launched in August 2022, with rewards from $100 to $31,337.
In 2025, according to BleepingComputer, Google paid a record $17.1 million to more than 700 researchers, across all its programs, 40% more than the $12 million of 2024. In other words, the channel was thriving. In October 2026, part of it was paused.
- Oct 1, 2026: the OSS VRP stops accepting new product flaw reports. Reports sent before that date are not affected.
- Oct 5, 2026: BleepingComputer and Help Net Security report the pause and cite Google's explanation: "a significant rise in automated submissions, the vast majority of them invalid".
- Still in force: OSS VRP supply chain reports; Patch Rewards, which pays up to $15,000 for security improvements in Google's open projects; flaws in Google Cloud's open repositories, which may continue through the Cloud VRP; and Google's other reward programs.
- Q1 2027: the deadline Google gives for a program update.
Timeline
What is known and what is not
| Confirmed in the articles that cite Google | Not known, or our reading |
|---|---|
| Pause for product flaws in the OSS VRP since Oct 1, 2026. | How many reports arrived and what fraction was invalid: Google did not disclose numbers. |
| Stated reason: a rise in automated submissions, the vast majority invalid. | Whether those submissions were generated by AI. The press speaks of "AI slop", but Google's word is "automated". |
| Temporary pause, with an update promised for Q1 2027. | How the program returns and whether there will be new submission rules. |
| Patch Rewards, supply chain, Cloud VRP and reports from before Oct 1 continue. | Whether the pause actually reduces the number of flaws fixed. There is no data. |
| curl ended its bounty on HackerOne in January 2026 over low-quality AI reports. Intel withdrew cash rewards on Intigriti in mid-September. | Intel's reason: it did not explain, and the case cannot be linked to AI. |
Two reading cautions. (1) We read the official explanation through the articles, which cite Google's post on X. We could not read the program page in full, so we treat the text as quoted, not as seen at the source. (2) "Automated submission" does not necessarily mean "made by AI". The articles use both ideas, but Google says only "automated".
The math that does not add up, in a picture
Executive view: risk, gain and decision
Risk
- Users of open-source software lose, for now, a channel that paid people to find and report flaws in Google's projects. As the prize disappears, it is possible (our inference) that some researchers take their reports to other programs or stop sending them.
- Anyone with their own channel for receiving flaws, even just a security email address, runs the same risk on a smaller scale: the inbox fills up and hides the report that matters.
Gain
- The case is a good mirror. A well-designed triage process (who reads, by what criteria, within what time) becomes a speed advantage when volume rises.
- Requiring the minimum in the intake form (affected version, steps to reproduce, proof that the flaw exists) reduces noise without closing the door on good reports. Our recommendation, not a confirmed Google practice.
Decision for the next 30 days
- Which open-source components underpin our systems and who is accountable for them?
- Who follows the security notices for those components?
- If we receive flaw reports (from customers, partners or researchers), who reads them and how quickly do they respond?
Commercial application: where there is revenue, savings, advantage or brand and contract risk
- Brand: a company that promises a reward and leaves the queue unanswered loses credibility with security researchers. Google, at least, stated the date it will give news.
- Contract: anyone who buys or sells software should know whether the vendor maintains a channel for receiving flaws and what response time it promises. It is a simple question to ask at a renewal.
- Savings: fixing a flaw found early usually costs less than handling an incident. It is a common-sense rule and, here, without a number from a source.
Operational view: processes, people and routines
- Owner: one owner for the security channel, with a backup.
- Triage routine: written criteria to tell a complete report from an empty one, and a standard reply for each case.
- Sampling: if part of the triage is automatic, someone checks a sample of what was discarded. It is the same care as in the BeyondTrust case, seen from the other side: there a machine closed true alerts; here a machine generates excess reports.
- Capacity limit: know how many reports per week the team can read with quality, and what to do when it goes over that.
Infrastructure view: cloud, network, servers and dependencies
- Component inventory: a list of what the system uses underneath, including open-source libraries and their versions. This type of list is called an SBOM.
- Indirect dependencies: a component may depend on others. The flaw may be at the second or third level.
- Updates: a process for applying fixes to open components, with a window, testing and a rollback plan.
- Cloud: the Cloud VRP remains in force for Google Cloud's open repositories. Those who use these components should follow the vendor's notices.
Security view: prevent, detect and respond
Prevent
- Keep the component inventory and choose projects with active maintainers.
- When it makes sense, support the project: Google's Patch Rewards keeps paying for fixes.
Detect
- Subscribe to the security notices of the components the company uses.
- Follow announcements of changes to vendors' reward programs. Google's pause is one of those signals.
Respond
- Have a plan for when a flaw is found in an open component: who assesses, who updates, who communicates.
- Have a plan B if a vendor's reward channel changes or stops.
Technology view: how it works inside
The path of a report
- A researcher finds suspicious behavior in the code.
- They write a report: what happens, in which version, how to reproduce it and what the impact is.
- The triage team tries to reproduce it. If it cannot, the report is returned or rejected.
- If the flaw is real, it receives a severity, a fix and, in the end, the reward.
Where automation comes in
Automated tools and language models can produce texts that look like complete reports, with a file name, a code snippet and an explanation. What they cannot always do is prove that the flaw exists and can be exploited. For the person checking, a report that looks good and does not hold up costs almost as much time as a good one. This is our general explanation, consistent with the reason Google gave, but without numbers from Google.
Similar cases
In January 2026, curl, a widely used open-source project, ended its bounty program on HackerOne over low-quality AI reports, according to BleepingComputer. In mid-September, Intel withdrew cash rewards from its Intigriti program without explaining why. In Intel's case there is no basis to link the decision to AI.
Opinion: the most interesting part is the inversion. For years, the security problem was finding the few flaws. Here, the problem is separating the few real ones from a flood that looks like them.
For the general reader: what to do today
- Leave automatic updates on for your phone, computer and apps. Many flaw fixes arrive that way.
- Download apps only from official stores.
- Remember that a good part of apps and sites use open-source pieces. When a flaw is found, the fix arrives through the update.
Terms in this article
These terms should go into the channel's glossary. Until they are added, they are defined here.
- Bug bounty program
- A program in which a company pays whoever finds and reports a security flaw.
- OSS VRP
- Google's program that paid for flaws in open-source projects it maintains. Since Oct 1, 2026, it does not accept new product flaw reports.
- Free and open-source software
- Programs whose code can be read, used and changed by other people, according to each project's license.
- Triage
- Separating what is serious, what is noise and what needs more information, before acting.
- False positive
- A notice that looks like a flaw but is not.
- Software supply chain
- The set of components, tools and vendors that a piece of software depends on.
- Patch Rewards
- Google's program that pays up to $15,000 for security improvements in open projects.
- Cloud VRP
- Google Cloud's reward program.
- SBOM
- A list of the components that make up a piece of software, with their versions.
Sources
Primary
- Google Bughunters, open-source security section (programs page): bughunters.google.com/open-source-security. We could not read the pause notice in full; the official text is quoted in the articles below.
Journalistic
- BleepingComputer, Oct 5, 2026: Google halts open-source bug bounty program amid AI spam surge
- Help Net Security, Oct 5, 2026: AI slop submissions force Google to freeze its open-source bug bounty
- Technews, Oct 5, 2026: Google suspends open source vulnerability reward program
- Gigazine, Oct 5, 2026: Google froze open source bug bounty program
Technical discussions (context, not a source of facts)
- Hacker News (news.ycombinator.com) and r/netsec (reddit.com/r/netsec) often debate the excess of low-quality reports in reward programs.
Cross-check: where the sources differ
- Start date: BleepingComputer does not give the exact date of the pause and says reports sent before Oct 1 are not affected. Help Net Security and Technews indicate Oct 1, 2026. We adopted Oct 1.
- Cloud VRP: BleepingComputer says flaws in Google Cloud's open repositories may continue through the Cloud VRP; Help Net Security says some reports for certain repositories may continue. That is why we use "may".
- Numbers: no source gives how many reports arrived or how many were invalid. We use no numbers on this.
Final question
When AI produces more than can be read, who decides what matters? Reply by Instagram direct message to @techtraduzida and tell us how your team handles this point. If this content helped, follow the profile, like and share: it helps develop and spread the channel.