Improve Security with a “Bug Bounty Program”

When managed well, a bug bounty program allows blue teams to more effectively implement defenses within a strategic threat model while lowering the budgetary needs of security teams. When designed right, bug bounties combine the best of in-house PenTesters and freelancers by quickly sweeping away low-hanging fruit and misconfigurations that otherwise left to fester could become the seeds of tomorrow's breach. Experienced security professionals often hunt bug bounties as a hobby, thus making bug bounties an excellent conduit for attracting talent to whom it otherwise may not have occurred to engage so deeply with your company's tech stack and products. 

However, setting up a bug bounty program for the first time is no small task, even for senior security staff; hence this guide to avoid decision paralysis and turn your threat model and budgetary constraints into a solid bug bounty program, attract penetration testers and bug bounty hunters in no time flat. 

First and Foremost, the proper concern of a bug bounty program is serving the needs of your organization's threat model. Everyone wants to prevent breaches, decrease costs, and facilitate compliance with standards like SOC2. So how do we design a bug bounty that respects and prioritizes that leads businesses to organize cybersecurity teams, to begin with? First, consider what products, domains, and services are most critical to your organization and include those in the program. Don't make the elementary mistake of prioritizing vulnerabilities by how dramatic the technical exploit is. For example, SQL injection needn't be elevated into a price category separate and above XSS because of its more impactful technical severity. Instead, bug bounty prices should be determined based on three factors: 

1. How critical is the affected service to your overall business? 

2. What damage could be done if the service were compromised? 

3. Do you want to attract top talent to your company or fix bugs? (note: there's no wrong answer to this question, but you have to be realistic given your company's size and budgetary restrictions. 

How starting a Bug Bounty Program saved a Company 

In 2012, the FlowCrypt encryption app received a report from a customer that users' private keys were visible via a simple, everyday activity within their browser extension. As a result, the company rewarded the customer with USD 1000 and immediately got to work designing a bug bounty problem so that simple bugs of this kind would never threaten their users' privacy ever again. And it worked. Not only were dozens of critical bugs disclosed and patched within weeks, but the additional attention also helped the small company win an exclusive deal with Google. Source: [Google Workspace encryption with FlowCrypt](https://flowcrypt.com/blog/article/2021-06-14-google-workspace-encryption/) 

Expanding your security team has diminishing returns because the effectiveness of a security team grows logarithmically. In other words, each new team member does add value, but the added value becomes smaller the more significant the team. So let's import this technique for powering up your security strategy into your company by answering the big questions: how much to pay, what to accept as a bug, and deciding how to publish your bug bounty program so bounty hunters will find it and choose to participate. 

How much to Pay?

Lucky for you, if you are starting a bug bounty program, you are late to the game! Why's that a good thing, you wonder? Because it means you have the privilege of making your payoffs competitive by evaluating bug bounty programs hosted by your competitors. Further, consider the bounty based on impact to the business rather than the complexity. If that sounds too subjective to convert into actionable tactics for devising your bug bounty, then take these two directly practical tips: 

1. Never commit to exact prices. Instead, always note in your bounty program that reward amounts listed are suggestions, that your security team and company withhold the right to revise, and that nothing is guaranteed. 

2. Reward small reports about security misconfigurations, not just epic exploits. This will save you money because small configurations like Content Security Policies often prevent big exploits. For example, would you rather pay 10 dollars for a report about a missing script-src directive in your CSP, or 1,000 dollars when an XSS is discovered, which that simple header could have prevented? By being generous about minor configurations and details, you save money by preventing exploits that depend on those vulnerabilities and adding more considerable exploits. By leaving yourself open to pay what you think is fair and reminding bug bounty hunters that payoff guidelines are just that, guidelines, you prevent yourself from getting caught up in technicalities. And by staying open-minded to more minor reports, you save money by avoiding big exploits later on. 

What should qualify for a reward?

As we've said before, misconfigurations that could feasibly be combined with other vulnerabilities to launch an attack that could threaten your company must qualify. And it should go without saying that blatant technical exploits, particularly ones that are dangerous according to your threat model. But what about the remaining bugs? Will you be flooded with a torrential outpour of bug reports that you are stuck with no idea how to categorize and reward? Not at all! Because you can run it through this simple filter. First, could the vulnerability feasibly be used to hurt your business, even when combined with another vulnerability to be exploitable? Second, does the bug bounty follow the confines of what should be allowed by external, third-party testers (i.e., not using phishing, physical entry, or denial of service)? And finally, is it realistic for your team to devise a patch to fix the vulnerability? After all, some issues are acceptable but unfortunate, and certain risks must be taken despite the possibility of negative consequences down the line. 

How to publish your bug bounty program?

There is one extensive choice to make: platform or not to platform. Often when launching a bug bounty program, companies feel obligated to manage it through a medium to save themselves headaches, but this is the opposite approach experienced managers tend to recommend if it's your first time. To begin with, start with a small in-house platform, and move to a forum when managing the program becomes too much work for one of your engineers to do on the side. One final tip: create a [security.txt file](https://securitytxt.org/). A bug bounty program can be leveraged by businesses to get more done towards compliance, security, and cost reduction with greater efficiency than traditional penetration tests. It does not undermine the value of PenTesting in any way. Still, it does illustrate that bug bounties, as an addition to a company's security strategy, can seriously amplify your security team's impact.