Bug bounty programs are sometimes viewed with a negative connotation for a variety of reasons. This post aims to overcome implementation obstacles by debunking those misconceptions, and providing recommendations for organizations as they embark on the bug bounty journey.
First a quick definition. A bug bounty program is a security scheme offered by many websites, organizations, and software developers where individuals are paid to find security vulnerabilities. These programs incentivize independent security researchers and ethical hackers to discover and report potential flaws, making the technology more secure and reducing breach risk. So why don’t more companies have them?
I’ve been involved in a few companies where bug bounty programs were generally perceived negatively. Colleagues gave a number of reasons for not implementing a bug bounty program. These included:
However, I’ve been fully managing a bug bounty program for more than two years now and I can attest that these concerns are essentially baseless.
The financial concern is misplaced since it’s significantly cheaper to find a critical vulnerability by doing a routine penetration test, or through a controlled bug bounty program, than if one of your customers discovers that vulnerability and demands a fix as soon as possible.
The consequences of customers and prospects finding security issues in an application can range from reduced confidence in your product, to actually losing an opportunity because the prospect considers the application insecure. This is far more expensive than the average bug bounty program. Not to mention the financial consequences of an actual security breach caused by a vulnerability.
Results can be obtained almost instantly. The researchers are usually highly motivated and working across multiple different time zones. Moreover, unlike penetration testing programs, which usually take place at specific points in time, bug bounty researchers test continuously. This allows you to constantly have an up-to-date understanding of your risk.
Bug bounty partner/platforms aid significantly when it comes to program management.
Organizations hesitant to implement a bug bounty program can start by setting a private program that provides access to only a limited number of researchers. This gives organizations more control over the program and limits the number of reports they receive. A private program helps address concerns both about an overwhelming influx of reports and the cost of bug bounty rewards.
Organizations can include production assets in the scope of their programs by disallowing certain types of testing. Common exclusions include denial of service attacks, social engineering, self-inflicting vulnerabilities, etc.
This is a more extensive topic that we will be covering in a future post, along with guidance on managing inadequate findings and researchers.
For smaller organizations, it is usually easier to run a bug bounty program when the company only has one main core product or a limited number of offers. For larger companies that have hundreds of applications and thousands of endpoints, providing full access for testers can become a challenge.
Ideally, a new test environment that researchers can freely use to run all the needed tests will be provided. If this is not possible, most companies already have a testing environment without any real data, which can be used for providing access to researchers.
It is recommended to include all production assets in scope for a bug bounty program, otherwise companies will likely miss vulnerabilities that are only applicable to production applications and configurations. This doesn’t necessarily mean encouraging load testing in production, rather, if somebody finds an issue in production, it must be rewarded.
For example, wouldn't you like to know if a person with limited resources and an open source web scanner were able to bring down an entire production environment? That’s certainly something I’d like to fix if it happened.
HYPR has made significant performance improvements by analyzing the scan patterns that researchers performed in production assets. Furthermore, even if these assets are not included under the scope, there’s usually nothing stopping actors on the internet from scanning assets that require authentication.