Secret Scanning 2026: The Default Tool Stopped Shipping
Gitleaks has 28,909 stars and its last release was five months ago, because its author put a warning in the README and moved to a fork with 1,757. Meanwhile the layer that actually prevents a leak is the one most teams skip, and only one of the four layers is prevention at all.
The most-installed open-source secret scanner has a warning callout at the top of its own README, written by the person who spent eight years building it.
“Gitleaks is feature complete. I’m not merging new features into Gitleaks. Future releases will be security patches only. I’m shifting my focus to Betterleaks.”
The numbers back it up. On 23 August 2026, Gitleaks has 28,909 stars and its most recent release is v8.30.1 from 21 March 2026, five months back. Commit activity over the last six weeks is zero except for one week with three. Betterleaks has 1,757 stars, shipped v1.8.1 on 18 August, and put out six releases between 27 July and 18 August alone. Both are MIT.
That is a 16-to-1 gap in stars pointing one way and every signal of actual maintenance pointing the other. If you picked your scanner from a comparison table sorted by popularity, you picked the frozen one.
What Betterleaks actually adds
It is a drop-in replacement in the sense that matters: same shape of CLI, same idea of a config file. The differences are in the detection engine.
Rule filters are written in Expr rather than the old allowlist blocks, so a rule can look at the commit author, the commit message, and the file path before deciding a fragment is a finding. There is a token-rarity filter that runs BPE tokenization to work out whether a string reads like language or like a key, which is a more interesting answer to the entropy problem than a threshold. And rules can now make HTTP requests to check whether a detected secret is live, which is the thing TruffleHog was previously alone in doing. Sources beyond git include GitHub, GitLab, Hugging Face, and S3.
Development is funded by Aikido, which is a real dependency to note rather than a scandal. A single-maintainer MIT project that a vendor now pays several people to work on is usually a better bet than the same project unfunded, right up until the vendor’s priorities and yours stop matching.
If you already run Gitleaks in CI and it is quiet, nothing is on fire. It still detects, and security patches are promised. But “feature complete” plus a five-month release gap plus an author who has publicly moved on is a combination that ages in one direction only.
One Gitleaks footgun worth knowing whichever you run: the official gitleaks-action needs a GITLEAKS_LICENSE secret if the repository belongs to an organization. The key is free, obtained through a form at gitleaks.io, and the action’s license changed from MIT to its own terms at v2.0.0. Personal-account repos need nothing. It is not a cost, it is a surprise, and it surfaces as a pipeline failure rather than as a message about licensing.
Only one of the four layers is prevention
People say “secret scanning” about four different controls, and three of them tell you about a credential that already exists.
History scanning is the one people skip and the one that finds things, because the usual leak shape is commit, notice, delete in a follow-up. The working tree ends up clean and the object store does not. Run it on a schedule, not on the PR path: a diff scan finishes in well under a second, a full-history scan on an old monorepo runs into minutes.
What the paid options cost, and what they count
GitHub Secret Protection is $19 per active committer per month, with Code Security a separate $30. Two things make the sticker number wrong in your favor.
Secret scanning and push protection are free on public repositories, on by default, for everyone. Billing only reaches private repos where you turned the add-on on. And it counts active committers over a 90-day lookback rather than seats, so the designer, the PM, and the contractor who pushed once in April are not on the invoice. The number moves month to month, which is pleasant for the bill and annoying for the budget.
GitGuardian is free for up to 25 developers with unlimited real-time scanning, capped at 500 historical scan detections, 10,000 API calls a month, and 1 GB of repository scanning capacity. That is the best-value entry in this whole comparison for a small team, and the 500-detection cap is the wall you hit first if your history is old.
Above 25 developers GitGuardian publishes nothing. The pricing page currently shows two overlapping sets of plan names, and every tier past the free one says “Contact sales.” Whatever that costs, you will find out on a call.
GitLab is the one to check carefully if you are on it. Secret detection in the pipeline is broadly available, but secret push protection, the only control in the diagram above that prevents anything, is marked Ultimate. On Premium you have reporting and nothing that blocks.
TruffleHog stays AGPL-3.0 and stays alive: 27,554 stars and pushed the morning I checked. Its verification approach is to take each candidate and try to authenticate with it, so a scan producing forty findings produces the handful that are live right now. That has a cost people forget, which is that verification makes outbound API calls from your CI network. An egress-restricted runner will report everything as unverified and you will spend a day working out why.
The first hour, which matters more than the tool
Revoke before you rotate. People reverse this constantly. Issuing a new key does nothing about the old one; it means two credentials work and one of them is not yours. Kill the old one first and take the outage.
Then assume it was used, and pull audit logs for the credential’s whole life rather than since you noticed. On AWS, delete the access key rather than deactivating it, then read CloudTrail for RunInstances in regions you never touch, new IAM users, and changed trust policies. On Stripe, roll the key and reconcile charges and refunds, because that one has direct financial exposure. On npm, revoke, review recent publishes, and require 2FA for publishing, because a leaked npm token is a supply-chain incident for everyone downstream rather than an incident for you, which is the shape covered in the npm install-script lockdown. On Slack, rotate the token and treat every message it could read as gone.
Rewriting history comes last, if at all. git filter-repo changes every SHA after the offending commit, which breaks every fork, open PR, and clone, and it buys you nothing if the repository was ever public or ever cloned by someone outside your control. Unreachable objects get cached. Mirrors exist.
Write down which credential, when it was committed, when it was found, and when it was revoked. The gap between the second and third of those is the only number in this whole area that measures anything about your team. Alert counts do not.
If the blast-radius step was hard because nobody could say what the credential could reach, that is a secrets-management problem rather than a scanning one, and Vault, Doppler, and Infisical exist to make short-lived narrowly-scoped credentials the default so that hour is boring.
What I would run
Under 25 developers: GitGuardian’s free tier, plus Betterleaks as a pre-commit hook. Zero dollars, and you will only hit the 500-detection cap if your repositories are genuinely old.
Twenty-five to a hundred on GitHub: turn Secret Protection on for private repositories and let the public ones stay free. Add a nightly full-history scan with verification, because push protection has nothing to say about what is already buried.
Above that, or regulated: buy the platform, not because the open-source engines cannot detect but because at that size what you are paying for is org-wide policy, an audit trail, and a phone number. Get both quotes and let them compete, since neither publishes a number at that tier for exactly that reason. Same shape as the dependency scanning market, where the detection engines are open and what the vendors sell is everything around them.
Before evaluating any of it, run a verified full-history scan against your main repository. Not the diff, everything, back to the first commit. Whatever comes back verified is the number that decides how urgent this is. If it is zero you have time to shop. If it is not, you are not evaluating tools today.
Star counts, release dates, licenses, and repository activity came from the GitHub API on 23 August 2026; prices and tier placements from the GitHub, GitGuardian, and GitLab documentation the same day.