Google's Bounty Pause Puts the Verification Bill in View

Google has closed one route for reporting security flaws, not declared that security research is finished. Its Open Source Software Vulnerability Reward Program stopped accepting new product-vulnerability submissions on October 1. That is a consequential restriction for researchers working on Google's open-source projects. It is also narrower than a shutdown of the entire program. Supply-chain reports remain eligible, and submissions made before the cutoff are unaffected. Some findings involving Google Cloud repositories may still qualify through the Cloud program. Google promises an update in the first quarter of 2027, not a reopening on a specified date.

The useful question is what a report must deliver before it becomes somebody else's work. A plausible explanation of a dangerous bug is not the same thing as evidence that the bug exists, can be reached and matters in the software being used. Treating those as interchangeable makes the recipient responsible for completing the research. This is our reading of the operational problem behind the pause: the value of faster discovery depends on how much verification and repair capacity accompanies it. A system that produces more allegations without resolving them can leave the maintainer with a larger queue rather than a safer release.

Tom's Hardware independently reported the suspension on October 3 and linked it to an influx of invalid AI-assisted submissions. Google's own earlier explanation provides firmer detail about the problem categories. In its March 19 rules update, the company described reports inventing conditions that would trigger a vulnerability, alongside reports identifying real coding errors with negligible security impact or unreachable code paths. Those are different failures. The first needs factual correction. The second requires understanding the application's security assumptions. Better grammar or a longer report does not resolve either one. The sources establish Google's diagnosis, not an independently measured failure rate for every AI security tool.

Google had already tried raising the admission standard. The March update required exact OSS-Fuzz reproduction steps using an existing target, or a merged patch, for memory-corruption reports in its flagship and important project tiers. An April revision removed rewards and credit for product vulnerabilities and other security issues in the lower tiers. That history matters because October's restriction did not arrive before any attempt to demand better evidence. It followed an effort to make certain submissions more actionable. The policy sequence alone cannot tell us whether that effort failed, reduced workload or excluded valuable findings. Google has not supplied those comparative results in the notices examined here.

A reproducer changes the handoff from a claim about code into an experiment another person can run. OSS-Fuzz's documentation describes a testcase containing the input bytes delivered to a fuzz target. Reproduction depends on building the target with the appropriate sanitizer and configuration; some bugs appear only under a particular architecture. Its Docker workflow can replicate build steps before replaying the input. After developing a local fix, the maintainer can run the testcase again to check whether the crash remains. This is concrete engineering work. It is materially different from attaching a model's explanation of what might happen to a code excerpt.

Even that experiment does not answer every question. Reproducing a failure under a test harness should lead to a separate account of the affected boundary: which input an attacker can control, what execution path accepts it and what consequence follows. A local crash without that account should not automatically be presented as a remotely exploitable vulnerability. Conversely, inability to reproduce something with the first build should not prove that the report is imaginary. Configuration can matter. For teams evaluating research tools, the useful artifact is therefore a repeatable test with its assumptions intact, accompanied by an impact argument that reviewers can challenge.

The remaining supply-chain category illustrates another boundary in Google's rules. It concerns compromising source or distributed build artifacts, including through release infrastructure or publishing credentials. Google requires an exploitable path rather than a scenario that only works after a maintainer approves a contribution. For researchers, these distinctions should determine where an investigation belongs. Relabeling a product defect as a supply-chain problem is not a substitute for demonstrating the relevant capability. For program operators, the distinction suggests a practical intake design: request the evidence appropriate to the claimed failure, instead of using a single impressive-sounding severity description as the entry ticket.

Open-source maintainers have already described how this burden changes incentives. In January, curl founder Daniel Stenberg announced the end of the project's monetary bug bounty, effective January 31. He reported that the program had produced 87 confirmed vulnerabilities and paid more than $100,000, but that the confirmation rate had fallen from above 15 percent to below 5 percent during 2025. He attributed the deterioration to low-quality AI reports and worsening human behavior, including arguments over severity without corresponding repair work. Those are his reported program figures and assessment. They are not a controlled comparison of AI against unaided researchers, or a representative measurement of every open-source project.

Stopping the history there would make the argument much too convenient. In an April 22 follow-up, Stenberg said the situation had changed after curl returned to HackerOne in March. He described junk reports as no longer the problem, incoming volume at roughly twice the 2025 rate and the confirmed-vulnerability share back around 15 to 16 percent. He believed almost all the reports used AI to some degree, while acknowledging that reporters rarely identified the tools. That is a maintainer's assessment, not audited provenance. It nevertheless supplies an important counterexample to the claim that AI assistance necessarily produces useless findings.

Stenberg's newer concern was the workload created by better findings arriving faster. That distinction should shape the response to Google's pause. Filtering invented reports and processing real vulnerabilities are different capacity problems. A team could solve the first and still have more legitimate repair work than it can handle. Removing a financial incentive, changing a reporting platform and improving research tools can also happen together; the curl account does not isolate which change caused the improvement. It would be a mistake to advertise bounty removal as a proven universal fix. The defensible lesson is to track both report quality and the ability to finish the resulting work.

Google's alternative Patch Rewards program places the emphasis on accepted improvements. Its current rules cover security hardening in eligible projects, including memory-safety work, rather than promising payment for every isolated defect. A patch must be accepted upstream and remain unreverted for a month before submission. Patches more than twelve months old are ineligible, and the rules limit each person to three submissions per month while encouraging batching. Qualifying patches in OSS-Fuzz-integrated projects can be eligible, but new integrations and fuzz harnesses are not covered by that provision. The rewards panel retains discretion and can share a reward with maintainers when their contribution warrants it.

This is not an effortless replacement income stream for displaced bounty hunters. It asks for a different contribution and depends on the project accepting it. The practical incentive is to arrive with a change that the upstream team can keep, rather than only a finding it must investigate. That creates a question worth asking of any reward design: does the payout acknowledge the work required on the receiving side? A patch author may do excellent research while still requiring substantial maintainer review. Programs should make that dependency visible instead of treating the handoff as the point where the cost disappears.

Google is pursuing a technical version of the same shift. In a July 29 announcement, it described combining OSS-Fuzz with CodeMender to propose fixes from crash details and source context. The company says proposed changes are checked in an isolated environment for compilation, resolution of the crash and regression-test behavior. During the beta, Google engineers also review patches. The announced coverage is memory-safety vulnerabilities in eligible C/C++ projects, with patches attached when available. Google says the process respects repository policies restricting AI contributions and allows projects to opt out. These are the vendor's description and commitments, not independent proof that every proposed patch is correct.

The design is useful precisely because it does not treat the model's confidence as the final check. A patch can silence a testcase while changing behavior that users depend on. Review should therefore ask both whether the reported failure disappeared and whether the intended functionality remains. Testing offers evidence for that judgment, not a guarantee of universal correctness. The recipient also needs the ability to decline the contribution. A project that has chosen not to accept AI-generated code should not have to spend its scarce review time rejecting repeated submissions from a system claiming to help it.

For builders selling security automation, the pause is a reason to change the demonstration. Show an investigator's path from a suspected issue to a reproducible result, then show what another engineer must still do. Separate invalid reports, duplicate findings, genuine defects without security impact and vulnerabilities that need remediation. Measure the time spent by the receiving team as well as the time saved by the scanner. Those are proposed evaluation standards, not performance results from Google's program. They make the buyer's question more demanding than how many findings the tool can generate, but also more relevant to whether adopting it improves security.

The open question for Google's next update is how it will preserve useful outside research while limiting work that contributors have not validated themselves. The answer need not be a blanket judgment for or against AI. The evidence here spans fabricated reports, reproducible bugs, accepted patches and higher-quality findings that still strain maintainers. Each needs a different response. Researchers should follow the current program scope, and product teams should build verification and repair into their handoffs. A bounty creates an invitation to contribute. Keeping that invitation viable requires contributions that leave the people responsible for the software with less unresolved work.

LaunchPad positionEvaluate security automation by reproducible evidence, accepted fixes and the work left for maintainers, while following each program's current scope.