GitHub Tightens Bug Bounty Standards Amid Flood of Low-Impact Submissions

GitHub Overhauls Bug Bounty Rules: Proof of Concept Required, Scope Filters Tightened

GitHub is rolling out stricter submission criteria for its bug bounty program in response to a sharp rise in low-quality reports, including many generated by AI tools. The company now requires a working proof of concept demonstrating real exploitation—not just theoretical impact—and warns that incomplete submissions will be closed as 'Not Applicable,' potentially damaging researchers' HackerOne reputation.

'We want to invest in making our program better, not shut it down,' a GitHub spokesperson told reporters. 'The security research community remains one of our greatest assets, but the bar for a valuable submission must be higher.'

Background

GitHub’s bug bounty program has long relied on external researchers to help secure its platform, which serves over 180 million developers. However, over the past year, submission volume surged industry-wide, partly due to AI tools lowering the barrier to entry. While more researchers probing attack surfaces can uncover genuine vulnerabilities, the increase has also brought a flood of reports lacking security impact—no proof of concept, theoretical scenarios, or findings already on the ineligible list.

Other programs have shut down entirely under similar pressure. GitHub says it wants to avoid that outcome and instead raise quality standards.

What’s Changing: New Submission Requirements

1. Mandatory Proof of Concept

Reports must include a working proof of concept that demonstrates real exploitation and concrete impact. 'Show us the boundary that can be crossed, not just that one theoretically exists,' the company stated. Submissions that say 'this could lead to…' without evidence will be deemed incomplete.

2. Strict Scope Adherence

Researchers must review GitHub’s published ineligible findings list before submitting. Categories such as DMARC/SPF/DKIM configuration, user enumeration, and missing security headers without a demonstrated attack path are automatically closed as 'Not Applicable,' which may affect a researcher’s Signal and reputation on HackerOne.

3. Validation Before Submission

Regardless of tools used—scanners, static analysis, AI assistants—researchers must manually validate output. 'A false positive that’s been manually reviewed is caught before it wastes anyone’s time. One that hasn’t is just noise,' the company said.

AI in Security Research: Welcomed but Not Excused

GitHub explicitly welcomes AI tools in security research. 'AI is a force for good in our industry,' the spokesperson added. 'But using AI doesn’t absolve researchers from verifying their findings. The burden of quality remains on the submitter.'

What This Means for Researchers

For the research community, the changes mean higher standards for acceptance and a greater need for due diligence. Submitters should ensure their reports include demonstrable impact, fall within scope, and are validated before hitting 'send.' Failure to do so could lead to rejection and a lower HackerOne reputation score, potentially affecting future interactions with other programs.

GitHub expects that stricter criteria will reduce noise for its security team, allowing them to focus on genuine vulnerabilities. The company reaffirmed its commitment to the program, emphasizing that collaboration with external researchers remains a cornerstone of its security strategy.

Industry Context

GitHub’s move mirrors a broader trend among bug bounty programs. As AI-generated submissions multiply, platforms are scrambling to maintain signal amid noise. Some have already pulled the plug; GitHub is betting that higher entry requirements will keep its program viable and valuable.

Researchers who adapt to the new rules—producing well-validated, impactful reports—will likely find their submissions rewarded and their reputation enhanced. Those who don’t may see their reports closed without payment.