GitHub is raising the bar for bug bounty submissions to combat low-quality AI noise. This matters to engineers as it clarifies the shared responsibility model for platform security and sets a standard for validating AI-assisted security research and vulnerability reporting.
The security research community is one of GitHub’s greatest assets. Every year, researchers from around the world help us find and fix vulnerabilities, making the platform safer for over 180 million developers. Our bug bounty program exists because we believe that collaboration with external researchers is one of the most effective ways to improve security, and we remain deeply committed to it.
But like every bug bounty program, we’re adapting to a changing landscape. We want to share what we’re seeing, what we’re doing about it, and how we think about the security boundaries of a platform like GitHub.
Over the past year, submission volume across the industry has grown significantly. New tools, including AI, have lowered the barrier to entry for security research, which in many ways is a positive development. More people exploring attack surfaces means more opportunities to find real issues.
However, alongside the growth in legitimate reports, we’ve seen a sharp increase in submissions that don’t demonstrate real security impact. These include reports without a proof of concept, theoretical attack scenarios that don’t hold up under scrutiny, and findings that are already covered by our published ineligible list. This isn’t unique to GitHub. Programs across the industry are grappling with the same challenge, and some have shut down entirely.
We don’t want to go that direction. Instead, we want to invest in making our program better.
We’re raising the bar on what we consider a complete submission. Going forward, reports will be evaluated more strictly against these criteria:
We want to be explicit about this: we have no problem with researchers using AI tools. AI is a force multiplier, and we expect it to play an increasing role in security research. We use AI across our own internal security programs, and we’re seeing the best external researchers do the same. We welcome it.
What we need is the same standard we’ve always expected: validation. An AI-assisted finding that’s been verified, reproduced, and submitted with a working proof of concept is a great submission. An unvalidated output submitted as-is without reproduction or demonstrated impact is not. This isn’t a new standard. It’s the same standard we apply to scanner output, static analysis, or any other tool. The human researcher is accountable for the accuracy of the submission.
We’d also ask researchers to keep reports concise and structured. A strong report has three things: a short summary of the issue, clear steps to reproduce with supporting evidence (screenshots, HTTP requests, terminal output), and an impact statement explaining what an attacker can actually achieve. That’s it. Verbose reports such as multi-page theoretical narratives, restated background context, or AI-generated filler slow down triage because the actual finding gets buried. The clearer and more direct your report, the faster we can act on it.
The tools don’t matter. The quality of the work does.
One pattern we see frequently deserves its own discussion. Many reports describe scenarios where a user interacts with attacker-controlled content (a malicious repository, a crafted issue, untrusted code) and experiences an undesirable outcome. These reports are often well-written and technically accurate in their observations, but they misunderstand where the security boundary lies.
We invest heavily in systems and teams dedicated to detecting and handling malicious content across the platform, from automated scanning to manual review. That said, GitHub operates on a shared responsibility model. Users are responsible for:
When an “attack” requires the victim to actively seek out and engage with attacker-controlled content (cloning a malicious repo, asking an AI tool to analyze untrusted code, opening a crafted file), 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.
To help researchers calibrate, here are patterns we see regularly 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 extremely valuable. If you think you’ve found a blind spot in our defenses (a way to bypass an actual security control that affects users without requiring them to actively trust malicious content), that’s exactly what we want to hear about. Those findings are some of the most impactful submissions we receive. And if you come across content that violates our Terms of Service, please report it.
If you’re already submitting quality research, thank you. Nothing changes for you except faster response times as we reduce queue noise.
If you’re newer to bug bounty, welcome! Take a few minutes to read our scope, review the ineligible list, and invest in a working proof of concept before submitting. Quality submissions from new researchers are always valued and appreciated.
If you’ve been prioritizing volume, we’d encourage a shift toward depth. One well-researched, validated finding is worth more than 10 speculative ones, both in bounty payout and reputation. The researchers who earn the most from our program are the ones who go deep.
Not every valid submission represents a meaningful security risk. Some reports identify hardening opportunities or documentation gaps that, while not exploitable, still lead to improvements we choose to make. We appreciate that work.
Going forward, we’re updating how we handle these cases. 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 lets us acknowledge the contribution while focusing our bounty resources on the findings that have the greatest impact on platform security.
We’d rather see researchers invest their time in deeper, high-impact research and be compensated accordingly than optimize for volume on low-risk findings.
We’re committed to making GitHub’s bug bounty program one of the best in the industry, for researchers and for the security of the platform. That means faster triage, clearer communication, and ensuring that valid findings get the attention and compensation they deserve. Raising quality standards is part of that investment.
Security researchers make GitHub safer for every developer who depends on it. That work matters, and we don’t take it for granted.
Happy hacking! 🚀
The post Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program appeared first on The GitHub Blog.
Continue reading on the original blog to support the author
Read full articleUnderstanding secure authentication is fundamental for any developer. SSH keys and PATs replace insecure password-based workflows for Git operations, while 2FA protects the account itself. Mastering these tools ensures code integrity and prevents unauthorized access to repositories.
GitHub Universe 2026 highlights the shift toward agentic workflows, where AI agents become core collaborators in software development. For engineers, it's a chance to move from AI demos to practical, integrated workflows while networking with peers solving similar scale problems.
AI is evolving from simple autocomplete to autonomous agents that handle complex SDLC tasks. GitHub's leadership highlights the shift toward orchestrating outcomes rather than just writing code, promising significant productivity gains and better governance for enterprise engineering teams.
These laws could force developers to implement complex age-tracking APIs and centralized data collection. For open source contributors, this creates significant compliance burdens and conflicts with decentralized norms, potentially altering how software is distributed and accessed.
