Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Security - Trust Center

On this page


GitLab protects your data with encryption in transit and at rest, providing organization-wide protection mechanism such as SAML SSO and enforced 2FA.

Security of GitLab as an Open-Source Product

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.


We are committed to protecting the privacy of your data, preventing it from unauthorized access.

GitLab's Access to Your Private Repositories

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.

Data Protection Officers

Oversight of Data Security is handled by GitLab's respective 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 concern, please contact the Data Protection Officer (DPO) for your respective territory at the following email address:

For the Americas: Johnathan Hunt and Jeff Burrows

For Europe and Middle East: Jan Urbanc

For Asia Pacific: Robert Mitchell

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

You also always have the right to lodge a complaint with a supervisory authority if you believe that your data is being misused.

Other Contact Methods


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.


  1. Do you maintain a quality management system (QMS) approved by management? In lieu of a formal and static QMS, GitLab has a dynamic and responsive approach to quality management. Does your quality management system (QMS) include coverage for software application security principles?
    • YES
  2. Is quality management system (QMS) content published and communicated to all relevant employees?
    • YES.
  3. Is quality management system (QMS) content reviewed and updated (if appropriate) at least once per year?
    • It is considered a constant Work In Progress; and updated almost daily in small increments.
  4. Is there defined management oversight who is responsible for application quality and security reporting & signoff?
  5. Is access to and maintenance of applications, systems, network components (including routers, databases, firewalls, voice communications servers, voice recording servers, etc), operating systems, virtualization components, hypervisors, or other information objects restricted to authorized personnel only?
    • YES
  6. Is access to and maintenance of applications, systems, network components (including routers, firewalls, voice communications servers, voice recording servers, voice response units (VRU) etc), operating systems, virtualization components, hypervisors, or other information objects granted based upon need-to-know job function?
    • YES
  7. For all IT systems including but not limited to servers, routers, switches, firewalls, databases, and external social spaces, is management approval required prior to creating all user and privileged accounts (e.g., system or security administrator)?
    • YES
  8. For all IT systems including but not limited to servers, routers, switches, firewalls, databases are privileged accounts (e.g., system or security administrator) logged at all times and reviewed on at least a quarterly basis?
    • YES
  9. Are all user accounts (including, but not limited to, standard user, system administrator, security administrator, internal social spaces, etc) assigned to an individual employee and not shared?
    • YES
  10. Are all user accounts disabled after no more than ten unsuccessful logon attempts?
    • YES
  11. For all IT systems (including but not limited to servers, routers, database, switches, firewalls, external social spaces), are inactive user and privileged accounts (e.g., system administrator or security administrator) disabled after 90 days or more?
    • YES
  12. Is a user's identity verified before communicating an initial/temporary password or initiating a password reset by an automated or manual process?
    • YES
  13. Do application, system, and device passwords (including routers, firewalls, databases, and external social spaces) require passwords to have the following characteristics: 1. minimum length of 8 characters, 2. chosen from any acceptable character sets available on the target system, 3. includes at least one alphabetic and one numeric character.)
    • YES
  14. Are passwords prevented from being displayed in clear text during user authentication or in electronic/printed reports?
    • YES
  15. Are passwords/PINs sent to users utilizing a secure method (e.g. secure e-mail) and sent separately from other authentication information such as the user account?
    • YES
  16. For all IT systems (including but not limited to servers, routers, databases, switches, firewalls), are user and privileged account (e.g., system or security administrator) passwords changed at least every 90 days?
    • YES
  17. Are users required to authenticate prior to changing their password?
    • YES
  18. Are all system, application and device password files encrypted using an industry standard encryption algorithm where technically feasible?
    • YES
  19. In instances where a software token is used to access an application or system, is a password or PIN required?
    • YES
  20. In instances where a software token is used to access an application or system, are stored keys and software token files encrypted using an industry standard algorithm and smartcards compliant to FIPS level 2 or above?
    • YES
  21. For externally hosted environment, is there separation of administrative access between the hosting infrastructure/platform and the hosted platform and data?
    • YES
  22. If user accounts are assigned to non-permanent personnel (e.g., contractors, consultants) for troubleshooting purposes, are the accounts disabled or removed after each use?
    • YES
  23. Is the retirement or replacement of encryption keys included in key management procedures when the integrity of the key has been weakened (such as departure of an employee with key knowledge) or keys are suspected of being compromised?
    • YES
  24. If you use cloud services, do you ensure that confidential data or an aggregation of proprietary information that can reveal confidential information is encrypted to ensure confidentiality at rest and in transit?
    • YES
  25. If you use cloud services, do you have key management procedures to manage and maintain encryption keys?
    • YES
  26. How does GitLab help companies ensure HIPAA compliance?
    • 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.

Software Development Life Cycle (SDLC)

  1. Are there documented processes, procedures, standards and templates used in your SDLC process?
  2. Do the materials above include references to application security best-practices and principles being followed?
    • YES.
  3. Are design and code reviews performed as part of your SDLC processes?
  4. Are security considerations (checklists, standards and policies) referenced in the design and code review?
    • YES.
  5. Is app security threat modeling performed when deemed appropriate (i.e. new or changed architectures and approaches)?
    • NO.
  6. Is application code managed in a secure configuration management system with access controls?
    • YES.
  7. Is there a configuration management plan and are release artifacts maintained in a configuration management system?
    • YES.
  8. Are test plans and records kept that reflects the tests performed and results observed for each release?
    • YES.
  9. Is security testing defined and included in the test plan for each release?
    • YES.
  10. Is a release criteria defined, measured and reported on to confirm targeted release quality is achieved?
    • YES. We do manual QA testing for each monthly release and deploy all new versions on to be our own test subjects.
  11. Are specific application security characteristics and measures part of the defined release criteria?
    • NO.
  12. Do you work with third parties that may have access to your IP and sensitive data?
    • N/A w.r.t. code, as our code is all open-source (community edition) or open-core (enterprise edition).
  13. If so, is access to data controlled by terms of Non-Disclosure Agreements?
    • N/A


  1. Is Internal company training available & performed commensurate with personnel roles and responsibilities?
    • YES; peer-to-peer training is commonplace.
  2. Does training include security awareness?
    • YES; as applicable for the role.
  3. Does training include education on policies, standards, procedures and updates when needed?
    • YES; as applicable.
  4. Are personnel training plans and records kept for internal company compliance purposes?
    • Tasks and training completed during onboarding are recorded.

Enterprise Protection

  1. Is antivirus protection enabled on endpoints?
    • NO. Antivirus solution will be dependent on management decision on device management strategy. We use Apple Macbook Pro's and Linux GitLab-issued laptops. Mac's provide application sandboxing which will require the malware to escape; requires by default all applications installed are signed. Linux laptops are operating with user trust. GitLab hosts are monitored utilizing Uptycs and OSquery.


  1. Are results from the execution of test plans reported and used to track and justify release readiness?
    • YES. We require all automated tests to pass before any official release (monthly and patch versions), and perform manual QA testing for each monthly release.
  2. Does the quality assurance organization have authority to delay shipment of releases due to non-conformance reasons?
    • YES.
  3. Is some form of static code scanning performed as part of the release acceptance? What tools are used?
    • YES. For example, brakeman and bundler-audit are part of our test suite to be alerted to any security issues in our dependent Ruby libraries.
  4. Is some form of dynamic code scanning performed as part of the release acceptance? What tools are used?
    • YES. We use GitLab CI for this purpose.

Security Response

  1. Do you have a documented company security incident response process?
  2. Do your maintenance releases include fixes for both quality and security related issues?
    • YES.
  3. Do you provide dedicated security patches for software versions that are released and supported in the field? How?
    • YES, for the latest release and the two prior monthly releases, when applicable.
  4. Is there proactive notification provided to customers and software partners (PTC)? How?
    • YES. Notifications in the "version check" image, blog posts, tweets, and a mailing list just for security fixes.
  5. Do you have a formal risk severity classification assessment approach?
    • NO.
  6. Is there a specified response policy that includes the timeframe issues are to be addressed?

GitLab Development Guidelines

GitLab also has a responsible disclosure program.

External Testing

GitLab's on-premises product as well as SaaS is subjected to security tests regularly through a combination of:

Grimm carries out a black box assessment of GitLab and 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 environment.

Business Continuity Plan

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.

Data Breach Notification Policy

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 and GitLab Hosted (GitHost). It does not apply to self-managed / on-premises GitLab instances or instances hosted with other providers than and GitLab Hosted.

Data Classification - What information is covered by this policy

This policy covers "private user data" stored by and GitLab Hosted, and includes:

Note: 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.). and GitLab Hosted also do not store any "personal health information" (PHI). Therefore, laws and regulations relating to PII and PHI do not apply.

What qualifies as a breach

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:

What is not considered a breach

Examples of security incidents that would not be considered a breach of private user data:

Who will be notified in the event of a data breach

If GitLab has detected evidence of a breach of 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.

Notification timing

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.