Published on: June 9, 2025
5 min read
Last year we signed the Secure by Design pledge - here's our progress
Learn about GitLab's CISA-aligned additions and improvements around MFA, default password reduction, patching, and vulnerability disclosure.
A little over a year go, GitLab signed CISA’s Secure by Design Pledge, a directive for technology providers to embed security at the heart of their products from the outset of development. Since then, we've made significant progress towards improving our security posture and creating a more secure ecosystem for our customers to develop secure software faster.
Meeting the security goals
Let’s explore the additions and improvements we've made to further enhance security across the development lifecycle.
Multi-factor authentication (MFA)
Goal: Within one year of signing the pledge, demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer’s products.
GitLab currently offers multiple MFA options for users to secure their accounts. We also offer SSO functionality to enable GitLab.com, Self-Managed, and GitLab Dedicated customers to streamline their authentication processes and their internal MFA requirements.
To further enhance the platform’s resilience, and to create a more secure foundation for our customers, GitLab is executing a phased MFA by Default rollout.
In the coming months, we will deploy changes requiring all customers to enable MFA on their accounts.
For customers who already have MFA enabled or authenticate to GitLab via their organization’s single sign-on (SSO) method, there will be no necessary changes. For customers who do not already have MFA enabled and are not authenticating to GitLab via their organization’s SSO method, they will be required to enable MFA and enroll in one or more of the available MFA methods.
The MFA rollout will occur in stages to ensure a smooth and consistent adoption across all customers. More details on GitLab’s MFA by Default rollout will be shared in the near future.
Default passwords
Goal: Within one year of signing the pledge, demonstrate measurable progress towards reducing default passwords across the manufacturers’ products.
To reduce the use of default passwords, GitLab uses randomly generated root passwords for its multiple installation methods. GitLab’s multi-method installation instructions also include guidance on how to change the randomly generated root password for each installation.
For some install methods, such as installing GitLab in a Docker container, the password file with the initial root password is deleted in the first container restart after 24 hours to help further harden the GitLab instance.
Reducing entire classes of vulnerabilities
Goal: Within one year of signing the pledge, demonstrate actions taken towards enabling a significant measurable reduction in the prevalence of one or more vulnerability classes across the manufacturer’s products.
GitLab has published secure coding guidelines to its documentation site that contains descriptions and guidelines for addressing security vulnerabilities commonly identified in the GitLab codebase.
The guidelines are “intended to help developers identify potential security vulnerabilities early, with the goal of reducing the number of vulnerabilities released over time.”
GitLab continues to improve its SAST rule coverage to address broader sets of security vulnerabilities for itself and its customers.
Security patches
Goal: Within one year of signing the pledge, demonstrate actions taken to measurably increase the installation of security patches by customers.
GitLab handles all updates related to its GitLab.com and GitLab Dedicated service offerings. Additionally, GitLab publishes a maintenance policy, which outlines its approach to releasing updates, backporting, upgrade recommendations and supporting documentation, etc.
GitLab’s documentation has comprehensive guidance on how to upgrade self-managed instances based on their deployment model. This includes Omnibus, Helm chart, Docker and self-compiled GitLab installations.
GitLab also provides a detailed upgrade plan to ensure proper testing and troubleshooting can be performed as well as rollback plans if necessary.
Depending on the version upgrade, specific changes (example for GitLab 17) for each version are highlighted to ensure a smooth upgrade process and limit unavailability of services.
Vulnerability disclosure policy
Goal: Within one year of signing the pledge, publish a vulnerability disclosure policy (VDP).
GitLab maintains a strong bug bounty program through HackerOne, a security.txt file highlighting GitLab’s preferred and additional disclosure processes, and release posts highlighting security fixes.
Customers and the general public can subscribe to receive GitLab’s release posts directly in their email inbox.
Common vulnerability enumerations
Goal: Within one year of signing the pledge, demonstrate transparency in vulnerability reporting
GitLab includes the Common Weakness Enumeration (CWE) field in all Common vulnerability enumerations (CVE) records it publishes. Over the past year, GitLab has iterated to also include the Common Platform Enumeration (CPE) field in CVE records.
The GitLab CVE assignments project stores a copy of all CVE identifiers assigned and published by GitLab in its role as a CVE Numbering Authority.
Check out GitLab’s CVE submission template.
Evidence of intrusions
Goal: Within one year of signing the pledge, demonstrate a measurable increase in the ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer’s products.
GitLab has published an incident response guide to help customers respond to incidents involving GitLab instances. Additionally, GitLab has open sourced versions of its GUARD detection-as-code and TLDR threat detection frameworks. The repositories for those open source frameworks can be found on GitLab’s Open Source Security Center.
In a similar manner, GitLab is adding functionality to its GitLab.com service offering to detect compromised passwords for all logins using GitLab’s native username and password authentication method.
What's next
GitLab’s Security Division’s mission is to enable everyone to innovate and succeed on a safe, secure, and trusted DevSecOps platform.
GitLab's security enhancements over the past year have allowed us to demonstrate our commitment to CISA’s Secure by Design Pledge, and they have strengthened our platform and given customers a more reliable and secure foundation to build on.
Our commitment to iteration means we're already focused on the next set of innovations that will drive us forward.
To learn more about GitLab’s security enhancements, bookmark our security page on the GitLab Blog.