How we compared them
We make a free key checker and a Leak Check at Continuum, so we say where the repository scanners do a better job.
A secret can leak in three places: a commit, the git history, and the JavaScript your live site serves to every visitor. Each option was weighed on:
- Which of those places it looks at.
- Whether it can tell a live key from a dead one.
- How much setup it needs and who can read the result.
- What it misses.
The options
Options are listed from the one built into GitHub outward, which is not a ranking. Facts about other products come from the sources at the bottom.
GitHub secret scanning and push protection
Built into GitHub
GitHub matches known secret formats. Push protection blocks a push that contains a credential from a supported provider before it reaches the repository. For provider patterns, GitHub also reports the leak to the provider so it can act, for example by revoking the key.
- Good at
- It stops the classic accident at the moment it happens, with almost no setup.
- Fits
- Anyone whose code is on GitHub.
- Drawbacks
- GitHub’s docs say older and legacy token formats may not be covered and that very large pushes can time out, with the scan running after the push. It reads the repository, not the files your live site serves.
Sources: [1]
Gitleaks
A scanner you run yourself
Gitleaks describes itself as a tool for detecting secrets like passwords, API keys and tokens in git repositories, files and standard input. Its current command line has dir, git and stdin scans.
- Good at
- You run it where you choose, on a folder, on the full git history or on piped text.
- Fits
- A developer who wants to check history and add a check to a build.
- Drawbacks
- A match means a string looks like a secret. Whether it is a live credential is for you to find out, and it needs a command line.
Sources: [2]
TruffleHog
A scanner that tests what it finds
TruffleHog describes itself as a tool that finds, tests and analyses leaked credentials. Its README says it classifies over 800 secret types. Verification tests a found credential against the provider’s API to see whether it is live. Results come back as verified, unverified or unknown.
- Good at
- Verified results tell you which leaked keys still work, which is the list to rotate first.
- Fits
- A developer or security-minded friend running a clean-up after a leak.
- Drawbacks
- Verification means your found credential is sent to the provider’s API to be tested, so decide whether you are comfortable with that for your keys. It also needs a command line.
Sources: [3]
Continuum key checker and Leak Check
Paste a key, or read the live site
The key checker is free. You paste a key, a line from your .env file or the whole file, and it says whether the key is safe to expose, server only, or leaking through a NEXT_PUBLIC_ prefix. It runs in your browser and makes no network request. The free Leak Check reads the client bundle of your live app for exposed keys such as Stripe, OpenAI and AWS credentials.
- Good at
- The Leak Check looks at what the public can actually download, which repository scanners do not. The key checker answers “does this key belong in front-end code” in plain words, and for a value it does not recognise it says to treat it as server only.
- Fits
- A non-technical founder who needs a straight answer, or a developer checking a deployed site.
- Drawbacks
- Neither tool searches your git history, and the key checker only judges the text you paste. The Leak Check is a surface scan that Continuum itself says is not a full security audit.
Open the free key checker →