2020 was a highly-productive year, and one with high impact, which brought a number of security enhancements across GitLab’s product and environment.
Our primary goal of strengthening GitLab’s enterprise grade security was accomplished through the implementation of numerous security controls and led to the successful completion of our first SOC 2 Type 2 attestation. We completed a 2 month field security study which consumed and aggregated data from current and prospective customers, the broader community, industry and several internal stakeholders (sales, support and product) to generate a report with prioritized areas of focus for our SaaS service. Our teams have started strategic work aligned to these priorities and designed to further enhance security in our enterprise service, strengthen our competitive position and bolster the trust and confidence of our customers.
We also saw advancements in our goal of reducing the threat landscape. Vulnerability management was dramatically improved across all aspects of security including application security (reduced: time to mitigate, total overall vulnerabilities, and number of high severity vulnerabilities), infrastructure security (improved scanning capabilities and accuracy of detection as well as reduced time to patching and mitigation) and bug bounty (increased engagement, improved response and remediation). We implemented an industry leading governance, risk and compliance tool which improved the effectiveness and efficiency of risk management and third-party vendor reviews. As a result, we saw a substantial improvement in customer adoption and third party security scoring.
As we look ahead into 2021, we will continue to focus on strengthening the security of GitLab Core and SaaS through a number of new and improved security features and services. Further, we will ambitiously pursue a host of compliance certifications to independently validate implemented security controls designed to protect company and customer data. Lastly, we continue to strive for and assert ourselves as the most transparent security organization in the world. We are committed to finding creative and innovative ways of sharing our approach to security openly in our publicly available handbook and blogs.
Stronger intel for increased visibility, detection and response
Next gen SIEM
In October, our Security Incident Response team (SIRT) onboarded a next generation SIEM from Panther Labs to increase visibility into our environments, improve processes around our log volumes, and build modern detection and response processes. This increased visibility into the infrastructure for GitLab.com and the GitLab organization allows SIRT to more effectively reduce risk for customers and users and increases confidence in our platform. By leveraging modern tooling, we are able to manage the large volumes of logs and event data that are produced each day, scale our processes, and highlight potentially serious issues before they impact the community. In 2021, we’ll dive into this tooling and further build upon our detection and response processes and capabilities.
Publicly-available deep dives into technical challenges
During our day-to-day work, the GitLab Red Team often stumbles upon technical challenges that we need to overcome. We felt that it was important to capture these challenges and the solutions we discover and document them to help others who may be doing similar work and encountering the same problems. We created a public project called Red Team Tech Notes and began documenting things there. This project contains everything from our public technical presentations to research papers and discovered vulnerabilities. By sharing this information publicly, others can learn and benefit from our work and experiences. In addition, we encourage the community to provide us with feedback on our research that may help us learn new things, improve our operations and increase the value and quality of our content. In 2021, we'll be focusing on purple-teaming, business relevant table-top exercises and improving existing tooling to aid our SIRT team operations. We're also going to be holding an Ask Me Anything/AMA session on Jan 26 and we'd love for you to join us.
Note: Shout out to @Jurbanc and @smanzuik who provided content for this section!
Security assurance: from audits to automation
Achieving SOC2 compliance
Our Security Assurance team team kicked off 2020 with the achievement our first security certification in February, a SOC 2 Type 1 report based on the trust service criteria related to security. Obtaining the SOC 2 Type 1 report provides our customers with a measurable result of GitLab, Inc. and GitLab.com’s overall security posture. Additionally, the report provides insight into security and entity level controls implemented at GitLab to ensure compliance with industry standard security requirements. It also serves as attestation by an independent third-party on the effectiveness of our security controls for the proper storage and processing of client data. We blogged about our experience in this first audit in “The benefits of transparency in a compliance audit”.
Proactive security risk identification and mitigation
Later in 2020 (April and May), our team formally established a Security Operational Risk Management program (StORM) and executed our first NIST/ISO based annual security risk assessment. StORM implements a proactive approach to identifying and mitigating security risks for GitLab the company and the product. In building this program, the Security Assurance team identified risk factors surrounding the impact of security risks internally, to customers and to our legal and regulatory obligations. This program helps us prioritize risk mitigation activities according to the impact a security risk may have on customers and provides customers with assurance that security risks impacting the GitLab product are triaged and mitigated accordingly, based on the risk level.
Your questions, answered transparently and efficiently
To increase transparency and support self-serve access to GitLab’s security information and collateral, our Security Assurance team deployed the first iteration of GitLab’s Customer Assurance Package (CAP) in April. Like all software vendors, we routinely receive requests about the security posture of our products and services from customers and potential customers. The CAP increases our efficiency and reduces time to closure of vendor security assessments on GitLab. Our intent is to continue to grow and curate package content based on GitLab customer needs. Since deployment, the CAP has matured to version 2.0 and an internal RFP tool, GitLab AnswerBase, has been deployed using GitLab.com to enable future package expansion through standardization and automation.
What’s next? Our Security Assurance team has kicked off SOC 2 Type 2 and SOC 3 audits and look forward to receiving and sharing reports in Q1 2021. The new year will also bring a heavy focus on automating continuous control monitoring and expansion of our CAP to better meet our customers needs.
Note: Shout out to @mmaneval20, @sttruong, @lcoleman @dsharris and @julia.lake who provided content for this section!
Securing our product with automation, dependency scanning and bug hunting
Preventing accidental key disclosure
The Security Automation team, in collaboration with the GitLab Secure & Protect teams and our AWS Security counterparts, has developed functionality to identify AWS instance keys that are accidentally publicly disclosed through a repo on GitLab.com. The new functionality will alert AWS of the disclosure and the finding will appear in the security dashboard within the GitLab project. The issue of accidental key disclosure is serious and warranted action to protect our customers and community members from key compromises that could lead to significant data breaches and unexpected incurred infrastructure costs. This added functionality allows the repo owner and AWS to take action to prevent the malicious use of the disclosed key.
Package Hunter for enhanced dependency scanning
Applications today tend to rely upon 3rd-party dependencies to enable functionality, but securing that supply chain is a difficult problem. Most existing dependency chain security tools help developers to identify dependencies known to be malicious or with known vulnerabilities. The Security Research team has developed a product, called Package Hunter to identify malicious packages using dynamic behavior analysis. The type of malicious dependencies that Package Hunter seeks to identify are those that try to exfiltrate sensitive data, or run unintended code, such as a cryptocurrency miner. Package Hunter is still in the prototype phase, but is already running in GitLab pipelines as we work on maturing its functionality. It enhances existing dependency security tools by identifying not previously known malicious packages as part of their security testing and will help developers avoid adding malicious dependencies before merging them fully into their application.The hope is to transition Package Hunter into a product feature that all customers can use to secure their applications.
Squashing bugs and vulnerabilities
Our bug bounty program takes a community-driven, hacker-powered approach to security and plays a crucial role in our multilayered approach to reducing risk. 2020 was a big year for this program, starting off with a bang as we hit the million dollar bounties paid milestone in January, followed by making our way to #6 on HackerOne’s 2020 Top Ten Public Bug Bounties program list in June. Throughout the year, the program received a total of 1082 reports from 508 security researchers and awarded $381K USD in bounties. Our development teams resolved 268 reports and, true to our value of transparency, we have made 133 of those reports public (see our disclosure policy). The success of this program and the innovative contributions from these deeply talented security researchers across the globe further secures and strengthens our product and company. In 2021, we’ll continue refining our processes, driving down triage and response times, and developing initiatives focused on recognition and engagement. You can read more about this program in this HackerOne case study.
Note: Shout out to @laurence.bierner, @dappelt, @estrike and @heather who provided content for this section!