Gitleaks — an open-source secret scanner that finds hard-coded credentials in git repositories, in plain directories and in anything you pipe into it — is one of the most widely used tools for stopping API keys, tokens, passwords and private keys from ever reaching a remote. Written in Go under the MIT licence, it began in 2018 as a pre-commit hook and grew into a full static-analysis (SAST) scanner with 222 built-in rules covering the services that leak most often: AWS, GitHub, GitLab, Stripe, Slack, database connection strings, private-key blocks and many more. It is now maintained by Truffle Security, and the current release is v8.30.1 (March 2026). Because it scans the commit history rather than just the working tree, a credential that was committed in 2019 and quietly deleted in 2020 is still reported today — which is exactly the case a file-system scanner misses.

Key Features

• Three scan modes — git walks a repository’s patch stream (--log-opts restricts it to a commit range), dir scans directories and individual files, and stdin scans piped data such as a database dump or a decompressed configuration archive.
• 222 built-in rules — the shipped default configuration recognises credentials from more than two hundred providers and platforms, from provider-specific token formats (GitHub PATs, AWS access keys, Stripe keys, Slack webhooks, SendGrid, GitLab) to generic API-key assignments and PEM private keys.
• Regex plus entropy — every rule pairs a Golang regular expression with an optional Shannon-entropy threshold applied to a captured group (secretGroup), so a string that merely looks like a key can be rejected for being too predictable.
• Custom rules in TOML — rules are plain TOML: id, regex, path pattern, entropy, keywords, tags and allowlists. You can write your own set, or extend the built-in one with [extend] useDefault = true and disable just the rules you do not want.
• Allowlists that survive a noisy repo — global and per-rule allowlists filter findings by commit, path, regex or stopword with AND/OR conditions and a regexTarget that can point at the secret, the match or the whole line. For one-off exceptions there is an inline gitleaks:allow comment, and for long-lived ones a .gitleaksignore file keyed on each finding’s fingerprint.
• Baselines for existing codebases — generate a report once, feed it back with --baseline-path, and only new findings are reported. Adopting a scanner on a ten-year-old repository does not have to mean a thousand alerts on day one.
• Decoding and archive scanning — --max-decode-depth follows base64, hex and percent-encoded text recursively, and --max-archive-depth extracts zip and tarball contents (including archives nested inside archives) so a key hidden inside a build artefact is still found.
• Composite rules — since v8.28.0 a primary rule can require another rule’s match within a given number of lines or columns, expressing conditions like “an AWS key ID in the same fragment as a secret access key” instead of one loose pattern that fires on either.
• Reports a pipeline can read — JSON, CSV, JUnit and SARIF output (the last feeds GitHub code scanning and most CI dashboards), plus a Go text/template escape hatch with sprig helpers for anything bespoke. --redact masks all or a chosen percentage of each secret so a report or log can be shared safely.
• Fits the developer workflow — pre-commit hook support, the official GitHub Action, Docker images on Docker Hub and ghcr.io, and meaningful exit codes (0 clean, 1 leaks or error, configurable with --exit-code) so a leaking commit can fail a build instead of a review.

Why Use Gitleaks?

Leaked secrets are the static-analysis failure that costs the most and is easiest to miss: the code is syntactically valid, the tests pass, and the key is simply in a string. Deleting it in the next commit does nothing, because git history keeps every version of every file — which is why the scanner has to look at commits, not just at the current tree. Gitleaks does that in a single self-contained binary with no runtime dependencies, finishes a full repository history in seconds, and runs entirely on your own machine: nothing is uploaded to a third-party service, so it is usable on private and regulated code. The rules are readable TOML rather than a black box, so you can see exactly why a finding fired, tune it, and version-control the change. The MIT licence removes the procurement conversation, and the project’s own README notes that gitleaks is now feature complete, with future releases limited to security patches as the original author’s attention moves to a successor project (Betterleaks) — it is stable, massively deployed software rather than a fast-moving one. If you do adopt it across a large organisation, note that the GitHub Action asks for a free licence key when scanning repositories owned by a GitHub organisation account; the CLI itself has no such requirement.

Use Cases

• Add a pre-commit hook that blocks a commit containing a credential before it is ever pushed.
• Run it as a CI gate on pull requests and fail the build when a new finding appears (SARIF output uploads straight to GitHub code scanning).
• Audit a repository’s entire history before open-sourcing it or handing it to a contractor.
• Scan code that cannot go to a hosted scanner — air-gapped networks, private client work, regulated environments — from a local binary or a container.
• Triage an incident after a key was exposed: find every commit, file and archive that ever contained it, then rotate with confidence.
• Check configuration and infrastructure-as-code rather than source alone: .env files, Kubernetes manifests, Terraform and Docker Compose are all just directories to gitleaks dir.
• Sweep a fleet of repositories from one shell loop and collect the JSON reports into a single dashboard.

Similar

• TruffleHog — the other major open-source secret scanner (also from Truffle Security historically); it verifies found credentials against the live API, whereas gitleaks favours fast, deterministic local pattern and entropy matching.
• detect-secrets — Yelp’s plugin-based scanner for Python projects, built around a baseline file and its own entropy heuristics; a natural alternative where the workflow is already Python.
• CrowdSec, Lynis and ClamAV — runtime counterparts: those watch the running host, gitleaks watches the repository before it ships.

Platform

Linux (x86-64, arm64, armv6/armv7, 32-bit x86) · macOS (Intel and Apple silicon) · Windows (x86-64, 32-bit, arm64) · Docker (Docker Hub and ghcr.io) · Homebrew · Go toolchain (go install) · packaged in Debian and other distributions (Debian ships 8.16.0)

Licence

MIT — the gitleaks CLI, its source and its default rule set. The separate GitHub Action is also open source but requires a free licence key when scanning organisation-owned repositories.

Website

gitleaks.io · source on GitHub · gitleaks-action · Docker Hub · also see the Security & Privacy category for more tools that keep secrets and systems in check.