What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current default rule count and provider coverage: confirm against the shipped config
- Scope of the commercial offering versus the open-source binary: confirm with vendor
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Gitleaks is a single Go binary that reads a repository either as a working directory or as a stream of git patches, matching each added line against a rule set. Each rule is a TOML entry with a regular expression, an optional entropy threshold on a capture group, keywords that cheaply prescreen lines before the expensive expression runs, and allow-list conditions for paths, commits or literals. The shipped configuration covers cloud providers, package registries, payment and messaging APIs, private key formats and generic assignment patterns.
History mode is why most teams reach for it. Rather than inspecting only the current checkout, Gitleaks reconstructs every diff in the commit graph, so a credential committed and later deleted still surfaces, which is the case that matters because the object remains fetchable by anyone with a clone. Findings carry a stable fingerprint of file, rule, commit and line, which goes into a .gitleaksignore file or a baseline so accepted findings stay quiet. Output includes JSON and SARIF.
Where it fits
Two placements are common. A pre-commit hook scanning staged changes, giving the developer immediate feedback. And a CI job on every pull request, plus a scheduled full-history sweep, because the incremental scan by definition does not revisit the past. Security owns the rule file and the baseline, developers see the failures. A full-history scan on a large monorepo is scheduled rather than run per push.
Strengths
- History scanning treats deleted-but-still-reachable secrets as findings, which working-tree scanners miss.
- The TOML rule format is legible enough that an application team can add a pattern for an internal token without reading Go.
- Keyword prescreening keeps large scans practical, and SARIF output drops straight into existing code scanning surfaces instead of requiring a bespoke reporting path.
Limitations
- It reports matches, not live credentials. Nothing calls the provider to check whether a key still works, so triage separates an expired test key from an active production one by hand.
- Entropy rules produce predictable noise on lockfiles, minified assets, generated clients and binary blobs committed as text, and the allow-list grows to match.
- A first run against an old repository returns a volume of findings that stalls adoption unless you baseline immediately, and because fingerprints include line position, unrelated edits can resurface an accepted finding.
Who it suits
Almost any team wanting a dependable, self-hosted scan with no service to run and no code leaving the network. It fits security engineers building their own pipeline controls. Organizations wanting validated findings, cross-repository incident management and public code monitoring will find the binary is only the detection half, and should evaluate a managed platform alongside it.
Used Gitleaks? Recommend it under your own name and title.
Recommend this tool