GitHub tightens bug-bounty rules to prioritise high-quality security reports
- GitHub updated its bug bounty program to prioritise quality submissions and clarify shared‑responsibility boundaries across researchers and maintainers. (github.blog) - The blog post says GitHub will focus on higher‑impact reports and refine scope definitions to reduce low‑value noise in submissions. (github.blog) - The change signals platform emphasis on disciplined, well‑scoped security research and clearer responsibility boundaries for maintainers. (github.blog)
GitHub said on May 15 it is tightening how it handles bug-bounty submissions, with a simpler message to researchers: show real impact, stay inside scope, and validate findings before filing. (github.blog) The immediate change is not that GitHub is abandoning bug bounties. Jarom Brown, writing on GitHub’s security blog, said the company remains “deeply committed” to the program but is reacting to a surge in lower-value reports across the industry. GitHub said new tools, including AI, have lowered the barrier to entry for security research, increasing overall submission volume while also driving more reports that lack proof of concept, rely on theoretical attack chains, or fall into already ineligible categories. (github.blog) What GitHub is changing is the standard for what counts as a complete report. The company said it will evaluate submissions more strictly and wants a working proof of concept that demonstrates concrete security impact, not a hypothetical path that “could lead to” something. GitHub also said researchers are expected to review scope and ineligible findings before submitting, and to validate the output of any scanners, static-analysis tools or AI assistants they use. (github.blog) That matters because GitHub is explicitly warning that reports in known ineligible categories will be closed as “Not Applicable,” and that may affect a researcher’s HackerOne Signal and reputation. GitHub named examples including DMARC, SPF and DKIM configuration issues, user enumeration, and missing security headers without a demonstrated attack path. (github.blog) The shared-responsibility piece is also central. GitHub’s documentation already says the company cannot authorize testing of third-party systems in its name and cannot protect researchers from legal action by third parties if their work extends beyond GitHub-controlled assets. The new post pushes that boundary-setting further by stressing that platform-level security research has to distinguish between GitHub’s own responsibility and what belongs to maintainers, users or outside services. (docs.github.com) In practice, that means GitHub appears to be narrowing attention toward higher-confidence, higher-impact findings on assets it clearly owns or operates, while reducing time spent on speculative or weakly evidenced submissions. That last point is an inference from the company’s stated criteria and enforcement changes, rather than a separate new rule spelled out line by line. (github.blog) The backdrop is a program GitHub has spent years building. GitHub said in a June 2024 retrospective that its security bug bounty program began in 2014 and moved to HackerOne in 2016. That post also said GitHub expanded scope over time, increased payouts and used the program as a regular part of its product-security process. (github.blog) So the story here is less a shutdown than a reset in expectations. GitHub is telling researchers that volume alone is no longer enough: reports need evidence, demonstrated impact and a clear understanding of where GitHub’s responsibility starts and ends. Researchers who want the operational details can find them in GitHub’s May 15 blog post, its coordinated disclosure documentation and the program listing on HackerOne. (github.blog)
