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, 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, 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). 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:
{::options parse_block_html="true" /} Why does a keyboard work 24 hrs a day?
Because it has 2 shifts! Badum bum 🥁
Happy hacking!
