今日已更新 240 条资讯 | 累计 23823 条内容
关于我们

Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program

Natalie Guevara 2026年05月15日 22:00 6 次阅读 来源:GitHub Blog

We're updating our bug bounty program standards to prioritize quality submissions, clarify shared responsibility boundaries, and evolve how we reward low-risk findings. The post Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program appeared first on The GitHub Blog .

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. The volume problem 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. What makes a strong submission We’re raising the bar on what we consider a complete submission. Going forward, reports will be evaluated more strictly against these criteria: A working proof of concept with demonstrated security impact. Show us the impact, don’t just describe it. What could an attacker actually achieve? We need a working proof of concept that demonstrates real exploitation and concrete security impact. Show us the boundary that can be crossed, not just that one theoretically exists. If your report says
本文内容来源于互联网,版权归原作者所有
查看原文