GitHub Celebrates Four Years of Bug Bounties: Q&A with VP of Security, Shawn Davenport

GitHub celebrated the fourth anniversary of its Security Bug Bounty program and released a comprehensive recap of a record-breaking 2017 to mark the moment. To join the celebration and give you a chance to learn more about GitHub’s approach to bug bounties and security, we recently caught up with Shawn Davenport, VP of Security at GitHub. See the full Q&A below: 

Four years of bug bounty is impressive, what have the results been to date? Any notable milestones?

In 2015, after the first year of our bug bounty program, 33 unique researchers earned a cumulative $50,100 for the 57 medium to high risk vulnerabilities they reported. In year two, that dollar amount jumped to $95,300 for 102 valid vulnerabilities. In year three, GitHub expanded the program to include Enterprise bugs and prized a collective $81,700 to 73 medium to high risk vulnerabilities. Later that year, we doubled our payouts, bringing the minimum and maximum payouts to $555 and $20,000, respectively. Now, as we celebrate our fourth year, GitHub has handed out a record $166,495 to 121 valid vulnerabilities. 

How has GitHub’s program evolved over the past four years?

We've learned a lot over the past four years, which has allowed us to enhance the program as we combat issues and learn how to be most efficient.

From an internal perspective, we're continually improving the process of quickly triaging and responding to submissions, ensuring the smoothest possible workflow. Since we launched in 2015, we've moved away from email-based triage and now communicate through HackerOne's Slack integration - everything from receiving alerts to flagging those most critical. At the end of our triage workflow, we use ChatOps to issue rewards through HackerOne, so we can close the loop and pay researchers as quickly as possible.

We’ve also been able to increase our scope throughout the years. In March 2017 we launched GitHub for Business, bringing enterprise authentication to organizations on GitHub.com. This allowed for a unique opportunity for our veteran researchers: private bug bounty for unreleased features and research grants. This activity proved successful through leveraging external researchers who helped us to identify and remediate issues before general exposure.

Do you have a favorite hacker story or report that stands out since starting the program in 2014?

One of the most interesting vulnerabilities we received was a vulnerability in GitHub Enterprise that lead to remote code execution reported by Orange Tsai. Not only did the severity of the issue make it memorable, but to reach this final risk, a total of four different vulnerabilities were chained together. Orange Tsai provided us a clear and impressive report that allowed us to quickly validate the vulnerability. Our ChatOps allowed us to triage this within minutes of receiving the issue. Work was started immediately to fix the issue and a patch to fix GitHub Enterprise was released within days.

Were there any unexpected benefits? If so, what were they?

One of the benefits we’ve seen is through our own community’s action - blogging about their experiences and assessment processes. This typically drives engagement as more of the community likes to get involved. 

One example of this was a user in 2017 who wrote about their method to assess and investigate bugs in GitHub Enterprise. By the time this was officially added to scope, a number of researchers were already digging into the GitHub Enterprise code using the methods the user blogged about. As a result, we saw a big uptick in actionable vulnerabilities.

What’s the biggest lesson learned over the past four years?

It’s been interesting to see how the community is not necessarily incentivized by cash. Bumping to higher payout ranges does not always yield increased participation, as we saw in year three. A bounty program needs to find interesting ways to engage new and diverse researchers. Once they are engaged, the communication, triage and follow-up has to run fluently in order to keep those researchers coming back. 

What advice would you give others starting their programs now?

We’d encourage others to ensure their program runs as smoothly as possible and that to reach maximum engagement starts with a clear process and the right team. Creating a clear process is extremely important and includes: validating the submission and identifying the risk and priority; fixing the issue (or bringing it to the engineering team to address); and making a proper decision on payout.

Know that you will come across a lot of low hanging fruit, so make sure your bases are covered by either spending time identifying these internally, or use a third-party to assess externally. One benefit of this is that it will alleviate any pressure from external participants and you won’t have additional noise.

Lastly, properly scope the program: start small and expand as you see fit. You’ll learn many lessons along the way that can be used to iterate and fine tune the program as you go.

In July 2017, GitHub became a sponsor of the Internet Bug Bounty (IBB), making a $100,000 donation to be used to reward the hacker community. Why are projects like this important to GitHub?

Our own Bug Bounty program on GitHub is core to our efforts of making GitHub more secure by reporting vulnerabilities in our platform. We saw an opportunity to hedge our beliefs on a much larger scale with the help of Facebook and the Ford Foundation - all in the name of making the internet safer. The donation is just one way we’re able to support catching more vulnerabilities in internet infrastructure and open source software. 

When looking at the security industry as a whole, what do you think needs to change?

As a whole, especially in the sphere of OSS, more incentives and resources (financial and otherwise) need to be put into hardening and fixing vulnerabilities. It’s not simply about rewarding vulnerability discovery. Programs such as Google's Patch Rewards and Mozilla's Secure Open Source are good starts, and hopefully we can find ways to couple more programs like these with traditional security bug bounty programs and OSS development.

What’s next for GitHub’s Bug Bounty program?

In 2018, we're planning to expand the initiatives that proved so successful last year. We'll be launching more private bounties and research grants to gain focus on specific features both before and after they publicly launch. Later in the year, we'll also announce additional promotions to continue to keep researchers interested and excited to participate.

Given the program's success, we're also looking to see how we can expand its scope to help secure our production services and protect GitHub's ecosystem. We're excited for what's next and look forward to triaging and fixing your submissions!

_____________________________________

Check out their program and get hacking here: https://hackerone.com/github. 

ps - Inspired by Shawn and GitHub and want to launch your own bug bounty program? Start a conversation here.

HackerOne is the #1 hacker-powered security platform, helping organizations find and fix critical vulnerabilities before they can be criminally exploited. As the contemporary alternative to traditional penetration testing, our bug bounty program solutions encompass vulnerability assessment, crowdsourced testing and responsible disclosure management. Discover more about our security testing solutions or Contact Us today.