Shifting Left with Ethical Hackers: A Q&A with GitLab

We sat down with James Ritchey, Application Security Team Manager at GitLab and a three-year member of HackerOne’s Technical Advisory Board. James talked about how GitLab is shifting left to bring security into every stage of DevSecOps, and how bug bounty helps them improve with product security. 

James also shared his advice on working with ethical hackers to secure products in the cloud and how GitLab leverages ethical hacker findings to identify vulnerability patterns that help them focus their internal efforts to build a more effective security program. 

Read on to see what James had to say. 

Tell us who you are.

I’m James Ritchey, an application security team manager at GitLab. I’ve been working in the information security field for over ten years, specifically focusing on securing applications and secure software development. My role at GitLab encompasses exactly that, raising the security bar for our product through all stages of the DevOps lifecycle.

Tell us a bit about GitLab’s goals. 

James: Our strategic goal is to be known as the leading complete DevOps Platform delivered as a single application. There are many stages of the DevOps lifecycle. Since this can lead to complexity, the number one challenge for our security team is to ensure we’re baking security in from the beginning and focusing on secure architecture and design. It is much easier and more cost-effective to prevent bugs (and thus vulnerabilities) before they make it to production. The earlier in the SDLC they’re identified and prevented, the better.

Who is accountable for cloud security in your organization? 

James: At GitLab, we are focused on shifting left and making security a part of everyone’s role. We believe that developer and security teams alike are responsible for keeping our code and product secure. Our Infrastructure and Infrastructure Security teams are the main teams responsible for securing our cloud environments. Of course, there is frequent cross-collaboration between these two teams and others when we have shared objectives.

What led you to HackerOne?

James: One of our biggest security challenges before implementing a bug bounty program was scaling. The global ethical hacker community is more extensive than our dedicated team, which allows us to scale identification of security issues in our product. Now, we have access to innumerable security experts who help our team and give us additional time to work on other security initiatives. 

At what stages are you designing security into your DevSecOps strategy? 

James: GitLab has shifted security left, implementing DevSecOps practices throughout the SDLC, thereby making the platform secure by design. At GitLab, we make it everyone’s responsibility to ensure security, including developers. 

The application security team supports issue triage and grooming, secure design and threat modeling, CI/CD testing, merge request review, post-deployment testing, and secure development training. We utilize HackerOne during the post-deployment testing phase, where the reporters help identify security issues that made it to production or publicly available features behind a feature flag. This is where hackers help us reduce risk the most.

How does HackerOne Bounty help your vulnerability management program? 

James: Bug bounty makes our program even more effective by scaling identification of vulnerabilities through crowdsourcing, especially vulnerabilities that can’t be automated or are difficult to automate. I also find the cost-benefit analysis to be in favor of bug bounties when compared to third-party penetration tests. Pentests are compensated based on time, whereas bug bounty is based on results. 

What lessons have you learned using bug bounty for product security? 

James: No matter how secure you think a product is, it’s never secure enough, so focusing on defense-in-depth mitigation controls is just as important as vulnerability prevention. When we got started with the program, we quickly learned to identify patterns among report submissions, such as entire vulnerability classes or issues affecting brand-new features, which helped us focus our efforts and more effectively work with reporters. Using HackerOne Bounty has allowed us to put more time into earlier aspects of the SDLC, such as performing threat modeling and ensuring secure feature design.

Every critical vulnerability confidentially reported to us through HackerOne is considered a major breach avoidance. Fortunately, the product's security has been improving. We've seen a 58% decrease in valid critical reports in 2021 compared to the previous year. The platform also makes it easy for our team to identify patterns in specific vulnerability classes that repeatedly affected us. Server-Side Request Forgery (SSRF) issues used to be prolific throughout the application, averaging 13 reports per year before 2020. Since then, we’ve made security enhancements to the product and have only received three SSRF reports. 

Tell us about your cloud security concerns.

James: GitLab is a cloud-native company. We place emphasis on expanding our SaaS offering to meet the most demanding customer requirements and driving towards feature parity with our market-leading, self-managed offering. HackerOne helps complement our cloud security strategy by continually strengthening our product through each security report received, increasing customer trust and confidence.

Any advice for other organizations looking to ethical hackers to secure cloud products?

James: Companies looking to hackers to secure cloud practices should consider a few things before getting started. First, the team must determine which vulnerabilities are the most critical. Those critical vulnerabilities will be where hackers and team members spend the most time. Then, be sure to take stakeholder feedback into account. Listening to the bug bounty vendor, reporters, security team, and others will help you understand how to improve and innovate. 

Timing is also critical in these situations. Time to response, triage, bounty, and fix all impact how a security program, and a bug bounty program, function. Keeping a tight schedule helps keep hackers engaged, informed, and incentivized. As the program becomes more successful, the organization will (hopefully be receiving numerous reports. Often, it is difficult to react and respond to all of these reports, and that’s where automation comes in. If you can automate parts of the process, like communication and report management, the process becomes much more manageable and can begin to scale. Finally, in accordance with GitLab’s values, it’s essential to practice transparency. Organizations are often wary of transparency in security, but in the end, it will demonstrate commitment to security, inspire new reports, and extend public recognition to the security researcher. Following these practices can help companies create a successful bug bounty program.

How do you build great relationships with hackers?

James: It’s important to keep hackers engaged in your program because they have a choice when it comes to what programs they contribute to. If they have a good experience when interacting with our team, there’s a good chance they will be repeat reporters. Whether through our policy, scope, or rewards, we do our best to openly communicate what reporters can expect when contributing to our bug bounty program. 

To keep hackers engaged, it’s important to have competitive incentives, respond quickly to reports and demonstrate the value the company sees in hackers. That’s why GitLab hosts an annual Bug Bounty Contest. Last year, we held our third contest and increased our bounties across all ranges. This resulted in 752 reports from 405 security researchers in 2021 and 115 security researchers who were repeat reporters.  

Our program and product's transparency attracts and engages hackers. GitLab is an open-core product with the source code readily accessible, making it easier for hackers to find security bugs through white-box testing. Hackers have given us feedback that they enjoy reading through our source code to find vulnerabilities and that they stick with our program because it is open-core. Additionally, we set fixed vulnerabilities to public disclosure 30 days after the patch has been released, which helps inspire other hackers to find related security issues. This enables the reporters of those vulnerabilities to share their findings with the rest of the community to gain further recognition. Hackers can also see and access new product features that are in development or in beta, which can be a prime area for discovering new security issues.

What will long-term success look like?

James: Focusing on our reporters is key to the long-term success of our bug bounty program. That we’re continuing to attract the top HackerOne reporters to our program, keeping them engaged, that they know what to expect when participating in our program, and that they are being well-compensated for their contributions. We will consider ourselves successful as long as hackers continue to participate in our program, feel valued and make actionable contributions. 

Click here for more information about bug bounty programs.