Sep 28, 2020 - Heather Simpson    

Our top tips for better bug bounty reports, plus a hacker contest!

Our AppSec team breaks down what makes a great bug bounty report. That advice comes just in time, as we're having another bug bounty contest.

We recently wrote an article with tips on how to build and run a successful bug bounty program in the hopes that the processes and practices we’ve built would help other organizations go from zero to sixty as quickly as possible.

But, the truth is, a bug bounty program will be a non-starter if you can't attract talented security hackers to join you.

The reporters in our program bring an immense depth and breadth of expertise and research, represented in the unique and innovative findings they deliver and the thoughtful reports they submit.

🎉 For these reasons and more, we’re excited to announce that we’re once again holding a community hacking contest! See more details below and we look forward to your contributions! 🚀

But when we think about the reports that researchers submit to our program, questions come up. What makes a report stand out, makes it helpful, makes it…for lack of a better word…good? We asked two of our Application Security engineers, who work to triage, investigate and test within our bug bounty program, for their frank thoughts on bug bounty reports.

What makes for a better bug bounty report?


Vitor Meireles De Sousa Headshot

Vitor Meireles De Sousa, senior security engineer, application security team

We often see reports with an incomplete description of the initial setup, or ones missing the step-by-step instructions necessary to reproduce it. This often leads to multiple, potentially unnecessary, time-consuming exchanges with a reporter or our AppSec team exploring different settings attempting to reproduce the report (or trying to get as close as possible to reproducing it.) Screenshots or videos are a great way to document the issue and can help avoid situations like this.

In my mind, a good report is a combination of the following:

  • A thorough description of the configuration used and a detailed step-by-step to reproduce the issue – this significantly helps us in triaging the report as fast as possible with a minimum of questions regarding the requirements and how to exploit the vulnerability.
  • A properly rated severity and impact analysis – when triaging reports, we typically use the severity rating to prioritize one report over another. Frequently we see reports that are overrated in severity. I think it is really important to understand how our team applies severity. Becoming familiar with our HackerOne policy and particularly the ‘How severity is determined’ section can help reporters provide an accurate impact analysis and by extension, appropriate severity ratings.

What’s an example of a report that exemplifies these criteria?

This report, “Injection of http.<url>.* git config settings leading to SSRF” from security researcher, vakzz has:

  • A comprehensive description of the issue
  • A detailed step-by-step with precise instructions on how to reproduce it
  • A clear impact analysis that justifies the severity of the report

And remember, it doesn’t need to be a long report to be a good one.


Dominic Couture Headshot

Dominic Couture, Senior Security Engineer, application security team

I like to see the following things in a report:

  • A detailed description of how the vulnerability is triggered
  • Information outlining what happens when it is triggered –this helps us know if we’ve reproduced it correctly
  • Simple steps to reproduce the vulnerability
  • A description of the impact of the vulnerability

To take it a few steps forward, here’s what makes a great report:

  • Details about the specific code causing the vulnerability
  • Scripted (Bash, Ruby, etc.) reproduction steps if it makes sense for that bug
  • For complex bugs, a video can aid understanding, but this should not replace the written steps to reproduce

I would also like to note that a vulnerability report is not like a write-up that you’d post on your blog. Including details about anything that isn’t directly related to the vulnerability itself are great for a “story” about how you found the bug, but they add noise to the report and should be left out (and saved for that blog post).

What’s an example of a report that exemplifies these criteria?

This report: SSRF on project import via the remote_attachment_url on a Note (and really all reports by vakzz mentioned above) ticks all the boxes above and falls firmly in the great report category. Additionally, there’s good communication from the reporter throughout the process and that’s the optimal triage experience for us.

Celebrating great reports, and great reporters

We had so much fun recognizing you – the amazing hackers who contribute to our program – last year when we celebrated our one year anniversary of taking our bug bounty program public that we’re doing it again.

Two-year anniversary hacking contest

We are running a community hacking contest starting October 1 (4 am UTC) until November 30, 2020 (4 pm UTC). The top contributor in the following categories will receive a special reward:

Most reputation points from submissions to our program. Collect the most reputation points from submissions to our program and win!

Most reputation points collected by a reporter new to our program. Getting started with a new bug bounty program is difficult. This one goes out to all the new reporters out there.

Best written report. See above. A well-written report goes a long way to demonstrate impact and to help us reproduce the problem efficiently and accurately.

Most innovative report. Sometimes reporters demonstrate true out-of-the-box thinking in their approach to finding bugs. We appreciate this creativity.

Most impactful finding. At the end of the day, these high-risk, high-reward vulnerabilities are what we’re all looking for.

The winners will be announced on December 14 via a GitLab blog post. A contributor can win at most one category. Of course, regular bounties still apply to any of your findings.

And, because everyone needs a laugh … here's a joke that hints at a little something the winners will get:

Why does a keyboard work 24 hrs a day?

Because it has 2 shifts! Badum bum 🥁

Happy hacking!

Cover image by meo on Pexels

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg