Secret Scanning Tools: free & open-source secret scanners, compared
A secret scanner finds credentials — API keys, tokens, passwords and private keys — that have leaked into code, configuration, logs or git history, where anyone with access can read and reuse them. This page explains what secret scanning is and why it matters, gives a factual roundup of the main free and open-source secret scanning tools, shows where each one runs, explains the difference between repo/history scanning, pre-commit hooks and platform push-protection, and covers what to do when a secret is found.
Secret scanning in plain words
- Secret scanning is the practice of detecting credentials — API keys, tokens, passwords, private keys — that have leaked into source code, configuration, logs or git history, where anyone with access to the code can read and reuse them.
- The most-used free and open-source secret scanners are Gitleaks and TruffleHog (repo and history scanning via CLI/CI), detect-secrets and git-secrets (pre-commit prevention), and GitHub’s built-in secret scanning with push protection (platform-side, blocks the push).
- They sit at different points: history scanners find secrets already committed, pre-commit hooks stop a secret before it enters a commit, and platform push-protection blocks it when you push to the remote. Most teams use more than one.
- Detection is by signature (a key’s fixed prefix and length), by context (a plain value next to a tell-tale variable name) and by entropy (how random the value is) — which is why both false positives and missed custom secrets are possible.
- When a secret is found, rotate it in the safe order: generate the replacement, verify it works, switch every consumer over, and only then revoke the old one — and treat any secret that reached git as already compromised.
What secret scanning is, and why it matters
A hard-coded API key, database password or private key is a credential an attacker can use directly — there is no vulnerability to exploit, only a value to copy. Secrets end up in the wrong place constantly: committed to a repository, pasted into a chat or ticket, printed into a log, baked into a client bundle, or left in a .env that gets shared. Once a secret touches a public repository it should be considered compromised — automated bots crawl public code and new commits within seconds of a push. Leaked credentials are a recurring, well-documented cause of breaches precisely because they turn “someone read our code” into “someone has our keys”.
Secret scanning is the automated detection of those credentials before — or at least soon after — they leak. A scanner looks at your code, configuration and git history and flags values that match a known credential shape or look random enough to be a real secret. The goal is to catch the mistake while you can still rotate the key quietly, rather than discovering it in an incident.
How detection works (and its limits)
- Signature matching. Most provider keys carry a fixed prefix and length —
AKIA…,ghp_…,sk_live_…,AIza…. These match with high confidence and rarely false-positive. - Contextual matching. Some secrets have no distinctive shape — an AWS secret key is just 40 base64 characters. Those are flagged only when they appear next to a tell-tale variable name, to avoid reporting every random blob.
- Entropy heuristics. For generic
api_key = "…"assignments, the value's randomness must clear a threshold, so a placeholder likepasswordis skipped while a genuinely random value is flagged. - The limits. A bespoke internal token with no recognisable shape can be missed, an encoded secret can slip through, and generic entropy rules produce false positives. A clean scan is a useful first pass, not a guarantee.
The roundup: free & open-source secret scanners
These are real, maintained, genuinely free or open-source tools, described factually. There are no ratings or benchmarks here — which one fits depends on where you want detection to happen, not on a score. Each links to its own project page.
A Go command-line scanner that detects secrets in files, directories, stdin and — notably — across a repository’s full git history, using regular expressions and an entropy check. It is commonly wired into CI (there is an official GitHub Action) and can also run as a local pre-commit hook, so the same rule set covers both after-the-fact history scanning and prevention.
A scanner with a large library of detectors for specific credential types across many sources — git repositories and history, filesystems, container images and more. Its distinguishing feature is credential verification: for supported providers it can actively check whether a detected key is still live, which helps separate a real, usable leak from a dead or example value.
A Python tool designed around a baseline file: you snapshot the secrets already present (or triaged as false positives), then the pre-commit hook fails the commit only when a new secret appears relative to that baseline. It combines plugin-based detectors with entropy analysis and an audit workflow, which makes it a practical fit for adopting scanning on an existing codebase without drowning in historical noise.
GitHub secret scanning & push protection
Platform feature — free for public repositoriesPlatform (server-side)Built into GitHub: it scans repositories for known credential formats and, through a partner programme, can notify the issuing provider so a leaked token can be revoked. Push protection blocks a push that contains a detected secret before it reaches the remote. Secret scanning and push protection are free for public repositories; for private repositories they are part of GitHub Advanced Security (paid).
A lightweight set of git hooks from AWS Labs that scan a commit (and commit messages, and merges) for patterns that look like secrets and block the commit if one is found. It ships with AWS-oriented patterns and lets you register your own. It does one thing — prevention at commit time — which makes it simple to add, though it is not a history or CI scanner on its own.
Where each tool fits: history, hooks and push-protection
The tools above are not really competitors so much as different layers. Understanding where each acts is more useful than ranking them:
- Repository & history scanning. Runs over the current tree and the full commit history to find secrets already committed, usually in CI or on a schedule. This is the main job of Gitleaks and TruffleHog, and it is the only layer that catches a key that leaked months ago.
- Pre-commit hooks. Run on your machine before a commit is recorded, blocking a secret from ever entering local history. git-secrets and detect-secrets are built for this; Gitleaks can run as a hook too. Prevention is cheaper than cleanup, since a secret that never enters history never needs a history purge.
- Platform push-protection. Runs on the hosting platform when you push to the remote and rejects the push if it contains a recognised secret. GitHub push protection is the common example — a server-side backstop that works even when a developer has no local hook installed.
In practice most teams combine layers: a pre-commit hook to catch the everyday mistake, push-protection as a backstop at the remote, and periodic history scanning to find what slipped through before any of this was set up. No single layer is sufficient on its own.
What to do when a secret is found — verify before you revoke
Finding the leak is the easy half. The most common way a response goes wrong is revoking the old secret before the replacement is confirmed working, which locks you out. Rotate in this order, every time:
- Generate the new credential.
- Verify it works with a real authenticated call.
- Swap every consumer — services, CI, local environments — over to the new value.
- Only then revoke the old credential.
If the secret ever reached git, rotation is necessary but not sufficient: the value stays in the commit history and is readable by anyone with repo access until you purge it — and even then, assume it was already harvested. Treat any key that touched a shared or public repository as compromised, rotate it, and review the provider's audit log for activity you did not perform.
A quick in-browser first pass: PlayCISO's Secret Scanner
The CLI and platform tools above are the right choice for scanning whole repositories, full history and every push. For a quick, private spot-check — a snippet you are about to paste into a ticket, a config you were just handed, a log line, a diff — PlayCISO's free Secret Scanner is a complement, not a replacement. Paste the text and it flags values that match known credential shapes (AWS, GitHub, Stripe, OpenAI, Anthropic, Google, Slack, SendGrid, Twilio keys, PEM private key blocks and JWTs) plus generic high-entropy assignments.
It is honest about its scope: it runs entirely in your browser — the pasted text is parsed with regular expressions locally and is never uploaded, logged or stored, which is exactly why it is safe to paste real config into. Findings are masked (the full secret is never echoed back), graded by severity, and paired with the same verify-before-revoke rotation guidance above. It does not scan git history, repositories or CI — use Gitleaks, TruffleHog or your platform's push-protection for that. It is a fast way to check one piece of text before it goes somewhere it should not.
When the scanner (or any tool above) turns up a real leak, PlayCISO also has two free companions for the response: Leaked Credential Response walks through the containment and rotation steps for a confirmed exposure, and the Key Rotation Planner helps you sequence the verify-before-revoke swap across every consumer so nothing breaks.
Note: this page describes each tool neutrally from its documented behaviour and does not rank them or publish benchmarks. Licensing and platform-pricing details (for example, which GitHub features are free on public versus private repositories) change over time — confirm against each project's own documentation before you rely on it.
Frequently asked questions
What is secret scanning?
Secret scanning is the automated detection of sensitive credentials that have leaked into places they should not be — source code, configuration files, .env files, logs, container images or git history. The credentials in question are things like cloud access keys, API tokens, database passwords, OAuth client secrets and private keys: values an attacker can use directly, with no exploit required. A hard-coded or committed secret is dangerous because anyone who can read the code can read the credential, and automated bots crawl public repositories and new commits within seconds of a push, so a key that touches a public repo should be treated as compromised the moment it lands. Secret scanning tools look for known credential formats and high-entropy values and flag them so they can be rotated before they are abused.
What are the best free and open-source secret scanning tools?
The most widely used free and open-source options are Gitleaks (a Go CLI that scans repositories, directories and full git history using regular expressions and entropy, and runs as a pre-commit hook or in CI), TruffleHog (a scanner with hundreds of detectors that can additionally verify whether a found credential is still live by calling the provider), detect-secrets (a Python tool built around a baseline file to stop new secrets entering a codebase, used as a pre-commit hook), and git-secrets (lightweight git hooks that block a commit containing a secret). GitHub also offers built-in secret scanning with push protection, which is free for public repositories. Each is maintained and genuinely free or open source; which combination fits depends on where you want detection to happen.
What is the difference between pre-commit hooks, repo scanning and push protection?
They act at different moments. A pre-commit hook runs on your machine before a commit is recorded, so it can stop a secret from ever entering the local history (git-secrets and detect-secrets are built for this; Gitleaks can run this way too). Repository and history scanning runs after the fact, over the current tree and the full commit history, to find secrets that were already committed — this is the main job of Gitleaks and TruffleHog and is what you run in CI or on a schedule. Platform push-protection runs on the hosting platform when you push to the remote and rejects the push if it contains a recognised secret (GitHub push protection). Used together they form layers: the hook catches most mistakes locally, push-protection is a backstop at the remote, and history scanning finds what slipped through earlier.
Can a secret scanner catch every leaked credential?
No. Secret scanners detect by three means: signature matching (many provider keys have a fixed prefix and length, like AKIA… or ghp_…, which match with high confidence), contextual matching (a value with no distinctive shape, such as a 40-character AWS secret key, is only flagged when it sits next to a tell-tale variable name), and entropy heuristics (how random a value looks, used to decide whether a generic assignment is a real secret or a placeholder). Each method has limits: a bespoke internal token scheme with no recognisable shape can be missed, an encoded or obfuscated secret can slip through, and generic rules produce false positives on high-entropy values that are not secrets. Treat a clean scan as a useful first pass, not a proof of safety, and keep scanning as code changes rather than once.
A secret scanner found a leaked key — what should I do?
Rotate it, in the safe order. Generate the new credential first, verify it works with a real authenticated call, switch every consumer — services, CI, local environments — over to the new value, and only then revoke the old one; revoking before the replacement is proven is how teams lock themselves out. If the secret ever reached git, rotation is necessary but not sufficient: the value stays in the commit history and is readable until you purge it, and even then you should assume it was already harvested, so also review the provider’s audit log for activity you did not perform. PlayCISO’s free Leaked Credential Response and Key Rotation Planner tools walk through this sequence; the key rule is verify before you revoke.