Why GitHub is tightening its bug bounty standards
GitHub’s bug bounty program draws on a global community of security researchers who help secure a platform used by over 180 million developers. The company remains committed to that collaboration, but it is adapting to a changing landscape — one defined by a surge in submission volume across the industry and an increasing number of reports that lack real security impact.
The rise in submissions is partly driven by new tools, including AI, which have lowered the barrier to entry for security research. While GitHub sees this as a positive development, it has also led to a sharp increase in reports that don’t hold up: submissions without proof of concept, theoretical scenarios that don’t survive scrutiny, and findings already covered by the program’s published ineligible list. Other programs have responded to this pressure by shutting down entirely. GitHub says it is choosing instead to raise the quality bar.
What a complete submission looks like
Reports will now be evaluated more strictly against three criteria:
- A working proof of concept with demonstrated security impact. Researchers must show what an attacker can actually achieve, not just describe a theoretical boundary crossing. A statement like “this could lead to…” without evidence that it does will be treated as incomplete.
- Awareness of scope and ineligible findings. Before submitting, researchers should review the scope and ineligible findings list. Known ineligible categories — including DMARC/SPF/DKIM configuration, user enumeration, and missing security headers without a demonstrated attack path — will be closed as Not Applicable, which may affect a researcher’s HackerOne Signal and reputation.
- Validation before submission. Regardless of whether the work comes from scanners, static analysis, or AI assistants, the output must be verified before it is submitted. A manually reviewed false positive wastes no one’s time; an unvalidated one is simply noise.
GitHub is explicit that it welcomes AI use in security research and considers it a force multiplier. It uses AI across its own internal security programs and sees top external researchers doing the same. The expectation is unchanged: an AI-assisted finding that has been verified, reproduced, and submitted with a working proof of concept is a great submission; an unvalidated output that has not been reproduced or shown to have impact is not. The human researcher remains accountable for accuracy.
Researchers are also asked to keep reports concise. A strong report has three components: a short summary of the issue, clear reproduction steps with supporting evidence (screenshots, HTTP requests, terminal output), and an impact statement explaining what an attacker can achieve. Multi-page theoretical narratives, restated background context, and AI-generated filler slow down triage because the finding gets buried.
The shared responsibility boundary
A recurring pattern in reports involves “attacks” that require a user to actively engage with attacker-controlled content — a malicious repository, a crafted issue, or untrusted code — and then experience an undesirable outcome. These reports are often well-written and technically accurate in their observations, but they misunderstand where GitHub’s security boundary lies.
GitHub invests in systems and teams dedicated to detecting and handling malicious content, from automated scanning to manual review. But the platform operates on a shared responsibility model. Users are responsible for:
- Choosing which repositories, issues, and code they trust. GitHub hosts over 600 million repositories, and not all are benign. Users are expected to exercise judgment about what they interact with.
- Reviewing content before executing or interacting with it. This applies to code, scripts, workflows, and any other executable content.
- Understanding that cloning a repository means choosing to trust that code. Git hooks, build scripts, and other repository-level automation execute because the user chose to check out that repository.
- Configuring their own environment securely. Token management, credential storage, and local security settings are the user’s responsibility.
When an “attack” requires the victim to seek out and engage with attacker-controlled content, the security boundary is the user’s decision to trust that content. These scenarios generally don’t represent a bypass of GitHub’s security controls. The table below illustrates common patterns that fall under shared responsibility.
| Scenario | Why it’s shared responsibility |
|---|---|
| Prompt injection via content the user chose to feed to an AI tool | The user decided to trust that content |
| Git hooks or filters executing code in a repo the user checked out | This is how Git works by design |
| Malicious content in a repository the user cloned | Cloning is an act of trust |
| LLM producing unexpected output when processing untrusted input | The user chose to provide that input |
Research in these areas is still valuable, but the program is most interested in findings that bypass an actual security control affecting users without requiring them to actively trust malicious content. Those are among the most impactful submissions GitHub receives. Content that violates GitHub’s Terms of Service should be reported rather than submitted to the bounty program.
What changes for researchers
Existing researchers who already submit quality work should see little change except faster response times, as queue noise is reduced. Newer researchers are encouraged to read the scope and ineligible list and to invest in a working proof of concept before submitting; quality submissions from newcomers are valued. For those who have been prioritizing volume, GitHub suggests shifting toward depth: one well-researched, validated finding is worth more than ten speculative ones, both in bounty payout and reputation. The highest earners from the program are the researchers who go deep.
There is also a change in how low-risk findings are rewarded. Submissions that don’t demonstrate significant security impact but do result in a code or documentation fix will be recognized with GitHub swag rather than a bounty payout. This is intended to acknowledge the contribution while focusing bounty resources on findings with the greatest impact on platform security.
GitHub states its goal plainly: faster triage, clearer communication, and a program where valid findings get the attention and compensation they deserve. Raising quality standards is part of that investment.
