Bug Bounty Programs Are Dying. The Data Says Something Nobody Wants to Admit.

Google paused. Intel paused. curl quit. But the gap between what AI finds and what maintainers can fix is the real story.

I read the Cloud Security Alliance analysis on a Tuesday and felt something I hadn't expected: relief.

Not because the news was good. Because it explained the pattern I'd been watching for months.

Google paused its OSS VRP. Intel removed all financial rewards. curl ended its program entirely. The Internet Bug Bounty paused submissions.

Everyone blamed AI slop. I did too. I wrote about it. I thought I understood.

Then I read the CSA analysis and realized I was only seeing half the picture.

Two Problems That Look Like One

The CSA research note draws a distinction that changes everything.

Problem one: Noise. Invalid reports, fabricated findings, hallucinated functions. This is what everyone talks about. This is the "slop" narrative.

Problem two: Signal at volume. AI-driven discovery is finding real vulnerabilities faster than maintainers can fix them. CSA's Project Glasswing analysis found that AI-driven discovery identified more than 10,000 high and critical vulnerabilities in its first month. 1,596 were disclosed to maintainers. Only 97 had been confirmed patched — about 6%.

Read that again. The bugs are real. The patches aren't happening.

An independent assessment cited in the analysis found 90.6% of 1,752 assessed findings were valid.

That's not slop. That's a backlog.

The Two Failure Modes Interact

Here's what the CSA analysis makes clear: these problems aren't separate. They're compounding.

A maintainer who spends hours rejecting fabricated reports has less time to fix valid ones.

A maintainer facing a backlog of valid findings is less able to separate a fabricated report from a genuine one.

The noise consumes the capacity that should go to signal. The backlog makes the noise harder to identify.

And the solutions are different. A program closed for spam can reopen with better filtering. A program closed for lack of remediation capacity is unlikely to reopen on filtering improvements alone.

Google's pause is "temporary." They said they'll update in Q1 2027. But the CSA analysis asks the question nobody wants to answer: what if the problem isn't the reports? What if the problem is that we're finding bugs faster than we can fix them?

The Patch Capacity Crisis

The CSA research note includes numbers that reframe everything.

Microsoft's July and August 2026 Patch Tuesday releases contained 570 and 398 fixes respectively. Palo Alto Networks' NOVA system reported 14,090 previously unknown open-source vulnerabilities in two months.

14,090. In two months. From one system.

The Microsoft figures concern a single vendor's products. The NOVA figure is just one tool. Together, they illustrate the volume that patching processes now face.

And AI-generated patches? CSA notes they fail or introduce defects more than half the time.

The same tools that find the bugs can't reliably fix them.

What This Means for Beginners Like Me

I've written before about the numbers that make bug bounty feel hopeless. Microsoft's average payout dropping from $49,000 to $35,000. Intel closing its program. GitHub cutting public payouts.

Those numbers are real. But they describe one failure mode — the noise problem.

The CSA analysis describes something else: a system where discovery has outrun remediation. Where the bottleneck isn't finding bugs. It's fixing them.

For beginners, this changes the question.

The old question was: "How do I find bugs that AI can't find?"

The new question is: "How do I find bugs that someone can actually fix?"

A report for a bug that will never get patched is just noise with better intentions.

What I'm Doing Differently

I can't fix the remediation crisis. I can't force maintainers to patch faster. But I can change three things.

First, I'm prioritizing projects that have active maintainers. Not just any open-source project. Ones with recent commits, recent releases, recent security advisories. A finding on a project that hasn't shipped a patch in two years isn't going to get fixed.

Second, I'm treating "reproducible" as a higher bar than "valid." A valid bug that takes an hour to reproduce is less useful than a valid bug with a one-line PoC. The kernel's new guidance asks for reports with reproduction evidence and ideally a tested patch. That's the standard now.

Third, I'm remembering that the bottleneck isn't me. The CSA analysis says the unit of risk is the maintainer's time. My job isn't just to find bugs. It's to make the maintainer's job easier. Clear reproduction. Specific impact. Suggested fix. The thing that gets acted on, not the thing that gets added to a backlog.

The Uncomfortable Truth

Bug bounty programs aren't dying because AI generates bad reports. They're dying because AI generates good reports faster than humans can fix them.

The CSA analysis puts it plainly: bounty shutdowns "reduce the noise input and do nothing to reduce the volume of true findings, and they may reduce the number of human researchers who supply carefully validated ones".

Closing intake doesn't fix the backlog. It just hides it.

I don't know if the programs I'm learning on will exist in a year. But I know what the CSA data says: the bugs are real, the patches aren't happening, and the gap between discovery and remediation is the actual crisis.

My job isn't to find more bugs. It's to find the bugs that can actually get fixed.

If you're also learning bug bounty in a system where discovery outruns remediation, I write about what I'm actually figuring out. Follow for more field notes from the bottom of the learning curve.