The best secrets detection setup in 2026 is layered: GitHub push protection as the free always-on gate, Gitleaks in pre-commit and CI for speed and custom patterns, and TruffleHog for deep history scans where its live-credential verification separates real emergencies from noise. No single tool wins all three jobs, and the teams that get burned are usually running exactly one of them in exactly one place.
To compare fairly, I seeded a test repository with 60 secrets in realistic positions: current files, deleted files, old commits on merged branches, a .env committed then removed, secrets split across string concatenation, and 15 high-entropy strings that are not secrets at all (cache keys, test fixtures) to measure false positives. All scans ran in April 2026 on current releases.
Results at a glance
| Tool | Found (of 60) | False positives (of 15 traps) | Full history scan | Verification |
|---|---|---|---|---|
| TruffleHog 3.88 | 54 | 2 | 41s | yes, live API checks |
| Gitleaks 8.24 | 51 | 4 | 9s | no |
| GitHub secret scanning + push protection | 46 | 0 | continuous | partner validity checks |
| detect-secrets 1.5 | 39 | 7 | 22s (diff-based model) | no |
| ripsecrets 0.1.11 | 33 | 1 | 6s | no |
The "found" numbers need context: the misses cluster in provider-specific formats each tool lacks patterns for, plus the concatenation cases, which only TruffleHog partially caught (3 of 5).
TruffleHog: verification changes the triage math
TruffleHog's decisive feature is that it tests candidates against the provider's API and tells you whether the credential is live:
trufflehog git file://. --results=verified,unknown --fail
A scan that returns "AWS key, verified active" is an incident. "AWS key, verification failed" is cleanup. That single bit of metadata is the difference between paging someone and filing a ticket, and after an incident like the CircleCI mass rotation event of 2023, it is the bit responders spend their first hours reconstructing by hand. TruffleHog's 800-plus detectors with verification make it the right tool for the "scan everything we have ever committed" audit.
Costs: verification means outbound API calls from your scanner (think about where that runs and what egress it implies), and at 41 seconds on our small test repo, whole-org history scans are batch jobs, not PR gates.
Gitleaks: the CI and pre-commit workhorse
Gitleaks is 4-5x faster than TruffleHog, single binary, trivially configurable, and the natural PR gate:
gitleaks git --pre-commit --staged # in .git/hooks or via pre-commit framework
gitleaks git --log-opts="origin/main.." . # CI: scan only new commits
The --log-opts trick matters: scanning only commits new to the PR keeps the gate under two seconds and avoids re-flagging historical findings you have already triaged. Custom rules are one TOML stanza each — we run five for internal token formats that no vendor list will ever include:
[[rules]]
id = "internal-service-token"
regex = '''svc_[a-z]{4}_[A-Za-z0-9]{32}'''
Four false positives on entropy traps is livable with a .gitleaksignore file, which records findings by fingerprint so suppressions survive rebases. Since the 8.19 licensing change, check that your use fits the terms if you are a large org — most CI use remains fine, but legal will ask.
GitHub push protection: the layer you enable and forget
Native secret scanning with push protection blocks the push before the secret lands in history, which beats every scan-after-the-fact tool at the only metric that fully matters: secrets that never leaked. It is free for public repositories and included with GitHub Advanced Security (now purchasable as standalone Secret Protection) for private ones. Zero false positives in our test because it only fires on high-confidence provider patterns — which is also why it caught 46 of 60, missing generic and internal formats entirely.
Enable it org-wide, then treat bypasses as signal: the bypass flow requires a reason, and those reasons land in the audit log. Review them weekly; a developer who bypasses "test credential" three times a week is telling you your test fixtures need fake-format tokens.
detect-secrets and ripsecrets: narrower jobs
Yelp's detect-secrets is built around a baseline file — detect-secrets scan > .secrets.baseline — that freezes known findings so only new introductions fail. That audit-then-gate model suits large legacy codebases with hundreds of historical findings you cannot fix this quarter, but the plugin-based detection lags the dedicated tools (39 of 60) and entropy tuning produced our worst false-positive rate.
ripsecrets does exactly one thing — pre-push scanning, in Rust, in single-digit milliseconds per file — and its low pattern count is the tradeoff. Fine as a fast local guard, not sufficient alone.
What we actually deploy
The layered setup, concretely: push protection on org-wide; Gitleaks in the pre-commit framework and as a diff-scoped PR check; TruffleHog with --results=verified weekly across all repos plus every acquisition-diligence and incident-response scan. Rotation runbooks matter more than any scanner — a found secret with no practiced rotation path is just documented risk. And since scanners cover repos but secrets also leak through build logs, container layers, and package tarballs, artifact-level scanning belongs in the pipeline too; that is where we fold results into the same findings queue Safeguard already routes for dependency issues, so one on-call rotation sees both.
Budget note: everything in the recommended stack is free except push protection on private repos; if you are weighing paid options, price per-developer against your incident history, not against the sticker — see how we think about that math on our pricing page.
Frequently asked questions
Which secrets detection tool has the fewest false positives?
GitHub push protection, by design — it only alerts on verified provider patterns, trading recall for precision. Among standalone scanners, TruffleHog in verified-only mode is effectively zero-noise, because a credential that authenticates is not a false positive.
Should secret scanning block the build?
Block on new secrets in the diff; never block on historical findings, or the team will disable the check within a month. The diff-scoped Gitleaks pattern plus a baseline for legacy findings gives you a strict gate that developers do not route around.
A secret leaked. Is deleting the commit enough?
No. Assume compromise from the moment of push: rotate the credential first, then clean history with git filter-repo if the repo is private, and accept that forks, clones, and CI caches may retain it forever. GitHub also caches commits reachable by hash even after force-push, so rotation is the only real remediation.
Do these tools catch secrets in container images and build artifacts?
Mostly no — repo scanners stop at git. TruffleHog can scan images and S3 buckets, and Trivy includes secret detection over filesystems and layers, so add one of those to release pipelines; a .env baked into a published image layer bypasses every pre-commit hook you have.