The Curious Case of Hacker Bug Bounties

The Curious Case of Hacker Bug Bounties

Matthew Honea

Blogpost Image

Bug bounty programs are growing at an incredible rate. According to the 2018 Hacker Power Security Report, almost every statistic about bug bounties has increased: from a 54% increase in new programs launched to a 49% increase in the number of reports submitted and vulnerabilities disclosed publicly. This is a positive sign for the future of the disclosure industry, in contrast to a troubled beginning when companies and governments pursued legal action against those who reported vulnerabilities (such actions, however, are still happening).

Now there are roughly thousands of bug bounty programs, both private and public. Companies that have implemented programs are seeing results, with 80% of reports deemed valid.

Despite all this growth, some programs have been frustrating to work with and not all programs are the same. While some published standards define receiving and disclosing information related to vulnerabilities, and additional standards define the process from intake to remediation, there are no defined ways to adopt a program, rules, or rewards—making every program different. Even on hosted platforms such as Hackerone or Bugcrowd, the severe lack of standardization is limiting these programs’ effectiveness for everyone.

I support the growth of these programs, but I want to explain in detail why there’s still a long way to go.

Making Programs That Work

What’s the point of a bounty program? For most companies, it’s to receive continuous testing of exposed systems from many angles at once, while providing a reasonable channel to reward people for their efforts. Notice that I mention two important arguments here. The first is that systems are tested from many angles using the techniques that nefarious attackers also use; the second is that the reward is balanced with efforts. These two views need to be kept in mind throughout the process.

Each company has its own set of IT standards, practices, and implementations, but as the market matures and bug bounty programs are more widely adopted, technology companies will inevitably shift to a more commonly defined approach. The insurance industry has always been the go-to place for risk transfer, and the market naturally developed new coverages as the need arose.

Consider, for example, the standards that were developed in the 1800s by HSB during the industrial revolution to create an insurance market for steam boiler malfunctioning and transform industry thinking to put safety first. Similarly, cyber-catalysts like the Equifax breach will drive industry change today. As these incidents happen—and happen more often—the market will naturally respond.

Some key organizations are helping to chart a path forward. Companies such as Intel and Google are leaders in the space, setting standards and payouts well beyond most other businesses. We decided to do some analysis of these types of programs and compare them to our risk data. The results supported our hypothesis that companies that implement either vulnerability disclosure or bug bounty programs tend to have lower types of risk when compared to their peers that do not.

The Prisoner’s Dilemma

Two of the most critical elements of a bounty program are quick communication and triage. If reports are not properly acknowledged and verified, the program can’t get off the ground. This gap in reporting has led third parties, such as OpenBugBounty, to create bounty programs for other companies. OpenBugBounty is a platform with no monetary incentive. It’s simply a place for researchers to responsibly disclose vulnerabilities with the goal of getting a response from affected companies.

I’ll hypothesize a scenario where a grey hat hacker finds a vulnerability with access to personal customer data. Here are some possible outcomes:

  • Remain silent about the vulnerability/data and do nothing.

  • Sell the vulnerability/data to someone else.

  • Give the vulnerability/data to someone else.

  • Report the vulnerability/data through a bounty program.

  • Publicly disclose the data.

In this case, the grey hat hacker has a choice of one or multiple options. For a company, however, the only desired option is for the hacker to report the vulnerability through a bounty program. Here’s the dilemma. To illustrate my point, let’s compare three companies with public bug bounty programs.







Start Date

November 29, 2016

May 31, 2017

March 22, 2016

Market Cap

US$78 billion

US$27 billion

~US$50 billion

Reports Resolved




Average bounty




Total bounties paid



~US$1.5 million

Comparison of public bug bounty programs hosted on the Hackerone platform, September 2018

There are two main angles at play here in this game of bug billiards. One angle is understanding whether these programs accept the vulnerability as part of their bug program (also known as the “scope”). The second is the payout amount and understanding whether the amount of effort spent is worth the hacker’s time in reporting it.

The scope for a bounty program should be well thought out and justified with minimal exclusions. Exclusions are basically a way for websites to say they will not recognize a disclosure (even if you can change the website’s confidentiality, integrity, or availability). Every program likely has some exclusions, but these companies blur the line between exclusions and excuses. They’re not alone in the space. Payouts are generally proportional to the damage and reputation of a company, walking the fine line between what’s reasonable and what’s extortion.

These programs are working and have come a long way since they were first implemented. Spotify released its managed bug bounty program last year, and it’s resolved 247 reports so far (with a breach in 2014). Uber is arguably the most developed of the three. Its program catalyst was a breach that happened back in 2016, which led to payment of a US$100,000 bounty without disclosure. Starbucks is one of the few major food industry chains with a bug bounty program, which also developed only after an app fiasco.

Regardless of the program details, every program pays significantly less in bounty payments than what a data breach actually costs to remediate. The average bounty payout for a critical vulnerability is US$2,041. The average data breach cost, according to Ponemon Institute, is US$3.62 million.

Incentivizing Programs to Maximize Effectiveness

We need to accept the fact that a tarnished corporate reputation costs more than any bounty program. Starbucks, Spotify, and Uber are clearly major global brands with both a digital and physical presence. They all have substantial assets and income that depend on a functioning service.

Let’s try to rethink how bounties are paid out. What happens if we allow the price to flow with market expectations in the context of the “prisoner’s dilemma” that I discussed earlier? As with insurance, the idea of many companies paying into a pool to share risk is a way to offer more to those willing to spend time and resources to secure a company. Having fixed costs is also a much smarter way to budget for programs where there is a high degree of uncertainty.