Not every bug bounty program is built the same. Today, GitLab announced that they have surpassed the milestone of awarding out $1 million in bug bounties to hackers on HackerOne for discovering and disclosing valid bug bounty reports! What’s more? This milestone comes on the heels of the GitLab security team completing one year of its public bug bounty program in December 2019. Since launching its vulnerability disclosure program (VDP) in 2014, GitLab has worked with 750 hackers and resolved more than 475 valid reports. Now those are the results we love to see.
To celebrate this momentous achievement we asked GitLab application security managers James Ritchey and Ethan Strike to share what this milestone means to their team, why GitLab prioritizes transparency, and what they’d like to see more of in 2020.
Q: How has GitLab’s work with the hacker community evolved since launching your VDP in 2014?
James Ritchey: We started off with a small, public vulnerability disclosure program in 2014 where we awarded swag on qualified reports. Eventually in December 2017, we were ready for a private program open to a small pool of researchers, where we were able to get our feet wet, build out our appsec team and develop and establish our bug bounty triage, response, and disclosure processes. Once we’d felt our program had matured enough to support a public program, we opened it up. We’re excited to have just celebrated our one year anniversary as a public program in December 2019!
Q: GitLab has officially paid out more than $1,000,000 dollars in bounties! Aside from budget and hacker rewards, what does that figure really mean? What makes this milestone meaningful to your team?
Ethan Strike: There’s no denying that a million dollars in bounties paid is a big milestone for our program, but what makes this especially meaningful to us is that it clearly demonstrates GitLab’s commitment to building a strong and secure product. It’s also worth noting that over half of this total was awarded in our public bug bounty program (over $593K) which means, the entire community of security researchers were able to contribute and reap the rewards. We’re proud that our journey to a million in paid bounties includes contributions from 768 reporters (since Jan 2014) including several of HackerOne’s all time leading reporters. We also have 227 repeat reporters, meaning that we’re finding ways to engage and incentivize reporters to continue to contribute to our program. Not to be missed, 541 new-to-our-program reporters have submitted reports just since our program went public in December 2018, meaning we’re growing and our program is one that exemplifies GitLab’s mission of “Everyone can contribute”.
Q: What moments, metrics or bounties are you most proud of to-date?
Ethan Strike: Besides celebrating our one year anniversary as a public bug bounty program in December 2019, it was a highlight to meet some of our program’s top contributors in person at DefCon 2019.
We’ve been consistently iterating to improve processes within our program like, shortening the time to bounty payout, increasing bounties for critical and high severity reports and working to improve communications with our reporters, so it feels great to be able to strengthen our program in these ways.
We’re also quite proud that our mean time to remediation (MTTR) for high and critical severity vulnerabilities is below industry standards. A model example of our triage and response would be this exfiltrate and mutate repository and project data through injected templated service report which was submitted by Jobert on a Sunday and triaged and fixed by our team the following Tuesday. Our MTTR is an area though that we must continue to strive to meet and exceed across all levels of vulnerabilities and it remains a key focus area for our team.
In terms of the quality of reports and ingenuity of the research being used, it’s been phenomenal to see and a constant learning opportunity for our teams. One report that sticks out both because of the quality of the writing and report, but also because of the innovative method of exploit is this report from Nyangawa involving a command injection into Gitaly, that led to remote code execution. The bug itself was one of the easier ones to fix, but one that we were able to then proactively research, find, fix and prevent on a broader basis.
Q: GitLab publicly discloses every valid bug once fixed. How many bugs has GitLab disclosed thus far and why is transparency so important to the program?
James Ritchey: Since the program’s inception, we’ve resolved 479 valid reports. Over 400 of those have been made public. You can see from our disclosure policy that resolved reports will be made public via issues on GitLab.com 30 days after releasing a fix. There are certain reports, however, that we cannot disclose due to sensitive information; either at the request of the reporter or to protect a customer. Not only is transparency one of GitLab’s core values, from a security perspective it helps us build and strengthen customer trust. Being transparent about our security issues truly illustrates how invested we are in securing GitLab. Customers can see the importance we place on securing our product and, by disclosing full vulnerability information after 30 days, we’re giving them the time and information to apply mitigations and make their environments more secure.
Q: What has been the biggest benefit of publicly disclosing valid bugs once resolved?
James Ritchey: In addition to maintaining and growing customer trust as mentioned above, publicly disclosing valid bugs reduces the threshold to contribute and helps our reporters build upon previous findings which ultimately makes our product and customers more secure.
Q: How have VDPs and bug bounties changed the open source community?
Ethan Strike: Just as vulnerabilities found and disclosed within GitLab help our reporter community and our security team build upon and proactively protect our product more broadly, openly disclosed findings make the wider open source ecosystem more secure. Open source means you can see the code and make changes to it. With the code being open, security fixes can be found and fixed faster. We believe our program models this and we’re proud of that.
Q: How do you hope to see security evolve for open source platforms in 2020?
Ethan Strike: We’d love to see more collaboration amongst organizations within the open source ecosystem. Our GitLab Security Researchers are already researching, finding and helping to fix bugs across open source tools. With time, we’d love to grow and expand this program and are excited about the potential positive impact for our customers, our community and the broader open source and security industry.
To learn more about GitLab’s scope, payouts, and to start reporting bugs, visit the program page at https://hackerone.com/gitlab.