techlist.io
KREN
github

Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program (opens in new tab)

githubgitai-securitystatic-analysisapplication-securityprompt-injectionbug-bountyvulnerability-disclosure

GitHub is reaffirming its commitment to external security researchers while tightening bug bounty submission standards. Rising report volumes—partly driven by AI and other tools—have increased both valuable findings and unvalidated noise. GitHub’s central message is that tools are welcome, but researchers remain responsible for validating vulnerabilities, demonstrating impact, and understanding the platform’s shared security boundaries.

Rising Submission Volume

  • New tools, including AI, have lowered the barrier to security research and expanded the number of people examining attack surfaces.
  • GitHub has also seen more reports that:
    • Lack a working proof of concept
    • Describe only theoretical attack scenarios
    • Concern categories already listed as ineligible
  • Because this challenge affects the wider industry, some bug bounty programs have shut down; GitHub instead plans to improve its program.

Requirements for Strong Reports

  • Submissions must include a working proof of concept demonstrating concrete security impact.
  • Researchers should show what an attacker can actually accomplish, rather than merely describing a possible attack path.
  • Reports must respect GitHub’s published scope and ineligible findings list. Examples of generally ineligible issues include:
    • DMARC, SPF, or DKIM configuration problems
    • User enumeration
    • Missing security headers without a demonstrated attack path
  • Scanner, static-analysis, or AI-generated findings must be manually validated before submission.
  • Unverified false positives create unnecessary triage work and may affect a researcher’s HackerOne Signal and reputation.

AI Is Welcome, but Validation Is Required

  • GitHub supports the use of AI in security research and uses AI internally.
  • AI-assisted reports are acceptable when findings are reproduced, verified, and supported by a working proof of concept.
  • Researchers remain accountable for the accuracy of their submissions, regardless of which tools produced them.
  • GitHub recommends a concise report structure:
    • A short issue summary
    • Clear reproduction steps and evidence, such as screenshots, HTTP requests, or terminal output
    • An impact statement explaining what an attacker can achieve
  • Lengthy theoretical explanations and AI-generated filler can obscure the actual vulnerability and slow triage.

Shared Responsibility and GitHub’s Security Boundary

  • GitHub protects users through automated scanning, manual review, and other systems for detecting malicious content.
  • Users are still responsible for deciding what repositories, issues, code, and scripts to trust.
  • Users should review content before executing or interacting with it.
  • Cloning a repository is considered an act of trust because Git hooks, build scripts, and other automation may run locally.
  • Users must also secure their own environments, including tokens, credentials, and local security settings.
  • Scenarios generally do not bypass GitHub’s security controls when they require victims to deliberately engage with attacker-controlled content.

Common Shared-Responsibility Scenarios

  • Prompt injection in content a user intentionally provides to an AI tool
  • Git hooks or filters executing code from a repository the user checked out
  • Malicious content in a repository the user chose to clone
  • Unexpected LLM output caused by untrusted input supplied by the user

Research into these areas remains useful when it identifies a way to bypass an actual GitHub security control without requiring the user to actively trust malicious content.