Pick a secrets scanner by testing it on your own repositories, not by reading feature lists. Check where it runs (editor, commit, pull request, history), how it handles noise, whether it redacts values, and how fast a found secret reaches the person who can revoke it. This guide does not rank vendors.
A scanner that finds everything and gets ignored is worse than one that finds less and gets acted on. Most of the criteria below are about that gap.
Where should the scan run?
OWASP's secrets management guidance says to run detection before code is committed, for example in the IDE or a pre-commit hook, and to use more than one tool and compare results to find gaps. Take that as a two layer design.
- Early layer: editor or pre-commit. Cheap to fix, but people can skip it.
- Enforcing layer: pull request or CI. Cannot be skipped, so it is where policy lives.
Ask each candidate which layers it covers and whether the same rules run in both. Different rules in each layer means developers fix things twice or learn to distrust one of them.
Does it scan history, or only the current files?
A secret deleted in the last commit is still in the repository history. A tool that only reads the working tree reports a clean repo that is not clean. Ask whether it scans past commits, branches and pull request diffs, and how long a first full history scan takes on your largest repository.
How does it handle false positives?
This decides adoption. Ask for specifics.
- Can you mark a finding as a known false positive in a file that is reviewed like code?
- Does it combine pattern matching with other signals, such as entropy or context? OWASP notes the tradeoff: strict format matching misses human-chosen passwords, loose matching creates noise.
- Can it tell you whether a found credential is still valid? Not every tool can, and checking validity means making a call to the provider, so ask how that is done and who authorizes it.
What does it do with the secret it finds?
A scanner that prints the secret into a CI log has created a second leak. Look for redaction by default. Safeguard's CLI, for instance, redacts values in detect output unless you explicitly turn that off, per its docs. Whatever you evaluate, test it: plant a fake credential and read the log.
How fast does a finding reach someone who can act?
OWASP's order after a leak is: revoke the exposed secret immediately, issue a replacement through an automated process, remove the secret from every exposed location, and keep records. Your tool does not do the revoking, but it should make the first step quick. Check what a finding contains: file, line, commit, author, secret type. A finding that says only "high entropy string" costs a human twenty minutes.
What are the deployment limits?
Questions for security and legal teams: Does source code leave your network? Does the tool work air gapped? Can it run in your CI without a long lived token with broad scope? Does it write standard output such as SARIF so existing code scanning views can display results? SARIF is an OASIS standard for static analysis results, designed so findings from many tools share one structure.
What to do
- Write down your layers: editor, commit, pull request, history, and who owns each.
- Build a test repository with fake secrets of your own types: cloud keys, database URLs, tokens, a password in a config file, one buried in an old commit.
- Run each candidate against it and score detections, misses and noise.
- Run it on one real repository and count findings a developer would call false.
- Check the logs and reports for exposed values.
- Time the path from a finding to a ticket with an owner.
- Decide the policy before rollout: what blocks a merge, what warns.
Quick check
Is one scanner enough?
OWASP suggests using more than one detection tool and comparing results to find gaps. Start with one, then compare against a second on a sample.
Do I still need rotation if I scan?
Yes. Scanning finds leaks, rotation limits how long a stolen credential works.
Safeguard's CLI can run safeguard detect on a directory for secrets and misconfigurations, with table, JSON or SARIF output. Free, in-browser scanning of up to 100 dependencies is available at gold.safeguard.sh/scan, though that is dependency scanning rather than secrets scanning.
See the same flow full screen.
Sources
Last reviewed: 18 October 2026.
