GitLab Bug Bounty Program policy updates

GitLab first introduced our HackerOne Bug Bounty program in 2018. Since then, we’ve worked with the researcher community to help secure our comprehensive AI-powered DevSecOps platform. We're excited to announce policy updates to the program that reflect our commitment to transparency, feedback from researchers, and our ongoing efforts to provide clear expectations and streamlined processes.

What's changing

Here is what you need to know:

Enhanced testing guidance

We're placing stronger emphasis on local testing environments to protect both researchers and our production infrastructure. We're strongly recommending local GitLab Development Kit (GDK) testing for most security research. The GDK gives you access to cutting-edge features before public release and the freedom to experiment without production infrastructure concerns.

If you need to demonstrate denial-of-service (DoS) impact, we recommend testing on a self-managed GitLab instance with specifications and resources equal to or greater than the self-managed GitLab installation requirements.

For vulnerabilities requiring GitLab.com production architecture, you must use test accounts created with your HackerOne email alias: [email protected].

Refined scope for better focus

We've clarified several scope areas based on community feedback:

DoS is out of scope: Exceptions may be considered for application layer DoS vulnerabilities that achieve persistent total service disruption AND can be executed through unauthenticated endpoints. Some examples include ReDoS, logic bombs, etc.

Prompt injection: Standalone prompt injection is out of scope, but prompt injection may be eligible if it serves as an initial vector to achieve harm beyond its security boundary.

Metadata and enumeration: General information gathering remains out of scope while privacy breaches exposing confidential data are in scope. We've provided new, detailed examples distinguishing between these two types of issues on the program policy page.

Transition period for researchers

We recognize that policy changes can create uncertainty for researchers with active investigations. To maintain trust during this transition and avoid disrupting valuable research already under way:

• GitLab is offering a 7-day grace period for DoS reports submitted before 2026-01-22, 9:00 p.m. Pacific Time (2026-01-23T00:05:00Z). Reports submitted before then will be evaluated under our previous policy.

Your investment in GitLab's security matters to us, and we're committed to honoring the policy under which you began your research.

Our commitment to the community

These changes reflect our deep commitment to the researcher community through three key principles.

1. We're prioritizing transparency by establishing clearer boundaries and objective criteria that reduce ambiguity and prevent disputes.

2. We're enhancing safety through improved testing platform guidance that protects both production systems and researchers from accidental service disruption.

3. We're ensuring fairness through consistent evaluation standards and provisions that guarantee equitable treatment for all researchers, including those already in the program.

Scope refinements also support program sustainability by focusing resources on high-impact security issues while maintaining broad coverage.

Get started

Ready to contribute to GitLab's security?

• New researchers: Visit our HackerOne program page.
• Set up local testing: Download the GitLab Development Kit.
• Review full policy: Check our complete documentation for detailed guidelines.
• Understand severity assessment: Explore our CVSS calculator.

We're grateful for the security research community's ongoing partnership in keeping GitLab secure. Your expertise and dedication make a real difference for millions of users worldwide.

Questions about these changes? Reach out to our team by creating an issue in our HackerOne questions project on GitLab.