GitLab protects your data with encryption in transit and at rest, providing organization-wide protection mechanism such as SAML SSO and enforced 2FA.
GitLab CE is open source and has over 2,000 contributors. This means there have been over 2,000 pairs of eyes looking at the GitLab CE source code. GitLab EE is open-core, which means the source code is also open for inspection to our customers.
GitLab releases patches for vulnerabilities in dedicated security releases.
There are two types of security releases: a monthly, scheduled security
release, released 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
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
To be notified when a security release is released, the following channels are available:
We are committed to protecting the privacy of your data, preventing it from unauthorized access.
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. 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.
Oversight of Data Security is handled by GitLab's Data Protection Officers. Should you wish to make modifications, deletions or additions to any personal data you believe to be captured by GitLab, or if you have any general security concerns, please contact a GitLab Data Protection Officer (DPO) by emailing email@example.com.
In the event you feel that you have not received proper attention to your data concern, or if you have any other legal/law enforcement concern - please contact GitLab's Legal Department at Legal@gitlab.com.
You also always have the right to lodge a complaint with a supervisory authority if you believe that your data is being misused.
A SOC 2 (Service and Organization Controls) examination with a third party assessor is on GitLab's 2020 security compliance roadmap. Whereas we currently do not maintain an independently certified security controls certification, we do operate within an information security control framework
Please visit our Security Compliance page for more information on our Compliance Roadmap.
GitLab Enterprise Edition (EE) and GitLab Community Edition (CE) work seamlessly in HIPAA-controlled environments. These products do not store, process or transmit any patient related healthcare information. As a result, GitLab EE and GitLab CE have been implemented by hundreds of healthcare-related companies. If your company needs to ensure HIPAA compliance, GitLab will work with your security team to ensure that basic compliance criteria are met. If more extensive security procedures are required, GitLab has a number of partners that specialize in helping companies comply with industry accepted data security standards.
GitLab also has a responsible disclosure program.
GitLab's on-premises product as well as GitLab.com SaaS is subjected to security tests regularly through a combination of:
Grimm carries out a black box
assessment of GitLab and GitLab.com annually and the last assessment was performed in Q3 of 2019. Their report is available for
(prospective) enterprise customers by emailing
Given that penetration testing and other simulated events are frequently indistinguishable from real life attack activities and have the potential to impact performance and site reliability, we do not permit customers, prospective customers, or members of the larger GitLab community to conduct penetration tests and vulnerability scans to or originating from the GitLab.com environment.
GitLab, by its remote-only nature, is not easily affected by typical causes of business disruption, such as local failures of equipment, power supplies, telecommunications, social unrest, terrorist attacks, fire, or natural disasters.
The detailed business continuity plan is documented in the BuinessOps section of this handbook.
This policy defines what qualifies as a breach of user data, what actions will be taken in the event of user data exposure or compromise, and the timeline for action.
This policy applies to user data stored on GitLab.com and GitLab Hosted (GitHost). It does not apply to self-managed / on-premises GitLab instances or instances hosted with other providers than GitLab.com and GitLab Hosted.
This policy covers "private user data" stored by GitLab.com and GitLab Hosted, and includes:
Note: GitLab.com and GitLab Hosted do not store any "personally identifiable information" (PII) such as (i) Private Addresses, (ii) Credit Card Numbers, (iii) Bank Account Information, (iv) ID numbers (e.g. passport, driver's license, social security, national identification, etc.). GitLab.com and GitLab Hosted also do not store any "personal health information" (PHI). Therefore, laws and regulations relating to PII and PHI do not apply.
A breach of user data is the unintended or accidental exposure of private user data. This can be caused by accidents, misconfigurations, or malicious actions performed by an external attacker or team member.
An event is considered a data breach when there is evidence that private user data has been exposed to the public or to an untrusted third party.
Trusted third parties may have authorized access to user data under a signed Non-Disclosure Agreement (NDA). Such trusted third parties include but are not limited to:
Some examples of a user data breach would include:
Examples of security incidents that would not be considered a breach of private user data:
If GitLab has detected evidence of a breach of GitLab.com or GitLab Hosted private user data, all affected users will be notified via the configured email address for their accounts. Emails will contain information on what data was exposed or compromised, when, and for how long (to the extent this information is available).
For a breach that exposes private data for a large number of users, the public will also be informed via the configured email addresses for their accounts, and additional means of communication will be considered (e.g. press release, the blog, etc.) on a case by case basis.
GitLab will endeavor to notify users within 24 hours of breach discovery. This may be delayed when necessary to comply with requests by law enforcement.