Whoever is on bug bounty duty is responsible for all
operational work that week, as well as continuing progress
on any strategic improvements to your program.
Chapter 2.2.3: Brace yourself, bugs are coming
In addition to setting up an on-going rotation, you’ll want to clear
out the calendars of your BBT for the first week when you launch.
There’s often a large spike in activity at the launch of a program
(like Yelp experienced), and this is also the time when you’ll quickly
identify and course correct for any hiccups in your program.
Chapter 2.2.4: Choose your platform
Fortune 500 companies like Qualcomm, and hot tech
companies like Uber, deploy bug bounty programs with the
help of a bug bounty platform. It’s possible to run a program
in-house, but things like tracking status of reports, processing
payments, and attracting and maintaining relationships with
top hacking talent is a lot easier with a bug bounty platform.
I may be a little biased, but I’ve heard this “HackerOne” thing is
pretty great; I mean, you could try to recruit 85,000 hackers on
your own… or you could sign up for HackerOne to quickly and easily
access the largest pool of top hacking talent in the world. But
don’t take my word for it – see what our customers have to say.
Before real bug reports start flowing in, familiarize yourself
and the rest of your BBT on how to use the HackerOne
platform. If you’ve signed up for Professional or Enterprise,
a HackerOne specialist will help train your team.
Chapter 2.3: Bounty Process
One of the first questions most people have when starting a
bug bounty program is, “how much is this going to cost?” Not
surprisingly, one of the first answers you’ll usually get is “it depends!”
There a wide variety of factors to take into consideration,
such as your initial scope, how you assess severity, and
whether you are running a pilot vs. an ongoing program
We have a great post on our blog: Anatomy of a Bug Bounty Budget for a deep dive on
this topic, but feel free to continue reading for high-level guidance.
Chapter 2.3.1: Bounty Tables
The simplest way to approach this is to set up a bounty table. A bounty table
illustrates how much you are willing to pay for various bugs, helps set expectations for
hackers, and gives you and your team a guideline to ensure fair and consistent reward
amounts.
Typically you want to pay out based on the severity of the issue identified. HackerOne
provides CVSS (Common Vulnerability Scoring System) scoring in-platform to assist
with this. Both hackers and teams can use CVSS to calculate a severity, or simple pick
one from Low, Medium, High, or Critical.
Available in every product tier, we show you the average award amounts across the
hundreds of programs on our platform. Integrated with the recently launched CVSS
severity setting on reports, our Bounty Statistics feature automatically shows you
the median bounty across our platform for that severity, as well as what programs at a
competitive and top level are paying out. Here’s an example of bounty statistics for a
Medium severity report:
I’d recommend starting with around (or slightly above) the median
values. It’s best to ramp up your bounties as bug scarcity increases,
as opposed to going too big initially. Once you have a feel for your
flow of bugs, you can increase your bounty ranges. Higher bounties
results in more attention, especially from higher ranked hackers
with polished skill sets.
This is a great starting point, but it’s always great to refine further
over time based on the issues that matter most to you. For
example, perhaps you would pay little to nothing for XSS on a
sandboxed domain with no sensitive content or functionality, but
would pay top dollar for an XSS on your flagship website.
For example, Twitter splits their scopes into “core” properties
and “all other,” then outlines what typical bounties look like for
different classes of bugs based on their impact. At the time of
this writing, an XSRF on a “core” property on a “critical action” will
net a $2,500 bounty, but any other XSRF on a non-core property results in a much
lower bounty of $140. Money talks! This is a great example of using bounty structure
to incentivize hackers to target and report the issues you care the most about.
Bounty amounts are certainly a hot topic, but HackerOne arms you with
data and access to experts in order to come to the best conclusion.
For those who want that extra insight and consultative approach, our
Professional, Enterprise, and Fully Managed customers have access to a
HackerOne representative who will walk you through the entire process
Chapter 2.3.2: Define your bounty awarding process
So you’ve settled on how much to pay for various types
of bugs. But how do you actually pay out?
Without HackerOne, you and your finance / ops team will have to manage the
ENTIRE process. This includes compliance (like OFAC and AML laws), taxation
(getting W9s from hackers, issuing 1099s at the end of the year), covering
processing fees, dealing with currency exchange rates, and other messy logistics.
All this to pay a bounty to a Hacker. Imagine dealing with that
100x over, with different countries around the world!
Thankfully, our no-hassle bounty platform handles all of this for you!
HackerOne’s payment process is painless – you can either set up a prepaid balance
to pay bounties out from, or add a credit card to your account for payments. After
you’ve done that, it’s as simple as defining a bounty amount on the report
Chapter 2.4: Determine your Service Level
Agreements
It may seem counterintuitive, but running a bug bounty
program is akin to providing a service to hackers who
participate in your program. The most successful
bug bounty programs have well-defined service level
agreements (SLAs) that they share with hackers on their
rules/policy page. The three big SLAs to consider are:
- Time to triage / response on a new report
- Time to bounty (after validation)
- Time to remediation
Let’s spend a minute to look at each of
these categories a little closer:
Time to triage / response on a new report depends
on the resources available to you, your team’s expertise
level, the sophistication or esoteric nature of the bug,
and your report volume. HackerOne recommends
an SLA of two business days for time to triage.
In his Hacker Herding blog post, Dan Adams, Web Application
Security Specialist at Sky Betting and Gaming suggests to
timebox triage. He says, “It’s essential therefore in order
to keep to pre-agreed SLAs (and deliver on those hacker
expectations) to clearly delineate and set aside time dedicated
to triaging and progressing vulnerability reports.”
Time to bounty (after validation) depends on which payout model
you choose. Some of our top programs pay bounties within a few
days of report receipt! At a minimum, I recommend determining
and issuing a bounty within 1-3 weeks from time of triage
Time to remediation depends greatly on the severity of the issue and
the complexity of the fix. Of these three SLAs, time to remediation
probably has the most wiggle room, but it’s still very important! Security
only improves when bugs are fixed, not when they are found, and
many hackers participate in bug bounties because they want to see
security improve as a result of their work. HackerOne recommends
the following SLAs for remediation timelines based on severity:
• Critical = 1 day
• High = 1-2 weeks
• Medium = 4-8 weeks
• Low = 3 months
Chapter 2.5: Craft your policy/rules page
Transparency between hackers and security teams is vital to a
successful bug bounty program. The “front door” for hackers to
any bug bounty program is the security page, which commonly
contains your disclosure policy, rules of engagement, scope,
and other important information. Twitter, Uber, Snapchat,
Coinbase, and Mail.ru (among many others!) have great security
pages that incorporate elements outlined in this guide.
Three benefits of having a rock solid security page include:
• It steers hackers towards the scope and
vulnerabilities you care most about
• It sets clear expectations around bounty pricing and timelines
• You garner more trust (and participation!) from top hackers
At a high level, you should ensure your rules
page includes the following elements:
- A well-defined scope
- Bounty structure
- Qualifying vs. non-qualifying vulnerabilities
- Service level agreements
- Eligibility/participation requirementS