Gitleaks checks Git history, files, and stdin for secrets
Gitleaks has a narrow job: find strings that look like credentials before or after they enter source control. Its git mode scans patches from git log -p, dir inspects files and directories, and stdin accepts streamed content. Findings include the rule, file, line, commit details, and a fingerprint. That makes the output useful to a developer fixing one commit and to a CI system producing JSON, CSV, JUnit, SARIF, or a custom report.
What happened when we ran it
Our sandbox installed 187 Go packages in 25 seconds at commit b58d3f1. The source build completed in 28 seconds. Tests finished in another 10 seconds, with 7 parsed Go test groups passing and 0 failing. We used Go 1.24 on Debian, 3 CPUs, and 8 GB of RAM in an unprivileged container without secrets. The repository also has 3 CI workflow files and a Dockerfile.
That clean run is a useful sign for contributors and teams that prefer source builds. The checkout contained 453 files, roughly 21,902 lines of source, and only 1.2 MB on disk before dependencies. There was no separate tests directory, but Go tests can live beside package code, and our test command found and passed 7 groups. None of these figures measure detection accuracy. They show that the project installed, compiled, and ran its own available test target in our clean environment.
Three scan modes cover different failure windows
Use git when history matters, such as checking every patch in a repository or a selected commit range. Use dir to examine the current filesystem, including material that Git does not know about. Use stdin when another process already produces the text. Those modes are related, but they are not interchangeable. A pre-receive range scan sees added patch lines; issue #2218 notes that an unchanged old secret in a modified file can fall outside that patch.
Rules and suppressions need routine review
Gitleaks is primarily a rule engine. The default configuration supplies known credential patterns, keywords, entropy checks, paths, and allowlists. Teams can replace the defaults or extend them, and configuration can come from a command flag, environment variables, or a repository file. Composite rules added in v8.28.0 can require nearby supporting matches, which helps express credentials whose pieces appear within a limited number of lines or columns.
Rules always lag some credential formats. Recent open reports describe gaps for OpenAI keys, an Anthropic rule behaving differently on macOS ARM64, new Supabase secrets, encoded Basic Auth, and a generic key in single-line JSON. Issue #2239 raises a separate suppression risk: the ignore fingerprint uses file, rule, and line, so replacing an ignored secret with a new one on the same line may remain hidden. Review .gitleaksignore like code, keep entries specific, and retest them when files move or credential formats change.
A clean exit can still mean incomplete coverage
Secret scanners are often used as a binary gate, which makes silent skips more dangerous than visible false positives. Issue #2232 reports that a file which cannot be opened because of permissions may be skipped while the run still prints that no leaks were found and exits 0. Issue #1338 describes a malformed Git diff that can leave a scan waiting indefinitely. Both are reminders to inspect warnings, set a timeout, and verify that the scanner reached every intended path.
Our own 10-second test result does not contradict those field reports. It confirms the checked-in test target passed in one clean Linux container. Production repositories add submodules, large histories, generated archives, permission boundaries, and custom rules. Run Gitleaks against seeded canary credentials in the same CI image and command used for real code. A canary that fails to trigger is more informative than another green scan against an empty fixture.
Feature work has moved to Betterleaks
The README now says Gitleaks is feature complete and that future releases will contain security patches only. The maintainer is focusing on Betterleaks. That statement is clearer than an ambiguous stale repository, and it changes the buying decision: existing users can keep a stable scanner, while teams seeking new detection features should compare the successor before standardizing. The latest published Gitleaks release we fetched was v8.30.1 from March 21, 2026.
Maintenance has not stopped. The repository was pushed on August 26, 2026, the same day we checked, and GitHub showed 464 open issues and pull requests combined. The current push and busy tracker argue against calling it abandoned. They do not restore a feature roadmap the maintainer explicitly closed. Pin v8.30.1 or a reviewed commit, watch for security patches, and understand that missing provider rules may need local configuration or a move to another scanner.
Gitleaks belongs in a layered secret policy
The best use is early and repeated: a local hook for quick feedback, CI on every change, and periodic history or directory scans. A baseline can make adoption possible in a repository with old findings, but every suppression should have an owner and a reason. When Gitleaks reports a real credential, remove it from code, rotate or revoke it at the provider, and decide whether history must be rewritten. Deleting the string from the latest commit does not invalidate a token already copied elsewhere.
Our run makes the tool easy to recommend as a first layer: 25 seconds to install, 28 seconds to build, and 7 of 7 test groups passed. The limit is equally clear. Regex and entropy rules cannot recognize every secret, and an ignored or unreadable path can weaken a clean result. Pair Gitleaks with provider-side secret controls, restricted credentials, and repository-host push protection where available. The scanner is useful evidence that a defined set of rules found nothing, not a certificate that the repository contains no credentials.