Blog Security GitLab native secrets manager to give software supply chain security a boost
Published on: May 20, 2024
4 min read

GitLab native secrets manager to give software supply chain security a boost

GitLab is building a secrets manager that is key to providing an end-to-end, cloud-agnostic approach to the management of sensitive information.

securitycompliance.jpeg

In a constantly evolving digital world, keeping the software supply chain and sensitive information secure is a priority for organizations of all sizes. To reduce the complexity associated with managing multiple infrastructure tools, GitLab plans to release a native secrets manager later this year that will enable users to manage and scale secrets across the DevSecOps platform. This cloud-agnostic, built-in solution has a similar look and feel to the CI Variables experience in GitLab, which will make it easier to learn and, therefore, lower friction to adopt.

What are secrets and a secrets manager?

  • A secret is a piece of data that acts as a credential to authenticate with systems or services. Secrets are highly sensitive and should be protected from unauthorized use or exposure. Examples of secrets include passwords, API keys, and certificates.

  • A secrets manager is a centralized tool that stores and manages these secrets throughout their lifecycle. Secrets are stored using unique encryption keys in order to achieve isolation, in this case, across GitLab.

Current state of secrets management within GitLab

Because GitLab does not currently have a native secrets manager, we have recommended using a third-party solution. Users leverage third-party secrets storage providers through our OIDC connection method (Free tier) or via native integrations (currently available for HashiCorp Vault, Azure Key Vault, and Google Secret Manager (Premium and Ultimate tier). However, we understand a third-party provider can be resource-prohibitive for some users because of the overhead for setup and managing user roles and integrations, as well as additional costs.

About the GitLab secrets manager

The GitLab secrets manager will allow customers to store sensitive credentials within the GitLab DevSecOps platform, which will simplify management and reduce risk of leaking sensitive information. Our initial release of the native secrets manager will be focused on bringing secrets management to the CI workflow, then workflows across all of GitLab. We have prioritized options to use an open source secrets manager with the GitLab UI. This enables us to stay true to our open core roots while minimizing our security attack surface as an extra layer of protection.

GitLab plans to have the native secrets manager available in Beta release by year-end.

Aligning secrets management with GitLab Security

As we continue to iterate, the GitLab secrets manager will integrate with existing security capabilities. Our goal is to automate when possible, while still empowering the user to own security decisions by providing prompts or calls-to-action. Here are some areas we have identified for alignment:

  • Secret detection. Detected secrets can automatically be placed in the native secrets manager. Instances of the secrets in the pipeline will be replaced automatically with the new secret key.

  • Access tokens. When access tokens are generated, they will automatically be placed in the secrets manager. This eliminates the need for the user to manually create a secret for each access token. This also eliminates the need to expose the value of the token at creation. A similar use case can be applied to deploy keys.

  • Compliance. Advancing audit logging within GitLab makes it easier for admins and security teams to identify access, changes, and deletion for each secret, all within the existing GitLab audit events.

  • Secured artifacts. Enabling a verifiable way to link job artifacts back to their source code is critical to ensuring integrity of the software supply chain. Attestations require signing and authentication to verify authenticity in the process and the secrets manager will secure these credentials within GitLab.

Share your feedback

At GitLab, we understand a single tool does not fit all. While we are building a native solution, we are also committed to continuing to support our existing third-party integrations for Hashicorp’s Vault, Azure Key Vault, and Google Secret Manager. We envision an ecosystem where multiple secret management solutions are available to customers, ensuring the best-fit solution for our customers’ use cases.

Interested in joining the conversation to shape the future of GitLab’s offerings in the secrets management space? Please leave us a comment. You also can view our current direction page for the latest category updates and follow our progress to building our own secrets manager in our MVC epic.

Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert