5 questions to answer before jumping on the bug bounty bandwagon

The bug bounty program landscape has undergone significant evolution in the last few years. Organizations of varying sizes and across industries commonly invest in some form of bug bounty model as the available options become more diverse, customizable, and affordable.

With humble origins dating back to the mid-90s, bug bounty programs are agreements typically offered by businesses in which publicly or privately invited ethical hackers may receive recognition and compensation for finding and reporting security vulnerabilities. The chief goal of a bug bounty program is to discover and fix these vulnerabilities before they become common knowledge or are maliciously exploited by cybercriminals.

By investing in a bug bounty program, organizations can significantly expand their security workforces, explains Sean Poris, Verizon Media’s director of product security. “This naturally builds a large worldwide network of researchers working together on your program and establishes a sense of community amongst the researchers and your employees. The talent level and techniques of some hackers are incredible and can yield some creative, impressive findings to allow your organization to increase its security posture.”

However, due to proliferation and maturity within the bug bounty market, embarking on and maintaining a successful bug bounty program is becoming a more complex, nuanced exercise for organizations. As a result, businesses need to answer these five key questions to ensure investment in a bug bounty program is realistic and beneficial.

1. Will you manage it internally or outsource some or all of the process?

First and foremost, organizations need to understand the bug bounty options they have at their disposal. Essentially, these fall into two camps: in-house and outsourced, though there ia some overlap between the two. An in-house bug bounty program, often the choice of large multinational enterprises, typically includes a documented public-facing submission and internally managed bounty process.

Outsourced bug bounty programs are as-a-service models whereby organizations invest in specialized third parties that handle various aspects of the bug bounty process on the company’s behalf. Both have merits and drawbacks to consider depending on various factors including budget, resources, and capabilities.

For example, by running a bug bounty program in-house, an enterprise can establish its own structures, rules, and boundaries for the process, as well as have direct management of things such as alert triaging, program finetuning, and best practice. However, an internal bug bounty program requires significant time, resources, and budget to run—hence why in-house bug bounty programs are more realistic for big companies than for smaller ones.

Outsourced platforms, on the other hand, are a far more attainable option for organizations that lack the resources and expertise required to run a bug program internally. A dedicated third party can offer anything from simple listings and introductions between hunters and organizations to fully managed services that perform varying amounts of the heavy lifting on the organization’s behalf. This can include triaging of disclosed vulnerabilities, liaising with potentially hundreds of thousands of registered ethical hackers, and providing vulnerability retesting services.

2. Is your vulnerability management up to scratch?

Regardless of whether you’re considering an in-house or outsourced approach, you’ll to gauge your readiness for a bug bounty program, with particular focus on your vulnerability management capabilities. “Security leaders can have a sense that it may be time to dip their toe into a bug bounty scheme when they’re sure there’s an internal commitment to run vulnerability discovery all the way to remediation,” explains Tim Wade, technical director, CTO Team at threat detection and response platform provider Vectra. “However, if there are known vulnerabilities in software or systems which continually fail to get patched, that’s a clue that there’s internal alignment that still needs to occur around the realities of modern software risk.”

Alice Collins, communications manager at bug bounty platform provider HackerOne, agrees about the importance of robust internal vulnerability management processes before inviting hackers to submit vulnerabilities. “Without clear and workable processes to deal with the vulnerabilities when they’re found, security and development teams will be overwhelmed, and hackers will be frustrated,” she adds.

“If your internal vulnerability management processes aren’t honed or if you don’t have a clear asset inventory that maps to the scope you are opening up to bug bounty, you simply are not ready yet and need to focus your efforts on these foundational security program elements first,” explains Verizon’s Poris.

A potential gauging exercise that organizations can carry out is to conduct a small-scale internal bug bounty trial program with existing employees/staff and invited persons, says Tom Brennan, CIO at Mandelbaum Barrett P.C. and US chairman of CREST. “Having a thought-out, small-scale project with a start and end date will provide a measurement of actions.”

3. Have you defined bug bounty objectives and scope?

Organizations must establish both the objectives and scope of their program early on, including statements on why their policy is being created and what is expected to be accomplished. “Understanding and articulating your objectives will give you a clear focus for your program, whether it’s being used for basic vulnerability disclosure, demonstrating ‘pen testing’ to external assessors or acting as a strategic element of your overall security program,” Poris says.

In terms of scope, it’s important to identify what is considered to be fair game within the bug bounty process and where attention from hackers is requested or not allowed, adds Collins. For example, she suggests clarifying the following:

• How hackers should submit reports and the information the organization would like to see. A secure web form is preferred over emailed reports, which can lead to incomplete and unstructured information.
• The types of vulnerabilities that should be reported and those that should be excluded.
• Any limitations to protect data or intellectual property, or on products or versions.

An as-a-service model can help an organization with these issues, but ultimately parameters will need to be set by the organization based on their requirements.

Organizations should also demonstrate a good faith commitment to customers and other stakeholders that are potentially impacted by security vulnerabilities, Collins says. “Essentially, the commitment will pledge that the organization will not take legal action when a vulnerability is disclosed. Using clear, inviting language in the commitment will give needed reassurance to hackers working on the program.”

4. Can you clearly articulate what hackers can expect from the program?

Clear and thorough communication of the finer elements of a bug bounty program are key to its ongoing success, Collins says. This includes:

• How quickly a hacker can expect to hear from you after submitting a bug
• Confirmation of vulnerability
• Expectation of recognition
• Follow-on communications
• If and when ethical hackers have permission to publicly disclose their findings.

“Setting expectations with hackers and educating them about internal processes and how that affects the bug bounty program will reduce the risk of hacker frustration and keep them coming back,” says Collins.

Taking such a transparent, communicative approach can also help to gauge whether what your program can offer matches with what ethical hackers expect, adds Poris. “Researchers want interesting scope, a challenging program, a responsive team, and good compensation.”

5. Do you understand the risk associated with bug bounty programs?

Lastly, organizations must recognize the risks that come with bug bounty programs, and these are not limited to an inability to meet bug fixing requirements when vulnerabilities are reported, as previously mentioned. “Companies may not be fully aware of their internet-facing infrastructure and product footprint,” warns Poris. “What is the business impact of a bug if you don’t know the risk level of the asset it affects? Further, not all researchers will be cooperative. You must have a strategy in place to anticipate researchers who make mistakes or act in bad faith.”

Collins advises that a clear policy definition will makes enforcement of your bug bounty policy rules easier and even expected when researchers violate them. “Through consistency, researchers will come to recognize your program as organized and well-managed, which will help reduce program risk.”

What’s more, bug bounty programs, like any other security approach, must be flexible, because what is adequate today, may be deficient tomorrow. “As an organization’s security requirements change and adapt due to digital transformation or the introduction of new products, the bug bounty program will need to change and adapt, too,” Collins says. Failure to do so can open organizations up to new threats as business priorities change, she adds. Bug bounty programs must therefore fit ever-changing and highly specific business needs.