Open-Source Secret Scanning Tools in 2026: Six Tested on One Seeded Repository

Which open-source secret scanners are still maintained in 2026?

Betterleaks, Gitleaks, TruffleHog, Kingfisher, Titus and secretlint each shipped a release in 2026, out of eleven open-source secret scanners we checked on 29 October 2026. Nosey Parker is archived, and detect-secrets and git-secrets have gone more than two years without a release. The table is what GitHub's API and each project's README said on 29 October 2026: the licence, the latest release, whether the tool can test a secret against its provider, and whether it writes SARIF. Stars measure attention, not upkeep, so they are left out.

Two rows change the usual advice. Gitleaks still works and its repository still gets commits, but since 21 May 2026 its README has called it "feature complete" and said future releases "will be security patches only". Its original author moved to Betterleaks, a new MIT project created in February 2026 by the people who made Gitleaks, whose development is supported by Aikido Security. And Nosey Parker, still named in many lists, was archived by Praetorian, which replaced it with Titus, a Go scanner whose 487 rules are drawn from Nosey Parker and Kingfisher.

Who maintains each tool matters as well. Kingfisher is MongoDB's, detect-secrets is Yelp's, git-secrets comes from AWS Labs and Talisman from Thoughtworks. TruffleHog is the open-source scanner of Truffle Security, licensed AGPL-3.0 since its version 3.0. Skyscanner's Whispers, which some lists still include, is archived, and its last release was 1.5.3 in August 2021.

What did each scanner find in a seeded repository?

In our test of 29 October 2026, six open-source secret scanners ran on one repository seeded with 12 fake credentials: Betterleaks found 12, Titus 11, Gitleaks and Kingfisher 10, TruffleHog and detect-secrets 9. The misses were passwords and a JWT signing secret with no provider prefix, a key present only in git history, and Titus's miss of a Stripe live key. Titus and detect-secrets each flagged a decoy.

On 29 October 2026 we built a small repository that looks like a web shop's API, with TypeScript, Python, a Django settings file, a Docker Compose file and a shell deploy script, over three commits. We planted 12 fake credentials where they tend to end up:

• an AWS access key pair in a TypeScript config;
• a GitHub personal access token in a curl header;
• a Stripe live key in .env;
• a Slack bot token in YAML;
• an OpenAI key and an Anthropic key in SDK calls;
• a Google API key in an HTML script tag;
• a password inside a Postgres connection string;
• a JWT signing secret in Node.js;
• a Django database password;
• an RSA private key;
• a SendGrid key in an .env.production file that a later commit deleted.

Every value was random and shaped like the provider's format, and none was a real key. Two decoys sat in the README: AWS's documented example key, AKIAIOSFODNN7EXAMPLE, and a Stripe placeholder made of x's. Each tool ran with its default rules, in git history mode where it has one, on a Mac with the versions Homebrew shipped that day. Live checks were off, since a fake key cannot be verified:

gitleaks git . --report-format json --report-path gitleaks.json
betterleaks git . --report-format json --report-path betterleaks.json
trufflehog git file://. --no-verification --json > trufflehog.jsonl
kingfisher scan . --no-validate --format json --output kingfisher.json
titus scan --git . --format json --output :memory: > titus.json
detect-secrets scan --all-files > detect-secrets.json

All six found the AWS key, the GitHub token, the Slack token, the Anthropic key and the private key. The secrets that carry no prefix caused the widest gaps: Gitleaks, Kingfisher and TruffleHog missed the Django database password, and Kingfisher and TruffleHog missed the JWT signing secret too. Provider keys were not all safe either, since TruffleHog and detect-secrets missed the Google API key, detect-secrets the OpenAI key and Titus the Stripe live key. A value assigned to JWT_SECRET is a random string with no format to match, so only rules that read the variable name or the string's entropy catch it.

The SendGrid key existed only in a commit that the next commit deleted. Every tool that reads git history found it. detect-secrets did not, and its README says why: it avoids "digging through all git history" and scans the current files, with a baseline of known findings.

The two decoys caught out different tools. Gitleaks and Betterleaks ignore AWS keys ending in EXAMPLE, because their default AWS rule carries that exception, so the documentation key stayed quiet; detect-secrets flagged it. Titus reported the placeholder made of x's as a Stripe key and missed the real Stripe key in .env. Nosey Parker 0.24.0, which we also ran, did exactly the same, which fits rules drawn from Nosey Parker's.

The count of findings runs higher than the count of credentials. Titus raised 16 findings for 11 credentials and detect-secrets 15 for 9, because several rules matched the same value: a GitHub token caught both as a token and as a curl header, an OpenAI key caught a second time as a generic key. Each duplicate is one more line to triage.

Gitleaks vs TruffleHog vs Betterleaks: which should you run?

Start with Betterleaks for a new setup, keep Gitleaks if it already sits in your hooks and you only need it to keep working, and add TruffleHog or Kingfisher when knowing whether a key is live matters more than catching every password. The tools differ in their rules, their upkeep and what they do after a match.

Gitleaks (MIT, v8.30.1) still does its job: in our test it raised no false alarm and missed two passwords. It will not get new rules. Moving off it is light, because Betterleaks reads a .gitleaks.toml file and honours gitleaks:allow comments.

Betterleaks (MIT) found everything in our test. Version 1.9.0 is the stable release and validation is a flag, --validation. Version 2 is in release candidate, and its migration guide says the CSV, JUnit, SARIF and template reporters "have been removed". If your pipeline reads SARIF, stay on 1.x for now.

TruffleHog (AGPL-3.0) claims over 800 secret types and over 700 detectors that test credentials against their own APIs, and it runs those tests by default. For AWS, its README says it calls GetCallerIdentity. --results=verified keeps only confirmed live secrets, and in our test, with verification off, it also raised the fewest findings. It missed the Google API key, the JWT signing secret and the Django password. It is licensed AGPL-3.0, so read the licence with your legal team before you embed or redistribute it.

Kingfisher (Apache-2.0, Rust) validates findings by default and can revoke some of them. Since its version 2.0.0 of 23 August 2026, its rules come from the Betterleaks catalogue: 462 of its 488 rules, plus 26 from Google's Veles. We tested 2.14.0; 2.15.0 came out the day before.

Titus (Apache-2.0, Go) is where Nosey Parker users go. It validates with --validate and writes SARIF.

Should a secret scanner test whether a key is live?

Yes for triage, as long as you control where the check runs. A live check sends the found credential to its provider's API and tells you which findings are an incident and which are dead keys. TruffleHog and Kingfisher do it by default, Betterleaks and Titus only with a flag, and Gitleaks never does.

The check is a real request with the real secret. Run it where your network policy allows calls to those providers, and keep the results out of public CI logs. GitHub's own secret scanning offers the same idea as opt-in "validity checks".

Unverified does not mean safe. A password for a database on your private network cannot be tested from a CI runner outside that network, so a verifying tool reports it as unverified, and a filter on verified results drops it.

Where should secret scanning run: pre-commit, CI or inside the agent?

In three places: a pre-commit hook on every laptop, a scan in CI on every push that a developer cannot skip, and one full-history scan when you adopt the tool. A pre-commit hook alone is not enough, because git commit --no-verify bypasses the pre-commit and commit-msg hooks, as the git documentation states.

On GitHub, push protection blocks a push that contains a detected secret. Secret scanning runs for free on public repositories; on organisation-owned private and internal repositories it needs GitHub Secret Protection on GitHub Team or GitHub Enterprise Cloud, billed per active committer.

Coding agents add a step before the commit. Claude Code, Cursor or Codex can read a .env file when nothing denies it, as we showed for what Claude Code sends to Anthropic and how to keep .env out of reach, and a value an agent has read can end up in a file it writes.

This is the step CybeDefend works on: VibeDefend's guards refuse an agent's read of .env in Claude Code, Cursor and Codex and point it to the environment variable, and its diff scan checks the files the agent changed for secrets, SAST and IaC issues before they are committed. How VibeDefend works shows both.

The pull request remains the last gate, and the security checks for an AI agent's pull request include a secrets pass.

How do you merge secret scanner results with your other scanners?

Have each scanner write SARIF 2.1.0, the format code hosts and vulnerability tools read, then merge. Five of the six tools we tested write it, and each command below produced a valid SARIF 2.1.0 file on our test repository. Two traps: Betterleaks v2 removes its SARIF reporter, and Kingfisher's own help still calls its SARIF output experimental.

gitleaks git . --report-format sarif --report-path gitleaks.sarif
betterleaks git . --report-format sarif --report-path betterleaks.sarif   # 1.x only
trufflehog git file://. --sarif > trufflehog.sarif
kingfisher scan . --format sarif --output kingfisher.sarif
titus scan --git . --format sarif --output :memory: > titus.sarif

Pre-commit and CI scansOne SARIF file eachMerge and deduplicateTriage and keep history

A merged file is not a triaged list. The same key comes back from two tools under two rule names, a false positive you dismissed reappears on the next run, and nothing keeps the record an auditor asks for. The sorting problem is the same one we describe in why most SAST findings are noise.

CybeDefend Open Source is built for that step. It runs the scanners you choose, any tool that writes SARIF, and puts what they find in one deduplicated queue, free and on your servers. It is launching soon, and the waitlist is open.

Which free secret scanners are not fully open source or local?

GitHub secret scanning and GitGuardian's ggshield are free to start, but neither runs entirely on your machine under an open-source licence. GitHub scans public repositories for free and needs a paid Secret Protection plan for private ones. ggshield's CLI is MIT, but scanning goes through GitGuardian's API and needs an account.

GitHub's scanning is a hosted feature: it reads the whole history of a repository on GitHub, on every branch, and its push protection works on the server. That makes it a good backstop and a poor fit for code that lives elsewhere. What it catches and misses in a Copilot workflow is covered in our guide to GitHub Copilot's security risks.

ggshield's README says that to use it "you need to authenticate against GitGuardian servers", with an account or an API key; it also says your files and secrets will not be stored. That is a reasonable trade for many teams, and a different one from running Betterleaks on your own runner.

What should you do when a scanner finds a real secret?

Revoke or rotate it first, then decide whether the history needs rewriting. GitHub's guide to removing sensitive data says the first step for a password, token or credential is to revoke and/or rotate it, and that a revoked secret can no longer be used for access, which may be enough on its own.

1. Revoke or rotate the credential at the provider. Kingfisher, and Betterleaks from version 2, can revoke some credential types themselves.
2. Check how it was used while it was exposed, in the provider's access logs.
3. Move it out of the code, into a secrets manager or an environment variable that the code reads.
4. Rewrite the history only if you must; GitHub's guide covers the steps.
5. Record the false positives so they stop coming back: a gitleaks:allow or betterleaks:allow comment, an entry in the tool's ignore file, or a detect-secrets baseline.

Frequently asked questions

What is the best open-source secret scanner in 2026?

In our test of 29 October 2026, Betterleaks 1.9.0 found all 12 credentials planted in one small repository and raised no alarm on the decoys. TruffleHog is the stronger choice when you need to know whether a key is live, since it verifies by default. Gitleaks still works, and its README limits future releases to security patches.

Is Gitleaks still maintained?

Gitleaks is still maintained, but for security patches only. Since 21 May 2026 its README says Gitleaks is feature complete and that no new features will be merged; its latest release is v8.30.1 from 21 March 2026. Its original author now works on Betterleaks, which reads Gitleaks configuration files and allow comments.

What is Betterleaks?

Betterleaks is an MIT-licensed secret scanner created in February 2026 by the people who made Gitleaks, including its original author, with development supported by Aikido Security. Version 1.9.0 is the stable release. Version 2 is in release candidate, leaves live validation off by default and removes the SARIF reporter.

Is TruffleHog free and open source?

Yes. TruffleHog on GitHub is open source under AGPL-3.0 since version 3.0 and free to run. It claims over 800 secret types, verifies credentials against their providers by default, and has written SARIF since version 3.97.0, released in August 2026.

Does detect-secrets scan git history?

No, by design. detect-secrets scans the files in your working tree, git-tracked files by default, and keeps a baseline of known findings so that only new secrets block a commit. In our test it missed a key that existed only in a deleted file's history. Its last release, 1.5.0, dates from May 2024.

How do you detect hardcoded API keys in source code?

Run a pattern-based scanner such as Betterleaks or Gitleaks over the code and its full git history once, then on every commit and push. Provider keys like AWS, GitHub or Stripe are matched by prefix and format. Generic secrets such as passwords need rules on variable names and entropy, which is where the tools differ most.

Is GitHub secret scanning free?

On public repositories, yes: secret scanning runs automatically for free. On organisation-owned private and internal repositories it requires GitHub Secret Protection on GitHub Team or GitHub Enterprise Cloud, billed per active committer.