ContextQMD
Back to Gitlabhq

Secret detection

doc/user/application_security/secret_detection/_index.md

18.11.23.2 KB
Original Source

{{< details >}}

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

Your application might use external resources, including a CI/CD service, a database, or external storage. Access to these resources requires authentication, usually using static methods like private keys and tokens. These methods are called "secrets" because they're not meant to be shared with anyone else.

To minimize the risk of exposing your secrets, always store secrets outside of the repository. However, secrets are sometimes accidentally committed to Git repositories. After a sensitive value is pushed to a remote repository, anyone with access to the repository can use the secret to impersonate the authorized user.

Secret detection monitors your activity to both:

  • Help prevent your secrets from being leaked.
  • Help you respond if a secret is leaked.

You should take a multi-layered security approach and enable all available secret detection methods:

  • Secret push protection scans commits for secrets when you push changes to GitLab. The push is blocked if secrets are detected, unless you skip secret push protection. This method reduces the risk of secrets being leaked.
  • Pipeline secret detection runs as part of a project's CI/CD pipeline. Commits to the repository's default branch are scanned for secrets. If pipeline secret detection is enabled in merge request pipelines, commits to the development branch are scanned for secrets, enabling you to respond before they're committed to the default branch.
  • Client-side secret detection scans descriptions and comments in both issues and merge requests for secrets before they're saved to GitLab. When a secret is detected you can choose to edit the input and remove the secret or, if it's a false positive, save the description or comment.

If a secret is committed to a repository, GitLab records the exposure in the vulnerability report. For some secret types, GitLab can even automatically revoke the exposed secret. You should always revoke and replace exposed secrets as soon as possible. For secret-specific remediation guidance, review the details provided in the vulnerability report.

Reducing false positives with GitLab Duo

Secret detection scanners can generate false positives that create noise in your vulnerability reports. The GitLab Duo false positive detection feature automatically analyzes secret detection findings to identify likely false positives. This helps your security team focus on genuine secrets and reduces time spent on manual triage.

For Ultimate tier customers with a GitLab Duo add-on, false positive detection runs automatically after each security scan and provides confidence scores with explanations for each assessment.