Google left its open-source supply-chain bounty lane open when it stopped accepting product-vulnerability reports on October 1. That split matters for developers and security researchers: the company is filtering one class of report that became cheap to generate and expensive to disprove, while preserving an intake path for flaws that can compromise how software is built or distributed.
The pause followed what Google called a significant rise in automated submissions, the vast majority of them invalid, according to TechCrunch's report. Google plans to post an update in the first quarter of 2027. Reports filed before October 1 will still be handled, and some flaws in Google Cloud repositories may qualify under the separate Cloud Vulnerability Reward Program.
This is a narrower action than the shorthand version of the news suggests. Google's Open Source Software Vulnerability Reward Program, or OSS VRP, has two distinct concerns: weaknesses in open-source products and weaknesses in the supply chain around them. The current program notice keeps supply-chain submissions open during the pause. Researchers can still report an exposed release credential, a compromised build route, or another flaw that threatens package delivery, provided it meets the rules.
The closed lane covered real code
When Google launched OSS VRP in August 2022, it covered current software in public repositories owned by Google organizations and certain third-party dependencies. Bazel, Angular, Go, Protocol Buffers, and Fuchsia were named as sensitive projects. Awards originally ranged from $100 to $31,337, depending on the severity of the flaw and the importance of the affected project.
The launch post welcomed supply-chain compromises, product-level design issues, leaked credentials, weak passwords, and insecure installations. That breadth gave researchers several ways to improve code people use far beyond Google. It also created a large surface for speculative findings. A scanner can flag a suspicious function or dependency in seconds. Establishing that an attacker can cross a security boundary in the product may take hours of setup, source reading, and failed reproduction attempts.
Google has not published the number of automated reports it received, how quickly the volume rose, or the share produced with a particular model or tool. The company's wording is automated submissions, while the TechCrunch account describes the problem as AI submissions. Those descriptions overlap, but they are not identical. A scripted static analyzer can automate discovery without a language model, and a person can use a model to improve a report without automating the submission.
Most of the new automated intake was invalid. That makes the failure rate more informative than the label on the tool. A polished report can name a source file, produce a plausible attack story, and assign a severe rating while missing a permission check elsewhere in the call path. The maintainer must still inspect the real code and configuration to prove the proposed path cannot occur.
Cheap reports still cost maintainers time
Bug bounties have always attracted weak reports because a valid finding can pay. HackerOne's submission rules now address the changed ratio between the work needed to submit and the work needed to reject. Generative tools can turn one uncertain scanner warning into a full narrative, complete with remediation advice, faster than a maintainer can build the affected project. The prose may look ready for triage even when the exploit path has never run.
The cost lands unevenly. A submitter can send the same broad technique across many repositories. Each receiving team has to understand its own trust boundaries, default settings, version history, and existing mitigations. In curl's case, the work needed to debunk weak reports contributed to the end of its monetary bounty. A claim that is almost right can consume more time because the reviewer has to find the condition that makes it harmless.
HackerOne's current code of conduct draws the line at verification rather than AI use. It permits AI throughout research, including reconnaissance and proof-of-concept development. The reporter remains responsible for a reproducible finding with demonstrated impact. Its rules prohibit high-volume low-signal submissions, fabricated claims, and technical details invented by a model. Hackbots must keep a human investigator in the loop.
That policy offers a useful standard for anyone preparing a report during Google's pause. Run the claimed path against an in-scope version. Record the exact preconditions and observed result. Check whether a documented mitigation blocks the attack under normal settings. Then reduce the proof to the smallest safe reproduction a reviewer can reproduce. A model can assist with any of that work, but its explanation cannot substitute for the observed behavior.
Curl found that incentives changed the queue
The curl project provides a useful comparison because it published numbers before changing its own bounty. In January 2026, lead maintainer Daniel Stenberg ended curl's monetary bug bounty after the confirmed-vulnerability rate fell from more than 15 percent in earlier years to below 5 percent in 2025. The program had previously produced 87 confirmed vulnerabilities and paid more than $100,000, so the decision also gave up a channel with a proven record.
Curl kept accepting private security reports. It briefly moved intake to GitHub, returned to HackerOne in March, and offered no reward. By April, Stenberg reported a different problem: the obvious junk had receded, yet valid reports were arriving faster than the small team could comfortably process them. AI-assisted research remained part of that new flow. Removing the cash incentive reduced one kind of noise without removing the human bottleneck.
That sequence argues against treating every machine-assisted finding as disposable. Automated analysis can locate real memory errors, unsafe state transitions, or overlooked combinations across a large codebase. The burden should move to the submitter before the report reaches a maintainer. Curl's higher-quality flow shows that evidence and judgment can survive the use of AI, even when a bounty does not.
Google's remaining supply-chain lane reflects the same logic. A compromised publishing credential or a demonstrated path to alter a release has an observable boundary and consequence. Product-level claims often depend on a longer chain of assumptions about how code is called and deployed. Pausing that category buys Google time to redesign its gate around evidence, reputation, rate limits, or some combination of them. Google has not said which controls it will choose.
Google's 2027 test is triage cost
A useful replacement should make the first reviewer spend less time discovering whether the reporter ever ran the attack. HackerOne currently requires reproducible impact, while Google could add limits that rise with a researcher's accepted-report history or a preliminary validation stage before a report reaches project maintainers. Each choice has a cost. A demanding exploit requirement can exclude legitimate design flaws, while reputation gates can make entry harder for a skilled newcomer.
The pause also creates a security tradeoff. Closing a noisy channel protects maintainer attention, but a researcher with a valid product flaw now needs another eligible Google program or must wait for new instructions. Google's notice points researchers toward its other reward programs and leaves some Google Cloud repository findings in the Cloud VRP. Anyone reporting during the gap needs to check scope before testing or disclosing.
Google's first-quarter update will be worth reading for operational details rather than a broad verdict on AI security research. Watch whether Google publishes submission and acceptance rates, requires an executable proof for product flaws, and explains who absorbs the initial validation work. The pause began because generating a convincing claim became easier than checking it. Google's fix can be judged by two numbers, if it publishes them: the share of submissions that survive first review and the maintainer time spent reaching that decision.