Gitleaks: Fast Secret Scanning for Git Repos and CI

What Gitleaks is

Gitleaks is an open-source secret scanner written in Go and released under the MIT license. Its job is narrow and useful: find hardcoded credentials — API keys, tokens, private keys, connection strings — in git repositories, directories, and piped input, and fail loudly when it does. It has become a default choice for the pre-commit and CI stage of a pipeline precisely because it does one thing quickly and without external dependencies.

Leaked secrets remain one of the most dependable ways into a system, which is why keeping them out of version control belongs next to the rest of your hardening work — the same discipline as the container image security checklist and the wider practice of software supply chain security. A credential that never reaches the repository is one you never have to rotate under pressure.

How Gitleaks detects secrets

Gitleaks works on two signals. The primary one is a set of regular-expression rules, each describing the shape of a particular credential type, defined in TOML. It ships with a large default ruleset that covers common providers, and you extend or constrain it in a .gitleaks.toml file. The secondary signal is entropy: rules can require that a match also be random-looking enough, measured by Shannon entropy, to weed out low-value matches.

The important architectural fact is that Gitleaks makes no network calls. It never contacts a provider to check whether a key is live — it decides purely from the text in front of it. That is the source of both its strengths (speed, offline operation, no data leaving your environment) and its main cost (it cannot tell a real, active key from a realistic-looking test fixture). Understanding that trade is the key to using it well.

Running Gitleaks

Install the binary and scan the current repository. By default the detect command walks git history, so it finds secrets that were committed once and later deleted:

# install (macOS)
brew install gitleaks

# scan this repo's full git history, write a JSON report
gitleaks detect --source . --report-format json --report-path gitleaks-report.json

To scan a plain directory that is not a git repository — a build context, an extracted archive — disable git mode. To catch secrets before they are ever committed, scan only the staged changes as a pre-commit step:

# scan a directory without git metadata
gitleaks detect --source ./build --no-git

# scan only staged changes (use in a pre-commit hook)
gitleaks protect --staged --redact

# newer releases expose these as dedicated subcommands
gitleaks git .
gitleaks dir ./build

Gitleaks exits non-zero when it finds a leak, so it fails a CI job with no extra wiring. The --redact flag keeps the secret value out of logs, which matters when your CI output is itself readable by a broad audience. There is also an official GitHub Action for scanning on pull requests.

Taming false positives

Because Gitleaks matches patterns rather than verifying credentials, a fresh run on a mature repository usually surfaces some noise: example keys in documentation, fixtures in tests, or a rule that is simply too broad. The tool gives you three levers to handle this without ignoring the scanner entirely.

• Allowlists in .gitleaks.toml exclude paths, specific regexes, or known-safe values from matching in the first place.
• A .gitleaksignore file pins the fingerprint of individual findings you have reviewed and accepted, so they stay silent while everything else is still checked.
• A baselinefile records the current findings once, after which only genuinely new leaks fail the build — a pragmatic way to adopt Gitleaks on a large existing repo without a big-bang cleanup.

The discipline that keeps this honest is treating an allowlist entry as a decision, not a reflex: a value is safe to ignore because you confirmed it is a placeholder, not because the finding was inconvenient.

Gitleaks vs verification-based scanners

The obvious comparison is with TruffleHog, which centers on active verification — calling the provider's API to confirm a credential is live. That extra step cuts triage noise sharply, at the cost of network access and a bit of speed. Gitleaks stays in the other corner: no network, maximum speed, total configurability, and more findings to sift through. Neither approach is strictly better. A common pattern is to run Gitleaks as the fast local and pre-commit gate and reserve a verification sweep for deeper periodic scans.

Whichever you choose, remember what secret scanning does not do: it will not tell you that a dependency has a known CVE or that your base image ships an outdated OpenSSL. That is a different question, answered by a vulnerability scanner, and a complete program runs both kinds of tool.

Where ScanRook fits

ScanRook is a vulnerability scanner rather than a secret scanner, and we would rather draw the line clearly than pretend to replace Gitleaks. Gitleaks is the right tool for keeping credentials out of your source and git history. ScanRook works on the artifact you ship: it reads the OS and language packages actually present in a container image or source tree and cross-references them against OSV, NVD, and Red Hat OVAL to find known vulnerabilities.

The two meet at the image boundary. Secrets frequently get baked into a layer during a build, and ScanRook's work on inventorying cryptographic material — the keys and certificates in an image, which we cover in what is a CBOM — can surface private keys and certs embedded in the final artifact. That is a backstop at the shipped-image layer, not a substitute for scanning source with Gitleaks. The strongest setup runs a dedicated secret scanner across your repository and history, then scans the built image for both vulnerabilities and embedded key material with ScanRook before it goes out. If you are wiring scanning into a pipeline, the docs cover the CLI and CI recipes.

Frequently asked questions