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 - We’re transparent about our security issues and, where possible, vulnerability details are made public 30 days after the release in which they were patched. We want our users to be informed and also to secure their instances through regular updates. Users can be notified about new security releases though our security notices mailing list, the security release RSS feed or the RSS feed for all GitLab releases. For more information about our security releases and process, see our FAQ entry “How does GitLab handle security releases?”.
We understand that updating software involves time and resources. However, the truth is, any widely used software will have continuously discovered vulnerabilities and any software that is not continually updated, can be vulnerable.
As part of maintaining good security hygiene we urge our customers to keep their instances updated. We continue to be dedicated to ensuring all aspects of GitLab, and our methods for handling customer data, are held to the highest security standards.
For more tips on keeping your GitLab instance secure, read "GitLab instance: security best practices".
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 not access private repositories unless required for support reasons, meaning for account and ownership verification, and when requested by the owner of the repository via a support ticket. Forms of access include, but are not limited to, impersonation. When working on 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 minimum access 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 on accessing private repositories: we are investigating a suspected violation of our terms of service or we are compelled to access repositories as part of a legal or security matter.
This FAQ applies solely to our Software as a Service (SaaS); GitLab.com.
