The Strength of the Security Research Community
The security research community remains one of GitHub’s greatest assets. Every year, researchers from around the globe help us uncover and fix vulnerabilities, protecting over 180 million developers who rely on the platform. Our bug bounty program was built on the belief that collaborating with external researchers is one of the most effective ways to strengthen security, and we remain deeply committed to that mission.
But like every program, we must adapt to an evolving threat landscape. We want to share what we’re observing, how we’re responding, and how we think about the security boundaries of a platform like GitHub.
The Challenge of Rising Submission Volume
Over the past year, the number of submissions across the industry has grown dramatically. New tools—including AI-powered scanners—have lowered the barrier to entry for security research. In many ways, that’s a positive development: more people exploring attack surfaces means more opportunities to discover real vulnerabilities.
However, alongside the increase in legitimate reports, we’ve seen a sharp rise in submissions that lack real security impact. These include reports without a proof of concept, theoretical attack scenarios that don’t hold up under scrutiny, and findings that are already listed in our published ineligible categories. This trend isn’t unique to GitHub; programs across the industry are wrestling with the same issue, and some have chosen to shut down entirely.
We don’t want to go that direction. Instead, we want to invest in making our program better and more efficient for everyone.
Raising the Bar: What Makes a Strong Submission
We’re raising the bar on what we consider a complete and actionable submission. Going forward, reports will be evaluated more strictly against these core criteria:
Working Proof of Concept with Demonstrated Impact
Show us the impact—don’t just describe it. What could an attacker actually achieve? We need a working proof of concept that demonstrates real exploitation and concrete security impact. Show us the boundary that can be crossed, not just that one theoretically exists. If your report says “this could lead to…” but doesn’t show that it does, it’s incomplete.
Awareness of Scope and Ineligible Findings
Before submitting, review our scope and ineligible findings list. Reports covering known ineligible categories—such as DMARC/SPF/DKIM configuration, user enumeration, missing security headers without a demonstrated attack path, and others—will be closed as Not Applicable, which may impact your HackerOne Signal and reputation.
Validation Before Submission
No matter what tools you use—scanners, static analysis, AI assistants—you need to validate the output before submitting. A false positive that’s been manually reviewed is caught before it wastes anyone’s time. One that hasn’t is just noise.
We Welcome AI in Security Research
We want to be explicit: we have no problem with researchers using AI tools. AI is a force multiplier for good, helping researchers find vulnerabilities faster and more efficiently. But the same responsibility applies: every AI-generated finding must be verified manually before submission. The tool is an assistant, not a replacement for critical thinking.
Shared Responsibility for a Better Program
Improving the program isn’t just about stricter criteria—it’s about shared responsibility. Researchers who invest time in understanding our platform, testing thoroughly, and providing clear evidence will continue to see faster triage, higher bounties, and stronger partnerships. Meanwhile, we’re investing in better tooling and processes to make sure quality reports get the attention they deserve.
We believe this approach will lead to a healthier ecosystem for everyone: researchers who produce quality work will be rewarded, and GitHub’s billions of users will be better protected. The future of our bug bounty program is about collaboration, accountability, and raising the bar together.