How to start an enterprise bug bounty program: A CISO's guide

Understanding bug bounty programs

Software users often stumble across programs that don't work the way they should, and ethical hackers, whether professional pen testers or hobbyists, often look at a vendor's software, either to conduct scans of products or to understand how the software works under the hood.

During the above cases, individuals inevitably discover flaws in software. In some cases, they will communicate these issues to the vendors, even without a bug bounty. Without an economic incentive, however, many of them could be slow to communicate an issue or ignore it altogether.

Organizations with bug bounty programs incentivize participants to document and report their findings. This means vulnerabilities can be found earlier in the software development lifecycle, which is generally cheaper than finding issues later in the SDLC or when the application is in production. It also gives organizations access to a global pool of bug hunters who have diverse skills and experiences. Some organizations might also find that a bug bounty program is more cost-effective than hiring full-time security teams or outsourcing regular security testing services. Unlike regularly scheduled vulnerability scans and pen tests, bug bounty programs also help ensure continuous testing.

It is important to note that bug bounty programs are not without their challenges. Beyond being difficult to manage, a program that is not well-defined faces possible legal and compliance issues. Malicious actors could also exploit the program, and data privacy is a major concern. Also, if there are many vulnerabilities, costs could get out of control.

Bug bounty programs can be public or private. A public bug bounty program is open to any bug hunter who wishes to participate. A private bug bounty program is invite-only and limited to a select group of hunters.

Vulnerability disclosure programs, like bug bounty programs, are for the secure, responsible disclosure of software vulnerabilities. However, vulnerability disclosure programs typically do not offer a monetary reward.

How to create a bug bounty program

CISOs considering adopting a bug bounty model should create a clear proposal for executives, the board and other stakeholders. Include how the bug bounty program fits within the organization's risk management strategy; a budget for establishing, running and managing the program; and the metrics they will use to measure program success.

Get input from legal, compliance, HR and other key teams. For example, to ensure the program complies with data protection laws and regulations, and to ensure sensitive data and intellectual property are handled properly.

In the proposal, include information about how the organization will manage the program. As soon as vulnerabilities are disclosed, the security team must know how to vet and validate the submissions, as well as accept and pay hunters. Teams must then fix any bugs. This process could be overwhelming for security teams, especially if large volumes of submissions occur.

When designing the program, CISOs must do the following:

• Define the scope. Clearly outline which applications, systems and data to target, as well as any exclusions or limitations. Bug hunters need to know exactly which types of security vulnerabilities the organization will pay for, such as sensitive data disclosure, cross-site scripting, broken access controls, remote code execution, injection flaws and privilege escalation. Also, specify any methods, such as phishing, social engineering or DDoS, that are out of scope.
• Specify terms and conditions. Set guidelines to protect the organization and its participants. This includes ethical and legal protections and code of conduct. Clearly display terms and conditions on the bug bounty website.
• Establish reporting protocols. Define how the bug hunter must report a vulnerability and the information required in the report -- including a description of the vulnerability, information on how to reproduce the issue and the potential risk of the bug. Ask for supporting evidence, such as screenshots, logs and proof-of-concept code. Include information on response timeframes and what bug hunters can expect after filing a report.
• Set the payment structure. Incentives could be monetary payouts, public recognition or company swag. Detail how rewards will be determined and distributed, and include information on reward amounts for various vulnerability severity levels.

Remember, communication is key. A successful bug bounty program requires active communication between the organization and the research community. There will always be questions and disputes from bug hunters who are unhappy with not being rewarded, for example, due to duplication, poor reporting or a false positive. How these are handled affects the reputation of the organization and, therefore, the number and quality of bug hunters who will participate in the program.

After designing the program, test it. Open the program to a small set of researchers before fully launching it. This first group will stress-test the program to be sure it is ready to be rolled out broadly.

After testing, launch and promote the program. This includes announcing the program, setting up reporting and communications channels, and marketing the program to attract participants.

Once the program has been established, CISOs and their teams must regularly assess and update the program. For example, periodically review the scope, adjust incentives and continuously market the program to remain relevant. Gathering feedback from trusted bug hunters can also help improve the program.

CISOs should report bug bounty program metrics to other executives and the board. For example, share the number of vulnerabilities discovered and remediated, average time to validate, average time to resolve, cost savings compared to other security processes, and other information about the program.

Self-managed vs. third-party platforms

CISOs must decide whether their organization should self-host the bug bounty program or use a third-party platform, such as HackerOne or Bugcrowd.

With a self-managed program, an organization has complete control over the program, including its scope, rules, communication and reward structure. Self-hosted programs also avoid the fees associated with popular third-party platforms.

An organization that runs its own can customize the program to meet the company's security policies and bug bounty goals. Self-hosting also enables an organization to ensure sensitive data and intellectual property remain within the confines of the company, reducing exposure to third parties. In addition, an organization will build a trusted pool of security researchers over time, enabling them to establish stronger relationships and build trust.

But a self-managed bug bounty program is not suitable for all organizations. Going it alone means an organization has to have the resources needed to establish and maintain the program; market the program and build credibility among the ethical hacker community; attract a large pool of ethical hackers; vet bug hunters; and take on others tasks third-party platforms typically deliver.

An organization with its own program must also have an internal team that receives inbound reports from bug hunters, communicates with bug hunters who reported the vulnerabilities, verify that the vulnerability is real and then pass that information to the relevant team for remediation. This can be time-consuming. The internal team will likely receive duplicate reports that require filtering, as well as low-quality reports that are difficult to verify. The team will also have to deal with bug hunters going outside the scope defined in the program and adversely affecting systems that were not intended to be part of the testing program.

Partnering with a third-party vendor might have more overhead costs, but it can simplify the process of running a bug bounty program. Such providers have established communities of ethical hackers, can streamline the bug hunting process from submission to validation, enable an organization to adopt a program more quickly, offer reporting and analytics tools, and often offer legal and compliance support. They also enable smaller and midsize organizations, as well as those with limited resources, to focus on their own security strategy rather than managing a bug bounty program.

Organizations that would benefit from creating their own bug bounty program are those that have mature cybersecurity capabilities and teams large enough to handle the additional workload. Such companies will have already found and fixed the obvious vulnerabilities and need the skill of a diverse group of bug hunters to find more niche and nuanced bugs.

Is your organization ready?

A bug bounty program can be an effective way to improve the security of an organization's attack surface. Recruiting the help of external bug hunters helps organizations find vulnerabilities before they can be exploited in the wild -- and at a potentially much higher cost than a bounty payout.

Note that a bug bounty program is not a replacement for existing security controls, such as vulnerability scanning or pen testing, but it can be an effective addition. Whether self-managed or through a third-party platform, a bug bounty program can help an organization proactively address threats and turn potential risk into opportunity for further growth.

Rob Shapland is an ethical hacker specializing in cloud security, social engineering and delivering cybersecurity training to companies worldwide.