Gitleaks

What it is

Gitleaks is a lightweight, open source secrets scanner written in Go. It scans a git repository's entire history, or a single directory, file or piece of text, looking for patterns that match known secret formats, such as cloud provider keys, private keys and common API tokens, plus a general entropy check for anything that looks like a random secret even without a known pattern.

Why it matters

A secret committed to git history does not disappear when the file is later removed. The value remains recoverable from earlier commits unless the whole history is rewritten, which is disruptive and easy to get wrong. Catching a secret before it is committed, or immediately after in CI, avoids that problem entirely, and is far cheaper than rotating a leaked credential after the fact.

How to use it

The two most common patterns are running gitleaks as a pre-commit hook so a commit containing an apparent secret is rejected locally before it ever reaches a remote, and running it in CI on every pull request so nothing slips through if a contributor skips their local hook. It can also scan an entire repository's history in one pass, which is useful when adopting it on an existing project for the first time.

Free versus paid

Gitleaks itself is completely free and open source with no paid tier; it is maintained as a standalone open source project rather than a product with a commercial upsell attached.

Prerequisites

Basic familiarity with git and the command line is enough to start. No security background is required, though understanding why a given match is a true or false positive takes a little practice.

Limitations

Gitleaks finds patterns and high entropy strings, not certainty. It will produce false positives on things that merely look random, such as hashes or generated identifiers, and it can miss secrets that do not match its rules or an entropy threshold. Tuning its configuration file to your codebase reduces noise over time.

Common questions

What do I do if it finds a real secret already committed? Rotate the credential immediately at the provider, then consider whether the git history needs rewriting to remove the old value, treating any exposed secret as compromised regardless of how long it sat there.

Does it slow down commits noticeably? For most repository sizes the pre-commit scan is fast enough not to be a bother; very large repositories may need scope limited to changed files only.

Can it scan private repositories in CI without exposing anything externally? Yes, it runs entirely within your own pipeline and does not send code anywhere by default.