The premise of crowdsourcing the task of uncovering new bugs and vulnerabilities in an organization’s web applications or consumer products sounds compelling to many. What’s not to like with the prospect of “many eyes” poking and prodding away at a corporate system for a minimal reward—and preemptively uncovering flaws that could have been exploited by hackers with nefarious intent?

Despite existing for over two decades prior to the more recent launch of commercial bug bounty platforms and services, not a lot has changed in the mechanics and benefits of crowdsourcing bug hunting. The question that many struggle to answer though, is “Are bug bounties an effective security strategy?”

Netscape was likely the first entity to publicly broadcast their bug bounty program back in October 1995—calling for beta testers to refine Netscape Navigator 2.0—and offering a mix of cash prizes and swag. Today’s bug bounty programs offer the same rewards; while new commercial bounty platforms offer bug hunters the additional prospect of scoreboards and cross-promotion aggregation of payments or prizes.

With the rise of new commercial bug bounty platform providers (e.g. HackerOne, Bugcrowd, BugBountyHQ, Synack, Cobalt Labs, etc.) and the growth of high profile online service providers offering bug bounties (e.g. Google, Facebook, Pinterest, Yahoo, Mozilla, Wordpress, Microsoft, etc.), there is added pressure on CISO’s of organizations with sizable online service or product portfolios to launch their own bug bounty programs.

For many new to the topic of bug bounties, new questions are being raised… Are bug bounties a “flash in the pan”? Should an organization launch a bug bounty? Are the newly emerged and VC-funded bug bounty platforms providing value? What will the bug bounty landscape look like in a few years?

Pre-requisites to Investing in a Bug Bounty Program

Before considering launching or offering up a bug bounty program for any organization, I strongly recommend that they master the following security prerequisites first:

• Is it clear to customers and security researchers how they should submit bugs and vulnerabilities to your organization? Every Website or online service should clearly illustrate the mechanism for submitting bugs and vulnerabilities. This may range from pointing to an email address (e.g. [email protected]) with accompanying public encryption keys, through to detailed online submission pages. It is important that this information is easy to locate.
• Have you published or follow any public vulnerability disclosure guidelines, and do you understand your “SLA” obligations? Vulnerability disclosure guidelines explain to bug hunters how you respond to the security issues they entrust you with fixing; setting expectations on communication levels and timeliness, and helping guide the relationship through the remediation process. Once a bug has been submitted, it is critical that responses be managed in a timely fashion—and that the company has the technical depth to rapidly evaluate and confirm or reject the submission, and provide a timeline for remediation.
• Do you already have your Internet-facing web services and applications assessed daily by a managed vulnerability scanning provider? It is difficult to beat the value of a third-party managed vulnerability scanning service that probes all the content and services of your Internet accessible business on a daily basis. As new vendor patches become available, or new vulnerabilities and attack techniques get publicly disclosed, a good managed vulnerability scanning platform will identify all common security flaws and rapidly alert the organization to its exposure—far quicker than any bug bounty program.
• Do you already have a managed penetration testing program that regularly assesses your Internet facing web services and applications? Regular penetration testing and security code reviews are core to securing the web services and applications that an organization makes Internet accessible. A managed program of (at least) annual security assessment and penetration testing will help identify most “big ticket” and fundamental security flaws—and can be targeted at high value or high risk assets.
• Are your engineering and QA teams trained and managed against a SDL? A well implemented and adhered to Security Development Lifecycle (SDL) program is critical to any successful Agile managed release process. Engineering teams and QA functions must already be capable of automated quality and security checking. Bug bounty programs will add new stresses to the review and triaging of security bugs—and development teams must have a well-established framework for processing and releasing fixes.

Failure to have mastered these prerequisites will likely:

• Result in newly uncovered bugs being passed on to third-parties rather than your own program,
• Cost you money for bugs you don’t needn’t pay for,
• Cause you to expend wasted cycles in triage and bug hunter responses,
• Incur delays in response and frustrate bug hunters,
• Undermine any community goodwill and PR benefits from the bug bounty program.

In Part 2 of this article, we’ll discuss why an organization should invest in a bug bounty program and understand the limits of any value an organization could expect to extract from running such a program.

In Part 3 we’ll look at the crystal ball. Managed vulnerability scanning and regular penetration testing form the basis of vulnerability management and certification today. Can bug bounty programs and platform providers close the gap on vulnerability management and usurp the commercial penetration testing market, or is this all just a flash in the pan?