Bug Bounty Programs Demystified

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.

What Is a Bug Bounty Program?

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? 

Common Objections to Bug Bounty Programs

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:

• Too expensive
• Takes several months before seeing results
• It’s hard to manage and is extremely time-consuming
• Researchers can be hostile
• Quality of findings can be inadequate

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. 

Financial Concerns

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 Timeline 

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.

Management and Scope

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.

Submissions Management

This is a more extensive topic that we will be covering in a future post, along with guidance on managing inadequate findings and researchers.

Suggestions To Get Started

Preparing the Test Environment

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.

Including Production Assets

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.

Final Recommendations

• Use an existing platform: Implementing a bug bounty program can be challenging and there are many recommended bug bounty platforms that can help your organization get started in no time, and they handle all the communications, accounts, payouts (especially international payments), etc. 
• Start with a private program: A private program will limit the amount of researchers and initial time invested.
• Implement guardrails: If there are some assets/domains/vulnerabilities that shouldn’t be included, these can be marked as out of scope.
• Define payouts: Bounties are a great way to motivate researchers to participate in a program. Consider increasing the bounties whenever possible — use other bug bounty participating companies in your space for guidance.
• Include all assets in scope: Production-like environments can be added instead of production if there are concerns.