How to start an enterprise bug bounty program and why
Incentivizing researchers for finding software vulnerabilities can be advantageous for vendors and participants. Here's what to know before starting a bug bounty program.
By now, most security pros are familiar with bug bounty programs. Software vendors offer these programs to provide a systematic and structured way to remunerate researchers for identifying and reporting vulnerabilities in the vendor's software.
Programs like this have been around for decades. Due to bug bounties' popularity, whole communities have developed around participating in bug bounty programs. These communities provide resources to researchers, enable a rapid on-ramp for a bug bounty program to companies and may act as a go-between for researchers and vendors. Researchers may do this work full time but, more commonly, do so to supplement their regular income.
For practical-minded organizations, though, the question is not about what bug bounty programs are, but whether they work. Organizations want to know if a bug bounty program will help achieve their goals and if the program is worth the money and investment in staff time and effort.
With these aspects in mind, explore the potential pros and cons of investing in a bug bounty program, and learn about the circumstances where bug bounty programs can be useful, as well as how to start a bug bounty program if it would be fruitful for your organization.
Advantages of bug bounty programs
There will always be ethical hackers looking at a given vendor's product, whether the vendor has implemented a bug bounty program or not. These may be software users that stumble across something that does not work the way it was intended, or they may be professional penetration testers conducting tests against a customer where the vendor's software happens to be running. Or they may be hobbyists who are merely interested in learning about how the vendor's software works under the hood.
In the course of, but not limited to, the above cases, individuals discover flaws in a vendor's software. Vendors should shrug off the stigma, however, because bugs happen. There will always be bugs. The question is what the vendor does with this information once it is reported.
Organizations may worry that people discovering bugs in their software are likely to attack or commit extortion. These cases do happen, but it is not the most common outcome. More often, most folks -- upon realizing security issues -- will communicate them to vendors even without a bug bounty. However, without an economic incentive, they may do it at their own pace and on their own schedule. Alternatively, they may ignore it altogether. A vulnerability disclosure involves testing and validating the conclusions, documenting how to reproduce the issue and even writing proof-of-concept code in some cases to demonstrate the security ramifications. Even if an individual documents a vulnerability perfectly, discloses it responsibly and communicates with the vendor politely, the vendor still may not be glad to hear from that individual.
A software vendor that launches a bug bounty program incentivizes participants to do what is in the organization's best interests -- meaning, researchers are rewarded for reporting their finding to avoid getting scooped by someone else, thereby losing the bounty. Bug bounty programs also encourage people to do the legwork of thorough vulnerability documentation. Additionally, it brings more eyes to the software of people who might not otherwise be looking at that product in the first place.
The time organizations gain from bug bounty programs is valuable because finding defects earlier in the development cycle is cheaper than finding them later. The closer a vendor is notified of an issue post-release, the more likely it is that development resources are still engaged for that release.
When and how to start a bug bounty program
In cases where an organization deems the value proposition is compelling, it must then decide whether a bug bounty program makes sense.
It is important to note that a bug bounty program works best when an internal security testing capability is already in place because, depending on how the bug bounty program is structured, it can get bogged down in lower-priority, easier-to-find issues that are more cost-effective to isolate and fix internally.
For example, bug bounty companies HackerOne and Bugcrowd have both found that cross-site scripting (XSS) is the most persistent vulnerability. Namely, Bugcrowd specified that reflected XSS is the most reported issue by volume. However, XSS flaws are pretty easy to test for; paying a bounty for such a predictable issue that should be caught quickly by an automated tool probably is not the best use of resources.
A bug bounty is all about economic incentives. This is true for the researcher, but it should also be true for the organization. Vendor leaders need to identify their expectations for launching a bug bounty program and know how and what to measure to ensure their expectations are met. Identifying goals can help with decision-making, such as in the case above about how much or whether to invest in internal capabilities. It will also help tune what dollar amounts the bug bounty program will offer for certain types of issues. Additionally, it can influence the decision to designate the bug bounty program as private -- by invite only -- or public.
One way to achieve this is to keep accurate records about the bugs that are found and not found through the program. The relative costs for finding a bug through the bounty program should be compared with the cost to build internal capabilities to help catch those issues to make sure a bug bounty program is worth the investment.
