Avoid leaking secrets in your GitLab repository

Shit happens! Chances are great that you or one of the developers in your team will one day commit a file containing secrets or private keys to a public GIT repository...

Most important thing: detect this quickly so you can take action immediately. Here comes gitleaks, a small tool that analyzes GIT repositories for leaked secrets.

Updated November 2021: with version 8, the syntax has been modified. You'll find the original version of the blog post at the bottom of this page...

Updated April 2022: with recent versions of git, you might get an error fatal: unsafe repository ('/builds/...' is owned by someone else). The gitlab-ci job below has been updated to avoid this error.

Usage

Once installed, you can use gitleaks from the command line to analyze a local or remote repository:

gitleaks detect -v /path/to/my/repo

GitLab

Here is how to automate this in your GitLab tests (in .gitlab-ci.yml):

stages:
  - leaks
  - test

# https://cylab.be/blog/20/avoid-leaking-secrets-in-your-gitlab-repository
leaks:gitleaks:
  stage: leaks
  image: 
    name: "zricethezav/gitleaks"
    entrypoint: [""]
  script:
    # to avoid
    # fatal: unsafe repository ('/builds/...' is owned by someone else)
    # with recent git versions
    - git config --global --add safe.directory $CI_PROJECT_DIR
    - gitleaks detect -v -c gitleaks.toml ./

Fixing issues

If one of the commits produces a warning you should of course fix the problem and revoke the leaked secret. Then, to remove gitleaks warnings, you can either:

• rewrite git history to hide the faulty commit
• or add the faulty commit to gitleaks.toml whitelist:

# the leaks in these commits have been fixed...
[whitelist]
commits = [
    "213c603d16c07d8b7252b62b694104e7e01c1f59",
    "444f28d5437ad3127702bf1b0779ae6cd00ab146",
]

Previous versions

With previous version of gitleaks, you can analyze a local or remote repository with:

gitleaks -v -p /path/to/my/repo
gitleaks -v -p https://github.com/gitleakstest/gronit

And here is how to automate this in your GitLab tests (in .gitlab-ci.yml):

stages:
  - leaks
  - test

# https://cylab.be/blog/20/avoid-leaking-secrets-in-your-gitlab-repository
leaks:gitleaks:
  stage: leaks
  image: 
    name: "zricethezav/gitleaks"
    entrypoint: [""]
  script:
    - gitleaks -v -c gitleaks.toml -p ./

If one of the commits produces a warning you should of course fix the problem. Then, to remove gitleaks warnings, you can either:

• rewrite git history to hide the faulty commit
• or add the faulty commit to gitleaks.toml whitelist:

# the leaks in these commits have been fixed...
[whitelist]
commits = [
    "213c603d16c07d8b7252b62b694104e7e01c1f59",
    "444f28d5437ad3127702bf1b0779ae6cd00ab146",
]

This blog post is licensed under CC BY-SA 4.0