Gitleaks: Open-Source Secret Scanner for Git Repos

What Gitleaks is

Gitleaks is a command-line tool for detecting secrets such as passwords, API keys and tokens in git repositories, plain files and directories, and anything piped to it through standard input. It is written in Go, released under the MIT licence, and has been around since January 2018, which makes it one of the longer-lived open-source secret scanners. The repository describes itself in four words: "Find secrets with Gitleaks".

The problem it targets is familiar to anyone who has reviewed a pull request late at night: a credential gets hard-coded "just for testing", committed, and then lives forever in git history even after the line is deleted. Gitleaks scans both the current state of a tree and the full commit history, so it catches secrets that were removed from the working copy but are still recoverable from old commits. It is aimed at individual developers who want a pre-commit safety net, platform and security teams who want a CI gate, and anyone auditing an existing repository before open-sourcing it.

One important status note up front: the README now opens with a warning that Gitleaks is feature complete. The maintainer states that new features are no longer being merged and that future releases will be security patches only, with development focus moving to a separate project called Betterleaks. That does not make Gitleaks unusable, but it changes how you should think about adopting it (see the section on things to know below).

How it works

At its core Gitleaks is a rule engine. Each rule combines a Go regular expression with optional extras: a capture group that holds the actual secret, a minimum Shannon entropy for that group, a path regex, keywords for cheap pre-filtering, tags for reporting and allowlists for suppressing false positives. The project links to a blog post titled "Regex is (almost) all you need" for readers who want the reasoning behind the detection engine. A large default rule set ships inside the binary; you can replace it entirely or extend it with your own rules.

There are three scanning modes:

• git scans local git repositories. Under the hood it runs git log -p and scans the patches, and you can pass options to that command with --log-opts, for example to restrict a scan to a commit range. Without a path argument it scans the current directory as a repo.
• dir (aliases files and directory) scans directories and individual files on disk, regardless of git.
• stdin scans whatever is streamed into it, which makes it easy to plug into other pipelines.

Each finding reports the matched line, the extracted secret, the rule ID, its entropy, the file and line, and, for git scans, the commit, author, email and date. Every finding also carries a fingerprint built from the commit, path, rule and line, which is what you use to ignore specific known findings later. Note that the older detect and protect commands were deprecated in v8.19.0 in favour of git, dir and stdin; they still work but are hidden from --help.

Key features

• Configurable rules in TOML. A configuration file can define rules from scratch or set [extend] useDefault = true to inherit the built-in rules and override or disable individual ones (for example disabledRules = [ "generic-api-key"]).
• Config discovery order. Gitleaks looks for config in a fixed order: the --config flag, the GITLEAKS_CONFIG environment variable (a path), GITLEAKS_CONFIG_TOML (the file content itself), and finally a .gitleaks.toml in the target path.
• Allowlists at two levels. Rule-level and global allowlists can match on commits, paths, regexes or stopwords, combined with OR or AND conditions. Since v8.25.0 an allowlist can target a list of rules via targetRules.
• Composite rules. Added in v8.28.0 and marked experimental, these let a primary rule report only when one or more required auxiliary rules also match, optionally within a given number of lines or columns.
• Inline and file-based ignores. A gitleaks:allow comment on a line skips that secret; a .gitleaksignore file at the repo root lists fingerprints to ignore.
• Baselines. Any previous report can act as a baseline so that later scans only surface new findings, which is useful for large repos with long histories.
• Decoding. With --max-decode-depth, Gitleaks recursively decodes percent, hex and base64-encoded text before matching. It is off by default.
• Archive scanning. With --max-archive-depth, it extracts and scans zip files, tarballs and nested archives, reporting inner paths separated by !. Also off by default.
• Report formats. JSON, CSV, JUnit and SARIF are built in, and a custom Go text/template can produce any other format.
• Redaction and exit codes. --redact masks secrets in logs (fully or by percentage), and the exit code on findings is configurable with --exit-code (default 1).

Getting started

The README lists Homebrew, Docker and building from source, and prebuilt binaries for many platforms are available on the releases page.

# MacOS
brew install gitleaks

# Docker (DockerHub)
docker pull zricethezav/gitleaks:latest
docker run -v ${path_to_host_folder_to_scan}:/path zricethezav/gitleaks:latest [COMMAND] [OPTIONS] [SOURCE_PATH]

# From Source (make sure `go` is installed)
git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build

Scanning a directory and streaming a file through stdin look like this, per the README:

gitleaks dir -v path_to_directory_or_file
cat some_file | gitleaks -v stdin

To create a baseline report and then report only new findings on later runs:

gitleaks git --report-path gitleaks-report.json # This will save the report in a file called gitleaks-report.json
gitleaks git --baseline-path gitleaks-report.json --report-path findings.json

For a pre-commit hook, the README shows a .pre-commit-config.yaml entry pointing at https://github.com/gitleaks/gitleaks with hook id gitleaks, followed by pre-commit autoupdate and pre-commit install. A blocked commit prints "Detect hardcoded secrets...Failed", and prefixing a commit with SKIP=gitleaks bypasses the hook when needed. There is also a separate Gitleaks-Action for GitHub Actions.

Use cases

• Pre-commit protection. Stop a developer from committing a token before it ever reaches a shared remote, which is far cheaper than rotating a leaked key.
• CI gating. Run a scan in the pipeline and fail the build on findings, emitting SARIF or JUnit so results show up in existing code-scanning or test dashboards.
• History audits. Before open-sourcing an internal repo, run a full git scan across all commits to find credentials buried in old history.
• Legacy repos with known noise. Generate a baseline once, then enforce "no new secrets" without first cleaning up every historical finding.
• Artifact and log checks. Use dir with archive scanning on build outputs, or pipe logs and command output through stdin.
• Organisation-specific tokens. Extend the default config with rules for internal token formats, or extend a built-in rule such as gitlab-pat when a self-hosted GitLab uses a custom prefix.

How it compares

The only alternative the README itself points to is Betterleaks, which the Gitleaks maintainer is now focusing on. Beyond that, Gitleaks sits in the same space as other secret scanners such as TruffleHog and detect-secrets, and as the built-in secret scanning offered by some git hosting platforms. Gitleaks' distinguishing traits, based on its own documentation, are a single Go binary with no service to run, a TOML rule format that can extend the defaults, and fingerprint-based ignores and baselines. Whether another tool's verification of live credentials or hosted dashboards matter more depends on your setup; evaluate them against your own repositories rather than relying on feature lists.

Things to know before adopting

• Maintenance mode. The README states that Gitleaks is feature complete and that future releases will be security patches only. Existing behaviour should stay stable, which suits a CI gate, but do not expect new rule types or integrations. Keep an eye on Betterleaks if you need active feature development.
• Regex-based detection. Like any pattern-based scanner it produces false positives and can miss secrets in unusual formats. Plan to tune allowlists, entropy thresholds and disabled rules for your codebase.
• Git scans only see additions. The README notes that Gitleaks looks at additions in git history, which is relevant when designing composite rules.
• Experimental pieces. Composite rules and the .gitleaksignore feature are both described as experimental and subject to change.
• Command changes. If you have old scripts using detect or protect, they still run, but migrate them to git and dir.
• Licence. MIT, so there are no copyleft obligations when embedding it in internal tooling or CI images.

Project activity

As of October 2026 the repository has about 30,155 stars and more than 2,400 forks. It was created in January 2018, is written in Go and is licensed under MIT. Its most recent push was at the end of September 2026, consistent with the security-patch-only status described in the README. Docker images are published on Docker Hub (zricethezav/gitleaks) and GitHub Container Registry.

Source code: github.com/gitleaks/gitleaks. Project site: gitleaks.io.