GitLab’s Public Bug Bounty Program Kicks Off: Q&A with GitLab’s Kathy Wang & James Ritchey

Dec 12 2018
HackerOne

GitLab is a single application for the entire DevOps lifecycle, making software development easier and more efficient, without sacrificing security or quality. The organization lives and breaths open source, so it only makes sense that they would approach cybersecurity with the same open source strategy. After running a private bug bounty program and public vulnerability disclosure program (VDP) on HackerOne, GitLab is launching their first public bug bounty program today. 

We sat down with GitLab's Director of Security Kathy Wang and Senior Application Security Engineer James Ritchey to dive into the evolution of GitLab's program over time, their decision to go public with their program, and how leveraging HackerOne's community has helped to find and fix security issues quickly. Here’s a peek at the conversation:

Q: Why did GitLab decide to start a bug bounty program in the first place?
Kathy:
At GitLab, everyone can contribute. Our product is open source. Back when GitLab started the bug bounty program, the Security Team was very new, and this program with HackerOne helped us scale and highlight where the vulnerabilities were in our product so we could fix them faster.

Q: Why did GitLab choose HackerOne to manage its bug bounty program? Why are you not just managing yourselves?
Kathy:
It isn’t easy to hire great people in security. Choosing HackerOne (and their experts) to manage our bug bounty program allowed us to focus in other areas required to scale our security efforts. For example, we were able to focus on hiring security practitioners for our Application Security and Security Operations teams.

Q: Did GitLab run a pilot or private program first and a public VDP? Can you tell me how long those programs ran, how many bugs within the project scope were found and if its success led you to launch an official program?
Kathy:
Initially, GitLab ran a public VDP that didn’t offer bug bounties, which kicked off in 2014. GitLab introduced a small private bug bounty program in December 2017. Since launch, the GitLab VIP (invite-only, private program) and the public VDP have resolved nearly 250 vulnerabilities thanks to the over 100 participating hackers. The GitLab VIP program has paid out $194,700 in bounties. We considered the private bug bounty program and public VDP tremendously successful and good training for an eventual public program launch. Today, both programs are being consolidated into one public bug bounty program.

Q: Why is the program going public now?
Kathy:
We wanted to extend our open source contribution values to responsible disclosure of security vulnerabilities, as well as to our source code base. We picked this timeframe to go public with the GitLab bounty program after consulting with the HackerOne team. They were able to provide us with relevant metrics and logistics to consider when taking a program public, so that we could make an informed decision. We are committed to collaborating with the hacker community, and we’ve been preparing to facilitate this collaborative initiative by developing better processes and improving response times with automation, so that hackers will want to continue to collaborate with us.

Q: What is different about GitLab’s bug bounty program and why is opening up your software to hackers important?
Kathy:
GitLab is more transparent than most companies. From my perspective as a long-time security practitioner, GitLab is the most transparent company I have every worked for. We currently make the details of security vulnerabilities public 30 days after the mitigations have been released. I do not think many companies do this consistently, but we do.

Q: How has and will the bug bounty program impact GitLab’s larger cybersecurity strategy?
Kathy:
We take security very seriously here at GitLab, and our HackerOne Bounty program is part of our approach for our defense-in-depth strategy. The GitLab platform also has built-in security scanning capabilities that alert on library dependency-related security vulnerabilities at the time of code merge. We also conduct internal application security reviews. Everyone who has been in the security industry long enough knows that there is no silver bullet in security - you have to mitigate vulnerabilities from multiple angles.

Q: As an open-source platform yourselves, how is fostering relationships with the hacker community similar to the developer community?
James:
I'd say fostering relationships with the hacker community is more or less the same as fostering relationships with the development community. Key points include transparent communication, building trust, respecting and valuing their input, and showing appreciation by rewarding contributions.

Using the HackerOne platform helps us cultivate those relationships, and it resonates well with our GitLab mission that everyone can contribute. That includes security bug contributions and not just code.

Q: How has the cloud impacted security at GitLab? How has hacker-powered security helped?
Kathy:
GitLab is a cloud-native company. There is literally no physical office - all employees are remote, across 40+ different countries. Every third party product we use is SaaS-based. GitLab.com is hosted on Google Cloud. There is no firm perimeter, from a security perspective. We have to focus on access and credentialing management, as well as internal application security reviews, for example. Working with hackers helps the team scale, so that we can focus on other areas as well. 

Q: What has been one of your favorite hacker interactions to-date? Any favorite bugs?
James:
@fransrosen is always a pleasure to work with. He always maintains a professional demeanor and his reports are always very detailed by showing clear impact through his proof of concept exploits.

There are many interesting bugs that have been reported to the program to-date, but one of my favorites was a critical finding from @nyangawa (Report #378148). The hacker was able to bypass a filename regular expression and create a symbolic link in Gitlab upload directory. The vulnerability also allowed.the hacker to delete an imported project and create a shell with the same permission of the system gitlab user.

Kathy: I also want to call out @jobert, for the great contributions he has made to our program. Overall, we have been impressed by the level of professionalism from most of the hackers we have worked with.

Q: What advice would you give other organizations about starting a bug bounty program?
Kathy:
The biggest factor when starting a bug bounty program is being prepared from a staffing perspective, and making sure that you have the support structure in place to mitigate those findings. That means having engineers who can validate the findings, triage them, and interface with developers to execute the mitigations. We also have security automation engineers on the Security team who have put in significant work to help us scale when responding and triaging the findings reports. This means better hacker engagement, which helps hackers stay interested in our program. We’ve also seen significant temporary increases in reported findings with each bounty increase, so be prepared for that.

Q: Now, what’s next?
Kathy:
Our Security Team has more than quintupled over the last year, and we will continue to grow in 2019. By the end of 2018, we will discontinue support for TLS 1.0 and 1.1 for GitLab.com. We are also rolling out Zero Trust in 2019. We are also planning a gamification program for HackerOne hackers on our program to provide interesting rewards (e.g., exclusive HackerOne-only GitLab swag to top hackers, etc.)  beyond the bounty payments.


If you’re interested in learning more about GitLab’s program or want to get hacking, check out the GitLab public program page at https://hackerone.com/gitlab
 

Related Posts