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:

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:

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:

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

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). Just find and report a bug to our HackerOne bug bounty program and you're entered to win. 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 Dec. 14, 2020 (that's a new date!) 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

30天免费试用极狐GitLab专业版

极狐GitLab不仅是源代码管理或CI/CD工具,它是一个覆盖完整软件开发生命周期和DevOps的开放式一体化平台。

免费试用
Git为Software Freedom Conservancy的注册商标,GitLab为GitLab B.V.的注册商标,我们已获授权使用“极狐GitLab”。

免费试用极狐GitLab 30天

有疑问? 联系我们

Gitlab x icon svg