The End of the Bounty Spray-and-Pray: Inside GitHub's New Rules
It’s no secret that AI tools have turned bug bounty hunting into a gold rush for automated scanners. If you’re a security engineer today, you know the drill: your triage inbox is clogged with thousands of low-impact, sometimes hallucinated reports that require human eyes to sort through. This shift reflects a wider movement across developer platforms, as seen when Codeberg restricted AI-generated content to preserve high-quality human collaboration.
GitHub, arguably the most important home for the world’s code, has finally hit a breaking point. They have announced a sweeping overhaul of their bug bounty program—a move that marks the death of the "spray-and-pray" era for many, and the beginning of a much harder, more selective regime for everyone else.
The message from GitHub? They’re sick of the sludge, and they’re willing to rewrite the rules to make sure they’re only paying for meaningful, validated, human-powered research.
GitHub's Two-Tiered Future
The core of this restructuring is a pivot toward a two-tiered bounty ecosystem. GitHub isn't abandoning the public, but it is effectively building a "walled garden" for the serious players.
By formalizing a permanent, invite-only VIP program, GitHub is creating a premium experience for the researchers who actually know the platform's quirks. These folks aren't just scanning for easy wins; they are doing deep, architectural research.
This isn't just about paying more. It’s about building a better working relationship. VIP researchers get:
- Higher, more predictable payouts.
- Faster response times from GitHub’s internal teams.
- A direct channel to the engineers who actually build and secure the platform.
It’s clear: GitHub wants to treat this as a partnership, not a simple service transaction.
The New VIP Standard
So, how do you get into this inner circle? The criteria are stiff, and intentionally so. It’s not about being a famous name in the security community; it’s entirely based on your track record of delivering quality.
According to GitHub’s new rules, you need a proven history of success. To qualify, you must have achieved at least one of the following:
- One critical finding
- Two high-severity findings
- Four medium-severity findings
- Seven low-severity findings
This effectively disqualifies anyone who relies on mass-scanners to pump out hundreds of minor issues. GitHub is essentially telling the community, "Show us you can find the hard stuff, or stay in the sandbox."
Public Bounties: Why Static is Better
The public bounty program, meanwhile, is being squeezed. GitHub is slashing public payout rates to discourage low-effort submissions, and they’re moving to a static, fixed-rate model for every severity level.
Why move away from ranges? Because ranges create noise and, frankly, they’re messy to negotiate. When a program promises a payout "between $500 and $5,000," every researcher assumes they deserve the $5,000. When they get $500, it creates friction, disappointment, and a lot of unnecessary back-and-forth for the triage team.
Static payouts set clear, hard expectations from the jump. GitHub has set the rates for the public program:
- Low: $250
- Medium: $2,000
- High: $5,000
- Critical: $10,000
In sharp contrast, the VIP rewards top out at over $30,000 for critical issues and start much higher for everything else. The signal is unmistakable: if you want the big money, you need to be in the VIP club.
Hard Caps and Signal-Based Screening
The most aggressive change is the implementation of a "signal requirement" for newcomers. If you don’t have a history on the platform, you’re now facing a hard limit on how many reports you can submit.
You get four initial, unrestricted tries. After that, if you haven’t proven your skill, you're locked out. This isn't just to keep beginners out; it’s to prevent the automated tools from filling the inbox. If your scanner is spitting out garbage, you’ll burn through your four attempts in a matter of hours—and then you’re done.
It’s a brutal, effective way to force researchers to actually validatetheir findings before hitting submit.
What "Shared Responsibility" Really Means
This entire overhaul is deeply tied to GitHub’s "shared responsibility" security model. They’ve been championing this for a while, but now it’s baked into the bounty program’s economics.
Submitting unvalidated scanner output isn't helpful. If it doesn't show a clear, actionable proof-of-concept that maps to a real platform vulnerability, it’s not being treated as a bug—it’s being treated as an administrative nuisance.
Reports that lack this rigor will be marked "Not Applicable" (N/A). And in the new system, N/A reports are a penalty to your signaling and your standing, jeopardizing your chances of ever making it to the VIP tier.
The Path Forward for Serious Researchers
GitHub has made a calculated gamble. They know this friction will push away a portion of the bounty-hunting population—the ones who treated bug bounties like a slot machine.
But their bet is that it will raise the average quality of the reports they do receive. As frontier AI models demonstrate elevated cyber capabilities, maintaining rigorous standards for human security reports becomes even more essential. By making the entry barrier higher and the rewards for the "best of the best" more lucrative, they are refining their talent pool.
This isn't the end of bug bounties; it’s the evolution of them. We’re moving away from the "volume equals bounty" model, and toward a "skill equals bounty" model. If you want a future on the GitHub platform, it’s time to stop scanning and start researching.
For serious researchers, these changes are a clear signal that the time for deep, deliberate exploration has arrived. Happy hacking—if you can back it up.
(Sources: The Register, GitHub Blog 2026-07-22, GitHub Blog 2026-05-15)
