The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
A recurring problem when developing applications is that developers may unintentionally commit secrets and credentials to their remote repositories. If other people have access to the source, or if the project is public, this sensitive information is then exposed and can be leveraged by malicious users to gain access to resources like deployment environments. This has very real and tangible costs including: breached application data through credential leaks and compute costs for resources spun up and abused with your cloud resource API keys. GitLab's Security Trends analysis found that 18% of projects hosted on GitLab had identified leaked secrets with Secret Detection. A further dive into this data reveals patterns of commonly leaked credentials.
Secret Detection aims to prevent the unintentional leak of sensitive information including: passwords, authentication tokens, and private keys. It checks source files and configuration files to detect well-known and common patterns that look like secrets or credentials and reports findings that are potentially risky to share.
Secret detection doesn't target a specific language so it can easily be applied to any project. The most common approach to detect secrets is to look for regex patterns of common credentials like AWS tokens, API keys, and more.
Security tools like Secret Detection are best when integrated directly into the Devops Lifecycle and every project can benefit from secret scans, which is why we include it on-by-default in Auto DevOps.
Overall we want to help developers write better code and worry less about common security mistakes. Our goal is to provide Secret Detection as a part of the standard software development lifecycle (SDLC). This means that Secret Detection is executed every time a new commit is pushed to a branch.
Secret Detection results can be consumed in the merge request, where only new vulnerabilities, introduced by the new code, are shown.
The importance of these goals is validated by GitLab's 2020 DevSecOps Landscape Survey. With 3,650 respondents from 21 countries, the survey found:
User success metrics
At GitLab, we collect product usage data to help us build a better product. You can see growth of GitLab Secret Detection on our performance indicators dashboard.
The following measures would help us know how successful we are in achieving our goals:
The Secret Detection Category Maturity level is currently at Viable. We plan to mature it to Complete by mid 2022.
With newly added support for automatically revoking secrets, we look next to experiment with suggested solutions to remediate identified secrets.
With Secret Detection existing as its own scan type and being one simple security scanner, the Static Analysis team can use Secret Detection to explore and experiment with more complex changes that we would like to introduce to our other SAST scanners like custom rulesets, suggested solutions and more.
With Secret Detection now available to all GitLab users and with our recent introduction of post-processing secrets, we're working to add support for third party cloud and SaaS providers who support automated secret revocation to help customers rapidly respond to leaked credentials. Vendors can express integration interest by filling out this form. This theme of taking action is a focus looking forward as we experiment with suggested solutions to help clean git history and even integrate with our HashiCorp Vault solution in the future.
Why is this important?
Secret Detection is a simple but very powerful tool to help developers avoid costly mistakes. Secrets are leaked in source code daily. In fact, there are publicly available tools to watch for leaked secrets like Shhgit. We want to enable as many projects as possible to avoid leaking secrets.
Differentiation
Gitlab uniquely has opportunities within the entire DevOps lifecycle. We can integrate across different DevSecOps stages leveraging data, insight, and functionality from other steps to enrich and automate based on Secret Detection findings. We even allow integration with partners and competitors to ensure flexibility. This allows teams to choose specific Secret Detection and Management solutions that fit their unique needs without GitLab being a constraint. This centers GitLab as the system of control and allows people to extend and integrate other solutions into the GitLab DevSecOps workflow.
View the full changelog of SAST features
There are a variety of vendors and open source projects offering Secret Detection soltuions:
GitLab has a unique position to deeply integrate into the development lifecycle, with the ability to leverage CI/CD pipelines to perform the security tests. There is no need to connect the remote source code repository, or to use a different interface.
We want to engage analysts to make them aware of the security features already available in GitLab. They also perform analysis of vendors in the space and have an eye on the future. We will blend analyst insights with what we hear from our customers, prospects, and the larger market as a whole to ensure we’re adapting as the landscape evolves.
While Secret Detection is not a standalone category of tools covered by analysts, it is frequently mentioned in Application Security Testing (AST) analyst coverage as a secondary feature.
Full list of Secret Detection issues
Last Reviewed: 2021-01-22
Last Updated: 2021-01-22
