Secret Detection (ULTIMATE)
Introduced in GitLab Ultimate 11.9.
Overview
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, the sensitive information is then exposed and can be leveraged by malicious users to gain access to resources like deployment environments.
GitLab 11.9 includes a new check called Secret Detection. It scans the content of the repository to find API keys and other information that should not be there.
GitLab displays identified secrets as part of the SAST reports visibly in a few places:
- Security Dashboard
- Pipelines' Security tab
- Report in the merge request widget
Use cases
- Detecting accidental commit of secrets like keys, passwords, and API tokens.
- Performing a single or recurring scan of the full history of your repository for secrets.
Configuration
If you already have SAST enabled for your app, you don’t need to take any action to benefit from this new feature. It is also included in the Auto DevOps default configuration.
Secret Detection is performed by a specific analyzer
during the sast
job. It runs regardless of the programming
language of your app, and you don't need to change your
CI/CD configuration file to enable it. Results are available in the SAST report.
The Secret Detection analyzer includes Gitleaks and TruffleHog checks.
NOTE: Note:
The Secret Detection analyzer will ignore "Password in URL" vulnerabilities if the password begins
with a dollar sign ($
) as this likely indicates the password being used is an environment
variable. For example, https://username:$password@example.com/path/to/repo
won't be
detected, whereas https://username:password@example.com/path/to/repo
would be detected.
Full History Secret Scan
GitLab 12.11 introduced support for scanning the full history of a reposity. This new functionality is particularly useful when you are enabling Secret Detection in a repository for the first time and you want to perform a full secret scan. Running a secret scan on the full history can take a long time, especially for larger repositories with lengthy Git histories. We recommend not setting this variable as part of your normal job defintion.
A new configuration variable (SAST_GITLEAKS_HISTORIC_SCAN
)
can be set to change the behavior of the GitLab Secret Detection scan to run on the entire Git history of a repository.
We have created a short video walkthrough showcasing how you can perform a full history secret scan.