Bug Bounty Programs: Significant Benefits, Challenges

Reading time: 6 min
Share this Share on email Share on twitter Share on linkedin Share on facebook

There are many reasons why an enterprise may want to implement a bug bounty program. Most notably is that no matter how good an organization’s software testing is, how proficiently developers code security, or how thorough an organization’s software security assessments– there will always be flaws. These flaws make it possible for attackers to exploit security vulnerabilities and bypass security defenses.

These flaws make it possible for attackers to exploit security vulnerabilities and bypass security defenses.

This is where so-called Bug Bounty programs come in. A bug bounty program is when an organization will pay a ransom to third-party security researchers when they find software security flaws that meet certain conditions in the software or on their sites, apps, or services.

There are many purported benefits to these programs, such as the identification and fix of more vulnerabilities, and a more secure infrastructure fixed. But there are also many challenges and drawbacks that must be taken into consideration.

Large companies—such as Facebook, Google, Samsung Smart TV Security Bounty Program, and Mozilla—that offer bug bounties and others have tremendous technical and financial resources necessary to run their own programs. With their complex web or development environments, these large companies’ bug bounty programs provide an additional way to find software and configuration errors that slip past developers, testers, and security teams. And organizations of this size often have the ability to manage the big bounty program, from setting the fees, to analysis of the bugs uncovered, to communications with security researchers.

For midsized and smaller organizations, however, it makes sense to turn to a bug bounty service providers. The bug bounty vendor can run the recruiting, vetting, and managing of security researchers for smaller enterprises, as well as the analysis of bug findings and payment management. For smaller firms who don’t have the expertise and full staff on hand required to run their own bug bounty programs, it’s a potentially affordable and more manageable way to find bugs that could slip past their automated scans.

Some companies like to run continuous bug bounty programs so that whenever a researcher finds a bug they will be paid if it is a flaw that merits payment. Other programs run for defined periods of time and within these deadline researchers are given a scope in which to explore for flaws.

While more secure software is certainly a benefit, there are potential challenges with bug bounty programs. I have noticed a number of recurring flaws in the interviews I’ve conducted with those who run bug bounty programs.

 Few researchers will understand your business.

What looks like a significant software flaw to a researcher may not appear significant to you for any number of reasons. It could be that the flaw increases the real risk of access to sensitive or related data or it might not make access to such data any easier. Perhaps there are other controls in place that mitigate the bug that the researcher hasn’t considered. In any event, you must be prepared to resolve such situations.

Bug bounty is incremental

The bug bounty program won’t eliminate the need for secure software development, secure software testing, pen tests, or ongoing web application and system scans. This bug bounty work is incremental to those efforts and is designed to find flaws that slip through these checks. Thus, while bug bounty programs can help eliminate flaws that could have otherwise gone unnoticed by everyone except an attacker, it’s hard to make a direct bug bounty return-on-investment argument.

Expect your logs to light up.

Your security teams must be ready to deal with an increase in security event noise. Researchers will be hitting the systems in ways that monitoring systems have probably not previously witnessed. This will create additional effort and tuning of the SIEM so that teams can be sure that they are not chasing legitimate security researchers and ignoring potentially real attackers in all of the new data that will be generated.

You’ll need to be prepared to fix the holes uncovered.

This may seem obvious but more than one of the CISOs I spoke with said their organizations didn’t have in place the ability to swiftly remedy flaws that were found. While many flaws can be easily fixed, some take considerable effort and the ability to close a high risk, costly flaw to remediate. This will take advanced planning and agreement with security teams, developers, operations, and application owners to ensure the procedures are in place to tackle such incidents when they arise.