5 reasons why a bug bounty program is not enough

So you’ve made the decision to start a bug bounty program at your company. Congratulations – definitely a smart move. But can you rely on bounty hunters as a guarantee of web application security? Can they help you maintain a good security posture even without internal vulnerability scanning and penetration testing?

More and more companies are setting up formal bug bounty programs, and that is great news for everyone. Not so great is that some expect the bounty program to be their primary web application security solution – which it simply cannot be.

Having a bug bounty program but no other web application security activities is a bit like having a locked vault in your bank but no cameras, sensors, or security officers. And then you put up a poster on the door saying, “$1000 if you can show us how to break into our vault.” For a bank, that would be a recipe for disaster – and it won’t work in web security, either.

Let’s have a look at five reasons why you should not rely on a bounty program as your primary guarantee of web application security.

Reason #1. Not everyone knows about your program

Staying with the bank vault example, a poster on your door is pretty unlikely to be seen by security professionals with the skills and motivation to actually test your vault. The same goes for a bug bounty program: if you don’t promote it, nobody will know about it.

It’s not easy to promote a bounty program on your own. Unless you represent a high-profile brand, it’s likely you will need to invest in specialist advertising targeted at the hacking community. Signing up for a crowdsourced security program or ethical hacker platform is a good idea to increase your visibility and ease communications – but it may not be enough. If you wanted to make your bug bounty program effective as a primary means of securing your web applications, you would have to invest quite a hefty sum in advertising and payouts. It would be one of the least economically sound approaches to web security.

Reason #2. Not everyone cares about your bounties

Even if white-hat hackers know about your program because you’re very effective at advertising it, there is no guarantee they will decide to work on one of your web applications. Hackers have limited time and resources, so they’re likely to focus on work that pays off best.

The attractiveness of your bounty program to the hacking community depends on three main factors:

• Money: If a hacker can expect $1,000 from your bounty program versus $10,000 from another company, they will likely go after the bigger prize first. So if you want to have your security thoroughly tested, you may end up in fierce competition for attention and payouts.
• Difficulty: Obviously, hackers will go for easy jobs and easy money first. If your web application is full of minor vulnerabilities, your first wave of bounty payouts will be for those issues rather than more dangerous ones. This could leave you spending money on issues that don’t pose a major threat while far more dangerous vulnerabilities that are harder to find still linger.
• Prestige: If you represent a well-known brand, hackers are more likely to choose your program purely for bragging rights if they find a high-profile issue. If you’re not Google, Facebook, or another global giant, you’ll be much further down the list of prestigious clients.

Reason #3. Bounty hunters focus on specific vulnerability classes

Hackers are only human. Finding vulnerabilities can take a lot of time, especially for more advanced (and dangerous) weaknesses, so you can’t expect bounty hunters to go through a hundred issues a day. In fact, they will often spend many days digging deep into just one potential vulnerability. This is why bounty hunters often focus on specific types of vulnerabilities, depending on their area of expertise and personal preferences.

A bug bounty program is not designed to guarantee comprehensive coverage for all types of vulnerabilities. Even if a skilled ethical hacker becomes interested in your program, they will most likely focus their testing on a small subset of all possible vulnerabilities and ignore everything else. The chances that you will ever get enough people working on enough vulnerability types to provide decent coverage without exhausting your bounty budget are close to zero.

Reason #4. Bug bounty programs work slowly

Even assuming you have a high-budget bug bounty program, going from initial engagement to security improvements will take a lot of time. Bounty hunters need to learn about your program and become interested in it. You will also need to have enough specialists to cover many different types of vulnerabilities – but even then, it will take them a long time to perform manual security tests across all the sites and applications you want tested. And remember, you will need to verify every bug report and send valid issues to your developers to fix, which takes even more time. 

In practice, it may take several months or more to see any clear security improvements from your bug bounty program. If you’re not doing anything else in terms of web security, then until the first results start trickling in, your websites and applications will remain just as vulnerable as before. And during that time, malicious hackers can stumble upon your bugs as easily as the bounty hunters – except they won’t politely report them.

Reason #5. Bounty hunters also use tools you could run yourself

Last but not least, bounty hunters are smart and know how to work more efficiently. If your bug bounty program permits it, they are likely to start work by running an automated scanner to map out your site and find any low-hanging fruit. Especially if you don’t use a vulnerability scanner yourself, a bounty hunter may simply scan your website using a commercial scanner such as Invicti Standard or Acunetix Premium, find several exploitable vulnerabilities, report the bugs, and cover the cost of their license from your payouts.

In the short term, it might seem more affordable to let bounty hunters pay for software that you should be using yourself, but you are only paying for one scan at a specific point in time. Even if you fix the reported issues, you will have to wait for another report to find any new ones. Ineffective fixes may mean that the same vulnerabilities will resurface in the future and you will be paying for them over and over again. Not to mention that you’d be missing out on the other advantages of integrating a web security testing solution into your routine security and development processes.

Bug bounties are one part of a bigger picture

Does all this mean that your bug bounty program is useless and investing in it was a mistake? Absolutely not! It does mean, however, that your program can only be effective as part of a bigger solution.

Remember that bank vault example? No single protective measure will keep your stash of gold safe. A well-protected bank vault needs cameras everywhere, pressure and movement sensors, security guards on 24-hour duty, doors and windows under alarm, redundant phone and power lines, alarm buttons for your cashiers… You need all these and more, working together.

It’s exactly the same with web application security. You need multiple elements to make your security program successful and comprehensive:

1. At the core of your web application security program, you should have a web application vulnerability scanner (a DAST tool) such as Invicti. This will help you find and address the most important issues quickly, effectively, and systematically, especially when integrated with your development process.
2. Additionally, you need to perform periodic manual penetration testing to find issues that no automatic scanner can detect. Even if you have an internal security team doing this, they may be biased or simply overworked, so you should also have external penetration testing every few months. If you have the resources, occasional red teaming exercises can be extremely helpful.
3. Once you have both of these in place, a bug bounty program makes a perfect addition. Its primary purpose is to find vulnerabilities missed in previous testing steps and to enable responsible disclosure. It should never be treated as a replacement for vulnerability scanning and penetration testing.
4. To provide some measure of protection, you should also consider using a web application firewall (WAF) integrated with your vulnerability scanner. While web application firewalls will stop some basic attacks on their own, they work best when integrated with a scanner. That way, you can set up your firewall to temporarily protect you from vulnerabilities that have been found but not yet fixed.
5. If you develop your own applications, consider shifting left and introducing DevSecOps practices. This will let you perform security testing as early as possible using not only DAST but also SAST and/or IAST tools, thus finding even more potential issues before they can become a problem in production.

So if anyone tells you that a bug bounty program can be all you need to secure your web applications, think of that bank vault. Would you leave it unprotected and hope for the best? Didn’t think so. And your business applications can be far more valuable.