How Are Bug Bounty Programs and Vulnerability Disclosure Programs Different?
Let’s start with the similarities. Both bug bounties and VDPs aim to collect vulnerability reports from third parties. These third parties can be security researchers, ethical hackers, partners, customers, or concerned citizens. Both types of programs typically involve rules of engagement, a scope, a means of submitting vulnerabilities (often a web form), and a process for evaluating submissions and getting back to the submitters (also known as finders or hackers in the case of bug bounties). Ideally, there’s also an internal workflow to route the vulnerability report to the proper security or development team.
Without either type of program, organizations lack an official way of accepting submissions for known vulnerabilities. Finders are easily discouraged when they can’t make a report or are ignored when sent to a general “contact us” email. Both programs also allow organizations to acknowledge that they will not take legal action against finders (assuming the program’s guidelines are followed). Laws in many countries define illegal hacking broadly, which can put finders in jeopardy for simply disclosing an accidentally-found vulnerability.
The main difference between bug bounties and VDPs is the incentive model. As the name suggests, bug bounties pay out a monetary reward—a bounty—for valid submissions. Those who submit the vulnerability are incentivized. VDPs, on the other hand, typically offer thanks and recognition. The finders are recognized. It’s akin to a professional vs. volunteer effort. Some VDPs do offer swag, but we consider t-shirts and water bottles a way to thank finders and not an incentive.
How Do You Decide if You Should Run a Bug Bounty Program, a Vulnerability Disclosure Program, or Both?
Organizations may start with either a bug bounty or a VDP. Typically, organizations that begin with a VDP want to start small and are looking to provide a means to receive reports from third parties. In 2020, the U.S. Federal Government announced it would require federal agencies to “develop and publish a vulnerability disclosure policy” (a program is the initiation of such a policy). Other government recommendations will eventually require government suppliers to have a VDP. So, some organizations set up a VDP to comply with government regulations. The U.K. Code of Practice for Consumer Internet of Things (IoT) Security became a requirement in 2020. According to their policy, “All companies that provide internet-connected devices and services shall provide a public point of contact as part of a vulnerability disclosure policy so that security researchers and others can report issues. Disclosed vulnerabilities should be acted on in a timely manner.”
Organizations that start with a bug bounty are usually more mature. They want to incentivize hackers to actively look for flaws in their applications, e-commerce sites, or cloud infrastructure. These organizations define the scope of their bounty programs to focus on the applications and assets that they care most about and set up their bounty payments to—typically—pay more for more severe vulnerabilities.
Organizations with both a bug bounty program and a VDP will likely have different scopes for each. For example, all web domains may be in the scope of a VDP, where only certain applications will be part of the bug bounty. Said another way, VDPs provide wide coverage, and bug bounties encourage targeted testing.
What Are Public and Private Programs?
Organizations can decide who they want to invite to their programs. If anyone can submit reports, then the program is public. If they only invite select people, then the program is private. Public programs are typically listed in directories and directly on an organization’s website. Table 1 below compares public and private programs.
Why Make a Program Private? And What’s the Point of a Private VDP?
It’s common for organizations to start with a private program to ensure their internal resources can handle the submission volume. For organizations that have not worked with hackers or other third-party reporters, a private program protects them from revealing their vulnerabilities to an unknown and wide range of finders. Start with a limited number of trusted hackers to protect the confidentiality of reports and assets. Security teams can receive, triage, and remediate reports while looking for process improvements, scope changes, and potential confidentiality issues. Once an organization feels comfortable, opening a program to the public generally attracts more submissions for better coverage.
In other cases, private programs can be an appropriate long-term option. Asset scope is one major consideration. Sensitive assets requiring strict access controls and new assets requiring testing before a public release are more suitable for a private program. In addition, organizations may be looking for a specialized skill set and only want submissions from hackers with that expertise.
The primary goal of VDPs is to allow anyone to submit a vulnerability in any asset, so the use case for a public VDP is straightforward. But what about private VDPs? Does this go against their very purpose? Not for organizations that only want to hear about vulnerabilities from partners or customers. In this case, private programs make sense.
There is no right answer regarding your organization’s choice of a bug bounty, VDP, or both and whether to make their program(s) public or private. It depends on the organization’s goals, awareness of its attack surface, unprotected assets, and other risks that make up its attack resistance gap. As part of HackerOne’s Attack Resistance Management Platform, both HackerOne Bounty and HackerOne Response can help identify critical and unknown vulnerabilities and help close the gap. Contact us for more information on how HackerOne can help.