Misconception: Bug bounty hunters are not as skilled as penetration testers. Even if they were, how can I trust them and control them?

This is the number one concern and misconception around bug bounties as they relate to penetration testing and in general. Bug bounties are commonly perceived as purely free-for-all contests wherein tens of thousands of anonymous testers worldwide have at it. Today, however, there are nuances around bug bounties and bug hunters that we’ll address in this post.
Before we do, however, let’s define what it is we’re actually talking about. We’re talking about your standard web, mobile, even IoT, penetration test–not physical testing, social engineering and certainly not red teaming. To hear more about these foundational definitions, listen to our recent webinar on the subject.

Testing Talent

The first part of this misconception to address is testing talent. To be clear, we are not saying that penetration testers aren’t talented. In fact, we are saying quite the opposite. Much of the Bugcrowd community is made up of penetration testers, along with security engineers, software engineers, and other professionals. Bug bounties simply provide more exposure to these talented people–at scale.
Stat: 60% of the crowd are full-time professionals.
While anyone can sign up to be part of the Bugcrowd community, Bugcrowd also offers invitation-only programs that narrow the testing pool based on skill level, expertise or even geography. Only trusted and vetted researchers can participate in private programs. In addition, Bugcrowd can provide strictly I.D. verified or background checked researchers to meet organizational guidelines or restrictions.
When we look at bug bounties this way, they start to look a lot like penetration tests. So, what’s the difference? The value of crowdsourced security testing is in the diversity of testing talent, as well as the continuous, results-driven model. In the end, bug bounties are just as safe as penetration tests–when done correctly. Which leads us to the next topic of discussion…

Trust and Control

The second part of this misconception to address is trust and control. To address the preconceived notion that bug bounties are too risky, we’ll take a multi-pronged approach…

1. Set parameters. 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.

2. Utilize 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.

3. Historical data. In reality, incidents of public disclosure are exceedingly 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.

Stat: Incidents occur less than .0005% of the time. 

If that’s still not enough proof, Bugcrowd retains full liability in all private programs for any unintended violations or infractions and have a generous business insurance policy to cover any damages–the same as a standard penetration test firm does. Read more about bug bounty liability concerns here.
4. Weigh risk vs. reward Bug bounties get you as close to continuous testing as possible–discovering more unknown vulnerabilities than traditional testing methods. Granting permission for third-party security research is an excellent way to receive more vulnerability findings, giving your organization more knowledge and control, and ultimately reducing risk.
Bug bounties are still finding their place within application security testing space, but are quickly becoming great alternatives in many cases for security assessments. To learn more about the key differences between bug bounties and penetration testing, download our recent guide ‘Head to Head: Bug Bounties vs. Penetration Testing.’
We understand this discussion is both nuanced and can be controversial and welcome the community’s feedback. Over the next several weeks we’ll be addressing many of those nuances. Stay tuned and subscribe to our blog to get updates.