Git Secret Scanning Tools: What They Catch, Where They Fail (2026)
Written by the Rafter Team
A git secret scanning tool scans your code, your commit diffs, and — in the better tools — your full git history for credentials that shouldn't be there: API keys, database passwords, private keys, OAuth tokens, cloud access keys. It flags or blocks those secrets before they reach a shared branch, a public repository, or a merged pull request. The category spans open-source scanners you run yourself (Gitleaks, its successor Betterleaks, TruffleHog, detect-secrets) and a platform-native option that needs no setup at all (GitHub secret scanning).
No single tool in that list is complete on its own, and that's the part vendor pages tend to skip. A pattern-matching scanner tells you a string looks like a Stripe key; it can't tell you whether that key still works. A verification-based scanner confirms a credential is live right now, but it runs slower and needs outbound network access to do it. And most scanners — GitHub's included — only look at the commit or pull request in front of them, not the years of history sitting behind it, which means a secret deleted from the latest commit can still be sitting in .git, one git log -p away from anyone who clones the repo.
Deleting a secret from your latest commit does not remove it from git history. The blob still exists in .git/objects, in every fork, and often in the host's own cache, unless a tool has explicitly scanned that history and you've rotated the credential. Treat any committed secret as compromised the moment it's committed, not the moment someone finds it.
The Quick Verdict
For most teams, the answer is layered rather than singular. Run Gitleaks or its successor Betterleaks as a pre-commit hook and a CI blocking gate for fast, offline, broad-pattern coverage. Add scheduled TruffleHog sweeps when you need to know whether a detected credential is still active. If your code lives on GitHub, turn on GitHub secret scanning and push protection today — it's free on public repos and takes minutes to enable — and treat it as a floor, not a ceiling.
| Tool | Detection method | Scans git history | Verifies credentials | Best fit |
|---|---|---|---|---|
| Gitleaks / Betterleaks | Regex + entropy (rule-first) | Yes, with explicit flags | No | Pre-commit hook + CI blocking gate |
| TruffleHog | Regex + entropy + live API verification | Yes, deep history sweeps | Yes | Scheduled CI, incident response |
| GitHub Secret Scanning | Regex against 200+ partner formats | No | Partner-side auto-revocation only | Zero-config baseline on GitHub |
| detect-secrets | Regex + entropy (plugin-based) | No, new commits only | No | Brownfield repos needing a baseline |
For the full head-to-head math behind that table, see Secret Scanning Tools: Gitleaks vs TruffleHog Compared and Gitleaks vs TruffleHog (2026).
What Is Git Secret Scanning, Exactly?
Git secret scanning is static analysis applied to version-controlled content instead of application logic. Instead of asking "does this code have a SQL injection," it asks "does this file, diff, or commit contain a string shaped like a credential."
The detection targets are specific: AWS access keys, GitHub personal access tokens, Stripe secret keys, OpenAI and Anthropic API keys, private SSH and TLS keys, database connection strings with embedded passwords, and Slack or Twilio tokens. Most scanners ship a rules file covering 100 to 700+ of these formats out of the box.
This is distinct from secrets management — tools like Vault or a cloud KMS that store and rotate credentials at runtime. Secret scanning catches what management tooling was supposed to prevent: a real credential typed into source instead of pulled from a vault.
Where Should Secret Scanning Run? Pre-Commit vs. CI vs. Server-Side
Secret scanning works at three different points in the git workflow, and each one catches a different failure mode.
| Layer | When it runs | Strength | Weakness |
|---|---|---|---|
| Pre-commit hook | On the developer's machine, before the commit is created | Instant feedback, fully offline, cheapest to run | Bypassable with git commit --no-verify; only protects machines with the hook installed |
| CI/CD pipeline | On push or pull request, before merge | Catches skipped or missing hooks; enforced org-wide, not per-developer | The secret already exists in the branch by the time CI sees it |
| Server-side push protection | At the git host, before the push is accepted | Can't be skipped from the client at all | Only as strong as the host's rule set, and some hosts allow a documented bypass |
None of these layers substitutes for the others. A pre-commit hook stops most leaks at zero network cost, but CI catches the developer who cloned the repo without it or bypassed it under deadline pressure. Server-side push protection — GitHub's model — is the only layer that can't be disabled from a misconfigured laptop, though it can usually still be bypassed with a logged justification.
The practical pattern: install the hook locally, enforce a scanner as a required CI check, and turn on push protection wherever your host offers it. Redundancy is the point — each layer catches what the one before it missed.
The Main Tools: Gitleaks, TruffleHog, GitHub Secret Scanning, and Betterleaks
Gitleaks and Betterleaks are rule-first scanners: a single Go binary matching diffs and history against a TOML file of regex patterns, with entropy as a secondary signal for high-randomness strings that don't match a named rule. They're fast, fully offline, and emit SARIF that plugs into a GitHub Action or GitLab pipeline with almost no configuration. Betterleaks is the actively developed successor built by Gitleaks' original author — it reads existing gitleaks.toml configs unchanged and keeps the same CLI, so migrating is usually a one-line CI change. See Why Betterleaks Replaces Gitleaks for what specifically changed under the hood.
TruffleHog takes the opposite bet: verification over pattern breadth. It finds candidates through regex and entropy like the others, then makes a live API call to the relevant provider to confirm the credential still works. A verified TruffleHog finding means a Stripe key, GitHub token, or AWS credential responded successfully to a real request seconds ago — the highest-confidence signal in this category, at the cost of network dependency and slower full-history scans.
GitHub secret scanning is the zero-setup option. It's enabled by default on every public repository, covers 200+ token formats through partnerships with over 100 providers, can trigger automatic revocation when a partner confirms a leak, and — via push protection — blocks a push containing a known secret pattern before it's ever accepted. The gap: it doesn't scan git history, has no verification of its own, and on private repositories the useful parts require a GitHub Advanced Security license. See GitHub Secret Scanning: What It Catches and What It Misses for the full breakdown.
detect-secrets, from Yelp, fills a narrower niche: a plugin-based Python scanner built around a baseline file, useful when you're rolling scanning out onto a large existing codebase and need to suppress the flood of pre-existing findings without ignoring new ones.
Entropy Detection vs. Verified-Secret Detection: What's the Real Difference?
Entropy, in this context, is a measure of how random a string looks. Shannon entropy scoring flags high-randomness strings — long, mixed-case, no dictionary words — because real secrets tend to look random while ordinary code doesn't, catching formats a scanner hasn't seen before.
The cost is false positives. Base64 blobs, content hashes, UUIDs, and test fixtures are also high-entropy, so an entropy-tuned scanner routinely flags strings that aren't credentials, and each one needs a human to rule it out.
Verified-secret detection skips the guessing. Instead of scoring randomness, the scanner makes a live call to the provider the candidate looks like it belongs to — Stripe, AWS, GitHub, OpenAI — and checks whether the response confirms an active credential. A verified finding means the secret works right now. An unverified finding means the scanner couldn't confirm it either way, which could be an expired key, a test fixture, or a provider without a verifier.
Neither approach is strictly better. Entropy and regex are fast, offline, and complete for known formats; verification is slower and only as broad as the providers the tool has a verifier for. Most mature setups run both — a rule-based scanner as the always-on gate, plus periodic verification sweeps to see which findings demand emergency rotation.
The Git History Problem: Why a Deleted Secret Still Works
A commit in git is close to immutable by design. Deleting a file in a new commit doesn't erase the blob that stored it — the object stays in .git/objects, reachable through any older commit's tree, for as long as the repository's history is kept.
This is the gap most teams miss. GitHub secret scanning doesn't look at history at all, only at pushes as they happen. Gitleaks and Betterleaks, by default, scan a diff or a shallow checkout — a full sweep needs an explicit history flag and a full clone in CI. TruffleHog treats history scanning as close to default, which is why it's the tool teams reach for during incident response: "did this repository ever contain a valid credential, and is it still active?"
A secret that shipped in a commit two years ago, was deleted the next day, and was never scanned or rotated is still exploitable today. It's sitting in every fork, every clone made before the deletion, and potentially in the host's own object cache. Rewriting history with a tool like git filter-repo can remove it going forward, but it does nothing about copies that already exist elsewhere — which is why rotation, not history-rewriting, is the actual fix. If you're dealing with a live leak right now, the emergency response guide walks through triage and rotation in the order that limits damage fastest.
Where This Fits Into a Broader Security Review
Secret scanning catches one class of exposure — credentials that shouldn't be in source control. It says nothing about the SQL injection three files over or the vulnerable dependency two levels down in your lockfile, and running it as a standalone tool means another config, another action, another place to check for findings.
Rafter runs secret scanning alongside static analysis (SAST) and software composition analysis (SCA) as one review, triggered as a GitHub Action on the pull request, before code merges. A leaked key shows up next to the injection bug and the outdated package in the same review, one gate instead of three. Top Tools for Detecting API Key Leaks covers the commercial and platform-native options beyond what's compared here; if you want the layered check built into your pull request flow, you can start a scan at rafter.so.
Frequently Asked Questions
What is the best git secret scanning tool?
There isn't a single best tool — the best setup layers two. Gitleaks or Betterleaks as a pre-commit hook and CI gate catches known formats instantly and offline, and a scheduled TruffleHog sweep adds verification for whichever findings are actually live. Solo developers on GitHub should also enable GitHub secret scanning and push protection, since both are free and need no installation.
Does GitHub scan for secrets automatically?
Yes, on public repositories secret scanning and partner notifications are on by default, no configuration required. Private repositories need a GitHub Advanced Security license for the equivalent coverage. Either way, GitHub only does push-time detection of known partner formats — it doesn't scan existing history or verify non-partner credentials.
Can secret scanning check git history?
It depends on the tool. GitHub secret scanning does not scan history at all, only new pushes. Gitleaks and Betterleaks need an explicit history flag and a full, non-shallow clone in CI; TruffleHog treats history scanning as close to the default.
Should secret scanning run in pre-commit or in CI?
Both, and for different reasons. Pre-commit catches a leak before it's ever committed, at zero cost and with no network dependency, but a developer can bypass it or simply not have it installed. CI is the backstop that catches exactly those bypasses as a required, org-wide check that no individual machine can skip.
What's the difference between entropy-based and verified secret detection?
Entropy-based detection flags statistically random strings, a good proxy for "this might be a secret" that also produces false positives on hashes, UUIDs, and encoded blobs. Verified detection instead makes a live API call to the provider a candidate appears to belong to and confirms whether it's active — higher confidence, but slower and dependent on network access and provider coverage.
Is Gitleaks still maintained, or should I switch to Betterleaks?
Betterleaks is the actively developed successor to Gitleaks, built by the same original author, and reads existing gitleaks.toml files and CLI flags unchanged. Most teams can migrate with a one-line CI update, though staying on Gitleaks is reasonable if you have existing integrations, audit requirements, or a need for pinned behavior.