GitHub Bug Bounty Gets Stricter

GitHub is elevating its bug bounty program, signaling a shift towards more rigorous standards for security researchers. The move aims to address a surge in submissions lacking demonstrable impact, a trend observed across the industry.

The company, a cornerstone for developers worldwide, is emphasizing quality and shared responsibility in its security efforts. This update to the GitHub bug bounty program reflects a growing need to manage the evolving threat landscape.

Raising the Bar on Submissions

Going forward, GitHub requires submissions to include a working proof of concept that clearly demonstrates security impact. Theoretical scenarios or reports without concrete exploitation will be deemed incomplete.

Researchers are now expected to thoroughly review GitHub's scope and ineligible findings list before submitting. Submissions covering known ineligible categories will be closed as 'Not Applicable', potentially affecting a researcher's standing.

Validation remains paramount, regardless of the tools used, including AI assistants. An AI-assisted finding must be verified, reproduced, and accompanied by a working proof of concept to be considered a strong submission.

The company is not discouraging AI use in research.

Concise, structured reports are preferred, featuring a brief issue summary, clear reproduction steps with evidence, and an impact statement. Lengthy, theoretical narratives or filler content slow down the triage process.

Shared Responsibility in Focus

GitHub is also clarifying the concept of shared responsibility, particularly concerning user interactions with potentially malicious content. The platform hosts millions of repositories, and users are expected to exercise judgment.

This includes reviewing content before execution, understanding the implications of cloning repositories, and securely configuring personal environments. Scenarios requiring user action to engage with attacker-controlled content generally do not represent a bypass of GitHub's security controls.

Common examples under shared responsibility include prompt injection via content users choose to input and issues arising from executing untrusted code from repositories.