At GitLab, security is a priority. But so is transparency. And that's why it is so important that our Customers and Prospects have the most accurate information regarding our security. We designed this Frequently Asked Questions page to serve as a starting point for those interested in GitLab's Security. For more in depth resources, please visit our Customer Assurance Package.
A - GitLab has two deployment models. The first is a multi-tenant public cloud Software as a Service (SaaS). For customers who utilize the SaaS model, GitLab.com, GitLab deploys, operates, monitors, and maintains the instance continuously. The second is Self-Hosted. With this method, the customer is responsible for deploying, operating, monitoring and maintaining GitLab software on their own infrastructure.
A - These are cloud computing terms defined in the National Institute of Standards and Technology Special Publication 800-145: The NIST Definition of Cloud Computing. To summarize, Multi-Tenant refers to the fact that multiple entities are deployed on the same underlying Infrastructure. Public Cloud refers to the fact that GitLab.com is open to most users with an internet connection with the few exceptions noted in our Terms of Service
A - Yes, GitLab.com is deployed on Google Cloud Platform (GCP) Infrastructure as a Service (IaaS). For detailed architecture please see our Production Architecture
A - There is no one-size fits all solution, however for most entities GitLab.com is the most efficient and secure way to make use of all the great features GitLab offers. GitLab.com comes preconfigured and running and it takes minimal internal resources to support. Some entities with highly specific needs may choose to deploy GitLab as a self-hosted software to tailor GitLab to their needs. If you need help determining which is right for your organization our Sales team would be happy to help evaluate your needs.
A - In a cloud computing environment it is important to understand the roles and responsibilities all parties have in keeping data secure. To learn more about Shared Responsibilities at GitLab see our whitepaper.
A - Yes; GitLab has a dedicated Security Department. The current individual makeup of our security team can be seen on our About the Team Page
A - Yes; GitLab has a robust information security program and many of our policies and procedures are publicly accessible.
A - Yes. GitLab's Security Compliance Controls are publicly viewable. The GitLab Control Framework forms the building blocks of our Security Compliance Program.
A - Yes; GitLab currently has a SOC2 Type 2 Report that can be provided under NDA. GitLab has a publicly available SOC 3 that can be found here.
A - Yes, Yes, and Yes. GitLab takes the security of data our customers entrust us with very seriously. Data is Encrypted at Rest using Google Cloud Platform's Encryption at Rest with the AES-256 Algorithm. All data in-transit is encrypted using TLS 1.2.
A - Yes; You can view our Incident Response Guide in the Handbook.
A - Yes. Our 3rd Party Penetration Test Summary can be provided under NDA.
A - Yes. GitLab, Inc's Business Continuity and Redundancy plans is available in the Handbook for our SaaS customers.
A - GitLab is the Data Processor and our Customers are Data Controllers. GitLab collects information required to set up your GitLab.com account. Please see our DPA on the Privacy Compliance page.
Personal Details (including but not limited to):
A - GitLab releases patches for vulnerabilities in dedicated security releases.
There are two types of security releases: a monthly, scheduled security
release, that is targeted to go out a week after the feature release (which deploys on the 22nd of each month),
and ad-hoc security releases for critical vulnerabilities. The fix for every
vulnerability is backported to the current release, and the 2 previous
major.minor versions.
To help you understand the vulnerabilities that were fixed, a blog post accompanies
each security release and includes a brief description, the
versions affected, and the assigned CVE ID for each vulnerability.
Feature and security release blog posts are located in the releases section of our blog.
In addition, the issues detailing each vulnerability are made public 30 days
after the release in which they were patched. It is highly recommended that
all customers upgrade to at least the latest security release for their
supported version.
To be notified when a security release is released, the following channels are available:
A - GitLab Support will never access private repositories unless required for support reasons and only when requested by the owner of the repository via a support ticket. Forms of access include, but are not limited to, impersonation. When working a support issue we strive to respect your privacy as much as possible. Once we've verified account ownership, we will only access the files and settings needed to resolve your issue. Support may sign into your account to access configurations but we will limit the scope of our review to the minimal required to solve your issue. In the event we need to pull a clone of your code, we will only do so with your consent. All cloned repositories are deleted as soon as the support issue has been resolved. There are two exceptions to this policy: we have determined that there has been a violation of our terms of service or if we are compelled as part of a legal matter.
This FAQ applies solely to our Software as a Service (SaaS); GitLab.com.
