The GitLab security team is aware of a blog post from Sysdig describing how attackers scan public repositories to identify exposed credentials in Git config files. GitLab consistently recommends its customers and users follow several best practices to harden their public GitLab projects to prevent unintentional leaks of their credentials in Git config files or elsewhere in public projects.
1. Limit public visibility of GitLab Groups and Projects
GitLab recommends setting the default visibility for new GitLab projects and groups to private by default. Configuring the default project and group visibility settings to private for your GitLab instance may help prevent accidental disclosure of information in a public project that was intended to be private.
2. Secure CI secrets
Any secrets that require protection, including passwords and tokens, should never be stored in plaintext. Encryption container technologies (Secrets Managers) should be leveraged to help store secrets securely. Some examples of secret manager tools include GCP Secret Manager, AWS KMS, and HashiCorp Vault.
3. Leverage GitLab Secret Detection
GitLab employs several secret detection capabilities to identify, block, or warn users about potential secrets stored in GitLab repositories. Secret detection monitors your activity to help prevent you from leaking secrets and enables you to respond if a secret is leaked.
Enable secret detection methods
All available GitLab secret detection methods should be enabled:
- 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 helps reduce 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.
What to do if you accidentally leak credentials
In the event of an accidental secret exposure, you should reset the exposed credential and review access logs to identify if there is evidence of credential misuse or abuse. If the leaked secret was a GitLab personal access token or other secret token type, you should revoke the token and review GitLab logs for any unauthorized activity associated with the exposed token.
