Join 5000+ subscribers and get tips for engineering leaders once a month

Back to all posts

Should you implement a bug bounty program?

Posted by Sierra Sterling on June 15, 2018

Amid growing privacy and security concerns, bug bounty programs are becoming increasingly prominent tools for companies to crowdsource vulnerability assessment. When most people think of bug bounty programs, they think of programs set up by a company or website that invite white hat hackers to submit reports of bugs they find, particularly those related to security and vulnerability. In exchange, these bounty hunters can receive compensation.

What we talk about when we talk about bug bounties

A hacker and a business may seem like an odd couple. In recent years, however, companies have set up bug bounty programs that allow them to work with hackers and those with skills in penetration testing/security vulnerabilities to discover security vulnerabilities before it leads to a breach that can put a company’s assets or its customers at risk. In other words, a company creates an incentive for hackers to use their powers for defense rather than exploitation.

In exchange for reporting a vulnerability, bounty hunters can receive monetary rewards, although it’s often not clear how big of a bounty a hunter can yield. For example, Facebook’s bug bounty program policy states, “We determine bounty amounts based on a variety of factors, including (but not limited to) impact, ease of exploitation, and quality of the report. If we pay a bounty, the minimum reward is $500. Note that extremely low-risk issues may not qualify for a bounty at all.” Facebook is not your average company in terms of size and security sensitivity, and smaller companies may offer smaller rewards but allow “lower-risk” issues to qualify.

Bug bounty programs, which by their very nature invite outsiders to discover vulnerabilities, are sure to spark a risk versus reward debate. One way to mitigate risk is to have a formal bug bounty program that spells out the expectations that the company has of white hat hackers and the expectations white hat’s can have of the company.

These expectations are key and it’s critical to make principled distinctions between security breaches and valid reports. You can’t just claim a security breach is part of your bug bounty program. For example, in 2016, a young hacker was able to gain access to 57 million customer names, email addresses, and phone numbers at Uber. The hacker demanded $100,000 to delete the data and Uber paid. There are a myriad of problems with how Uber handled this, including its delay in reporting the breach, but one of the most problematic aspects of it was that Uber made it look like the payment came from its bug bounty program, which is a gross misrepresentation of how bug bounty programs work.

So what’s in a name? Actually, a lot. Bug bounty programs seek to establish ground rules and parameters, and extortion payments undermine the entire purpose of bug bounty programs and leave companies vulnerable to being taken advantage of by hackers.

As Casey Ellis of Bugcrowd points out, “Uber’s payment was not a bug bounty payout, it was an extortion payment. Bug bounty programs establish clear parameters, validate vulnerability claims and pay a hacker based on an amount the company determines is fair. Paying a hacker who finds and exploits a vulnerability and then sells it back to an organization is extortion, not bug bounty.”

Situations like the Uber payout can be avoided by implementing and sticking to a bug bounty program.

When to implement a bug bounty program

man holding white balloon

So what’s the safest bet? According to Marten Mickos, CEO of HackerOne, “Every company with a digital asset should have a vulnerability intake program. You can do it yourself or have a vendor do it.” Having a process in place for receiving and responding to reported vulnerabilities will give you a clearer path to decision-making and allow you to take advantage of the skills of white hat hackers.

How to set up a bug bounty program

Once you’ve determined your company can benefit from a bug bounty program, you have to decide how you’re going to manage the program. This can be a large undertaking, especially for a small company with limited resources. For companies of any size, however, there are two main paths, discussed below.

Option 1: Work with a trusted partner

There are several companies who serve as trusted partners for companies both large and small. These third-party vendors have track records and have established trust in the tech community, and take much of the work out of your hands. In exchange, however, you must pay for their services.

Below are several bug bounty partners trusted by entities ranging from the U.S. government to Fortune 500 companies:

Often the hackers utilized by these partners are security professionals who are willing to dedicate free time to hunting for vulnerabilities. Partners like HackerOne offer different types of programs ranging from a full suite of services where they work with hackers to validate vulnerabilities and triage submissions to a solution that is more self-managed. Depending on your level of comfort with security vulnerabilities and your resources, either can be a great solution for your company.

Option 2: Set up your own bounty program

Another option is to set up your own bounty program. A common method for this is to set up an email account that hackers can submit vulnerabilities to like vulnerability@yourcompany.com. If you do decide to manage everything internally, there are a few key considerations to keep in mind to set up a program that will work for both you and white hat hackers. Since you are essentially creating an offer, you want to make the terms as clear as possible, and you should strongly consider integrating the following into your program and terms:

  • Ability to validate the identity of a hacker (and that they are a white hat hacker)
  • Clear guidelines for submitting vulnerabilities
  • Definitions of responsible behavior on the part of the hacker (e.g. giving you reasonable time to respond, not publicly disclosing vulnerabilities, rules governing downloading data, or accessing certain types of information)
  • Program in place to validate vulnerabilities
  • Clear compensation program
  • Clear policy on when/how a vulnerability will be publicly disclosed

Takeaway

The need for detecting vulnerabilities before data is compromised is a reality. Bug bounty programs are a great way to do that, provided that they are implemented thoughtfully and clearly.

Fortunately, for those who feel less comfortable implementing their own program, there are business partners out there ready to help you take advantage of a white-hat community that consistently outperforms technology when it comes to discovering vulnerabilities. Whether you use these third parties or set out on your own to create a bounty program, make sure you have clear policies in place to avoid conflicts with hackers and to give your business a clear process for dealing with vulnerability reports.

Enter your email below to be served up tasty tutorials, informative articles, and ButterCMS updates.

Get started now

Sign up with Google Sign up with Github
or