Bug Bounty First Impressions

The first week of your bounty program can be the most critical. The decisions you make around bounties, how long it takes to reply to a report, and even just what you say (or don't say!) can make all the difference in whether hackers will love your program and become ongoing contributor, vs. running away in terror (and Tweeting about it, to boot)! Ultimately, you are competing with other programs for the attention of the best hacker talent out there, so putting your best foot forward in the first few weeks can make a world of difference.

If you’re about to start (or recently started) your program, here’s some quick advice for a smooth takeoff.

1. Don't cheap out!

Take a few minutes to look around https://hackerone.com/hacktivity/popular to see what other programs are actually paying for different types of bugs based on scope and impact. Everyone's budget is unique, but trying to stretch a small budget by paying small amounts for big issues will result in a poor reputation for your program.

If someone finds a bug that most people would pay $1,000-$2,000 for, pay it!

It may seem counter-intuitive, but exhausting your budget early is not a bad thing. It warrants happy hackers that will continue to contribute solid issues to your program, as well as gives you great results which you can bring back internally to push for additional budget by demonstrating how successful your program is chugging along.

2. Over communicate!

One of the biggest causes of misunderstandings between hackers and security teams is a lack of communication. The first stop for any hacker participating in a bug bounty program is your rules page, and we already have some great advice here on how to craft that. It’s incredibly important to consider things from the hacker’s perspective, and to step outside of your shoes as an “insider” on the security team of your company. You have a ton of useful knowledge that can help hackers use their time most efficiently, which results in happier hackers, and better results for your program.

Examples include:

• What scopes do you care about most? The least?
• Protip! If you receive reports on scopes you aren’t interested in, add an “Out of Scope” section to your rules page!
• Will you pay more for important scopes? Will you pay less than typical value for low value scopes?
• What types of bugs do you care about the most?
• How far (or not) do you want a hacker to go with vulnerabilities they identify? Is an error message on a SQLi the limit, or are you okay with the hacker demonstrating xp_cmdshell is available?
• Do you want similar reports grouped into one ticket, or do you prefer individual reports for an issue that appears in multiple places?

Without proactively communicating your preferences, hackers will end up shooting in the dark. Proactively communicating your preferences in your rules page and messaging to hackers will help guide them towards the most efficient use of their time and result in far less misunderstandings.

3. Be ready!

Another important thing to keep in mind is that at the launch of any program, you’re going to be inundated with a huge wave of reports. Some might be amazing, some might be “meh,” some might be duplicates - but ready or not, here they come! It’s incredibly important to ensure you have staff on hand with enough cycles to triage the first incoming waves of reports. Being caught with tons of work and no one to do it is never a great feeling, and will result in burnout for both you and your team. Clearing out calendars and setting aside time for your launch is a best practice. Even better, set up a weekly on-duty or interrupts rotation where one person is always “on call” to handle triage of any reports that come in, filing bugs internally for valid issues, helping determine bounty amounts, and pushing forward vulnerability remediation timelines for any known issues from your program. Sharing the load and having a defined “bug bounty leader” each week will help immensely with smoothly handling the operational aspects of your program. Additionally, this will ensure hackers get responses in a timely manner, and that they don’t feel like they’re shouting into a canyon. Programs that respond quickly and courteously will keep their hackers coming back for more.

4. Over communicate!

...wait, didn’t we cover this already? Well yes, we did, but it’s so important it made the list twice! In addition to communicating your preferences in your rules page, it’s incredibly important to continuously over communicate in your day-to-day interactions on every single report. Once you’re in the thick of it, you’ll have loads of reports to reply to, and it may become tempting to give quick and dirty answers in order to drive through the heap and move on. Don’t do it! Remember there’s an individual capable of finding vulnerabilities for you behind every one of these reports. It’s important to explain why and how you’ve come to your decision on each report, whether it’s closing as informative, or paying a bounty.

This isn’t an all encompassing guide, but hopefully these key tips will help get you on your way to a successful launch, as well as thriving, ongoing bug bounty program.

Got any other tips or thoughts on what to consider when launching a bug bounty program? Let us know! Email us at feedback@hackerone.com, or hit us up on Twitter @hacker0x01 with the #bugbountylaunch hashtag.

-Adam Bacchus

HackerOne is the #1 hacker-powered security platform, helping organizations find and fix critical vulnerabilities before they can be criminally exploited. As the contemporary alternative to traditional penetration testing, our bug bounty program solutions encompass vulnerability assessment, crowdsourced testing and responsible disclosure management. Discover more about our security testing solutions or Contact Us today.