In our recently released guide, 7 Bug Bounty Myths, Busted, we addressed some common misconceptions about the bug bounty model. We’re spending some time each week to take a deeper dive into those myths one by one. We started by addressing the misconception that bug bounty programs are all public and open to everyone and last week discussed the types of companies engaging with the bug bounty model. This week, we’re talking about risk…  

Myth #3: Running a bug bounty program is too risky.

Although the bug bounty model is gaining steady traction, many organizations are still concerned about ‘putting a target on their backs.’ Simply put, these perceived risks are tied to the unknowns and volume of external testers and the level of control that can be retained.

Our response to this myth is three-fold:

  1. The risk of being vulnerable greatly outweighs the risks associated with running a bug bounty program.
  2. The bug bounty model allows you to mitigate nearly all perceived risks with the ‘knobs and levers’ at hand (i.e. private or public, scoping, etc.)
  3. With a trusted partner and with the right processes in place, running a bug bounty program is no riskier than other traditional security assessment methods.

1. Lower the Risk of Being Vulnerable

You should know that your applications are vulnerable 24/7. Bug bounties close the gap left by traditional testing methods to get you as close to continuous testing– discovering more unknown vulnerabilities before the bad guys do–as possible.

Thus, granting permission for third-party security research is a great way to receive more vulnerability findings, giving your organization more knowledge and control, and ultimately reducing risk. 

2. Craft Your Program to Mitigate Risks

There are options available to optimize the success of your program and minimize unknown variables. Decide how you want to run your program–private or public–then articulate what you do and don’t want to be tested by defining a clear scope.

Budgeting, another perceived risk of running a bug bounty program can also be mitigated (and is addressed in our 7 Myths Guide). We often recommend that organizations start with a small–private, on-demand or Kudos-only program and throttle incentives throughout the lifetime of their program. Bug bounties don’t have to be “blank check” affairs–we can help you manage your budget from start to finish.

3. Work a Partner

Running a bug bounty program with a trusted partner lowers potential risk, as all community members follow a set of rules, outlining acceptable and unacceptable behavior. However, if the idea of opening up testing to the community at-large is too much for your organization right now, you can run a private program with a select group of vetted researchers.

Bonus! We get this question so often that we have to answer it…

What happens if a researcher goes rogue? In reality, incidents of public disclosure are extremely rare, and we actively work to prevent them. We closely monitor public researcher communications and activity, and researchers are penalized for not complying with Bugcrowd’s Standard Disclosure Terms which outlines acceptable and unacceptable behavior. In the event of a public disclosure incident–although rare and usually unintended–our team reaches out to the crowd member to ask them to remove the public information and notify them of the consequences of unauthorized disclosure. We reserve the right to issue a warning and/or removal of access to elements of the Bugcrowd platform on a temporary or permanent basis depending on the severity of the violation.

Still have questions? Learn more about how we address the liability concerns around running a bug bounty program, and read our FAQ’s about the risks and rewards of bug bounty programs.

Want to learn more about common misconceptions about bug bounty programs? Download our guide to get more in-depth commentary on the seven bug bounty myths in the coming weeks.

[button link=””]Download Now[/button]