how to do secrets scanning with gitleaks in CI

TL;DR

Gitleaks scans your repo for things that look like API keys, tokens, and private keys, and it belongs in CI on every pull request plus as a pre-commit hook so secrets never land in history. Run gitleaks detect with verbose output redacted, block merges on findings, and for repos with ancient history use a baseline file so only new leaks fail the build. If a real secret already leaked, rotate it first; no scanner un-leaks anything.

how to do secrets scanning with gitleaks in CI

Use this when

• You want automated secrets detection on every PR
• A credential was committed and you want to stop the next one
• You are setting up pre-commit hooks for a development team
• An audit asks for evidence of secrets scanning

Not for

• Rotating or revoking an exposed secret (do that immediately, separately)
• Designing a secrets manager or vault setup
• Scanning non-git artifacts like container images

Steps

1. Run gitleaks locally first to see the current state. From the repo root, run gitleaks detect --source . --verbose --redact. The redact flag keeps any found secrets out of your terminal history and CI logs.

Expected output: a list of findings (or a clean bill), with secret values masked.

1. Triage what it finds. Real secrets get rotated immediately and purged from history (rotate first, history rewrite second, because rewriting takes longer). Test keys and obvious fakes go into an allowlist with a comment saying why each is safe.

Expected output: every finding is either a rotated real secret or a justified allowlist entry.

1. Add it to CI on pull requests. Use the official gitleaks action or run the binary in your pipeline; make findings fail the PR. Scan the full diff of the PR, and on a schedule scan the whole repo to catch anything that slipped in before the check existed.

Expected output: a PR containing a fake test key is blocked with a clear gitleaks message.

1. For repos with legacy leaks, create a baseline. Run gitleaks with a baseline flag against the current commit so historical findings are recorded but dont fail new builds; only newly introduced secrets break the pipeline. Pair this with a plan to rotate the old ones.

Expected output: the pipeline is green on old history and red on a newly added secret.

1. Install the pre-commit hook for the team. Gitleaks ships a pre-commit hook that runs in seconds and stops the commit before the secret enters history, which is far cheaper than cleaning history later. Document the one-command install in your contributing guide.

Expected output: committing a file with a test secret is rejected locally with the hook's message.

1. Protect the config itself. Keep the gitleaks config and allowlist in the repo, require review on changes to them, and alert if someone weakens a rule. An attacker who can edit the allowlist can silence the scanner.

Expected output: changes to the gitleaks config need the same review as production code.

Variant phrasings

• "gitleaks pre-commit hook setup"
• "scan git history for API keys"
• "gitleaks allowlist false positives"
• "prevent committing secrets to git"

Edge cases and pitfalls

• Gitleaks matches patterns, so high-entropy test fixtures can false-positive; the allowlist with fingerprints handles these precisely.
• Secrets in CI logs and build artifacts are a separate leak path; redact step output and dont echo credentials in scripts.
• Rewriting published history to purge a secret breaks every clone; coordinate it like the breaking change it is, after rotation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstVVkx-8UQDYFeXgUan2U-Q