In the past several weeks, we’ve been addressing bug bounty misconceptions in our guide, 7 Bug Bounty Myths, Busted. So far we’ve…

  • Discussed the misconception that bug bounties are all public
  • Examined the types of companies engaging with the bug bounty model
  • Debunked the perception some have that bug bounties are too risky
  • Talked about the white hat hackers who participate in bug bounty programs
  • Analyzed the kinds of results they yield

Today we’re talking about the budget.

Myth #6: Bug bounties are too costly and hard to budget for.

Many perceive bug bounty programs to be ‘blank check affairs’ and to some extent that has been true for organizations like Microsoft and Google. However, this model doesn’t work for everyone. Today, by being diligent and thoughtful, or by working with a trusted partner, you can easily control your bug bounty budget.
This is not to say that bug bounty programs are cheap. We know that the cost of fixing a bug is significantly higher in production than in development or pre-release testing. The fact is, bug bounty programs catch vulnerabilities that slip through, and in order to successfully find them, you must attract the right researchers. Often, attracting the right talent includes offering rewards. Without guidance, offering rewards and managing a budget for a bug bounty program presents organizations with a set of unknowns–a legitimate concern that can be easily mitigated by tweaking the many knobs and levers found in the modern bug bounty model.
Bugcrowd works with organizations of all kinds and sizes at different stages of security maturity to optimize the use of a bug bounty program for their unique needs, maximize the success of their program and minimize unknown variables such as cost. In general, this can be broken down into (1) what you want to test, (2) how you want to test it and (3) what incentive model you want to utilize.

1. Articulate what you do and don’t want to be tested

The only way to articulate to researchers what you do and don’t want to be tested, as well as the rules of your bug bounty program, is through the bounty brief. The brief is a web page that outlines what is in scope, what is out of scope, what areas you want to focus on, and more. It also communicates your reward range–discussed below–and disclosure rules.
When approaching your bounty brief, start by defining a clear scope. Keep in mind all the various factors involved such as gaps in your current testing, organizational goals, target complexity, and scope breadth.
Additional resources to get you started:
  • Scope
  • Exclusions
  • Business objectives 

2. Decide how you want to run your program

By tailoring your bounty brief to your needs, you can better control what is tested, what results come in, and thus, how much money you pay out. Now you have to decide how you want to engage with the crowd. In general, there are a few different ways to do this.
Private or public: By utilizing a private program, you can limit the volume of the testers involved in your program to exclusively invited researchers rather than the entire testing crowd. Although private programs don’t necessarily decrease the amount you will pay out, a smaller crowd frequently translates to fewer results. More and more organizations are starting out private and transitioning to a public program after anywhere from a couple of weeks to up to a year.
Ongoing or time-boxed: Not only can you decide who has access to testing your program, but you can also decide how long it will be tested. Bugcrowd solutions offer both continuous testing or time-boxed testing that operates as a crowdsourced penetration test. Much like a penetration test, you set a designated reward pool that the invited researchers compete for and you receive a report of valid findings once testing is complete. Many of our customers looking to ‘dip their toe in’ start with a time-boxed program to limit exposure and cap their costs.

3. Determine your incentive program.

That leads us to the next way to tweak your program–money. In addition to, or in lieu of, starting out private, some organizations start with Kudos or points-only programs, also known as vulnerability disclosure programs.
Additionally, reward ranges vary. Increasing rewards throughout the lifetime of your program is a good way to boost engagement and tap into the differing expertise and skill levels of security researchers and skill levels. We offer guidance as to how much you should pay based on your organizational security maturity. Learn more about our suggestions in our Vulnerability Rating Taxonomy.
As you can see, there are many ways to limit spending or better budget for your program, and it’s important to know that bug bounty programs must be thoughtful and planned in order to be truly successful. Stay tuned next week for our next myth-busting blog post and download the 7 Myths Guide to get a look at the most common bug bounty misconceptions.

[button link=”https://www.bugcrowd.com/resource/7-bug-bounty-myths-busted/?utm_source=website&utm_medium=blog&utm_content=report&utm_campaign=7_myth”]Download Now[/button]