Ask a secrets scanning vendor where it looks, how it separates real secrets from noise, whether it can block a leak before a push, and what happens after an alert. A scanner that finds secrets but cannot help you revoke and rotate them is only half a control.
These questions apply to any tool, including ours. Use them in a trial with your own repositories.
What should it cover?
1. Where does it scan? Full git history, all branches, pull requests, issues, wikis, chat exports and build logs? GitHub's own documentation, for example, says secret scanning covers the entire git history on all branches plus issues, pull requests, discussions and wikis. Compare any vendor against that baseline.
2. What kinds of secrets does it detect? Ask about provider-specific tokens, private keys, connection strings and generic passwords. Generic detection finds more but is noisier.
3. Can you add custom patterns? Your internal tokens will not be in a vendor library. Ask how custom rules are written and tested.
How does it handle noise?
4. What is the false positive rate on your code? Do not accept a marketing number. Run it on a repository you know and count.
5. Can it check whether a secret is still live? Validity checks help you prioritize, though GitHub's docs note that they may contact the issuing service. Ask what a vendor sends where and when.
6. How are test fixtures and examples handled? You need allow lists with owners and expiry, not silent ignores.
Can it stop the leak?
7. Can it block before the push? OWASP's Secrets Management Cheat Sheet advises running detection early, in the editor or in pre-commit hooks, and notes that more than one tool can catch gaps. Ask whether the vendor supports pre-commit, push-time and pipeline checks.
8. What does a developer see when blocked? A clear message with the file, the line and the fix path gets compliance. A cryptic failure gets bypassed.
What happens after an alert?
9. Does it support response? OWASP's guidance is to revoke exposed keys immediately, then rotate, remove the secret from the exposed system and check who accessed it. GitHub's docs recommend rotating the credential rather than relying on history removal. Ask whether the tool tracks alert state, owner and closure, and whether it links to your secrets manager.
10. Who gets notified? Ask about routing to the code owner or team instead of a central inbox.
Where does the data go?
11. Where does scanning run, and what leaves your network? Cloud scanning sends code to a vendor. A local option may keep source on your machine. Ask for the data flow in writing. Safeguard's CLI local runner scans on your machine and pushes only encrypted results, and its secrets scanning is also available as part of the platform.
12. How is the tool itself secured? Ask about retention, access controls and what the vendor does with detected secret values.
Walk through it at /demos/secrets-scanning.
What to do
- Pick two or three repositories, including one with a known old leak.
- Run each candidate and compare findings, false positives and time to triage.
- Test the push-time experience with a deliberate fake secret.
- Ask each vendor for the answers to questions 9 and 11 in writing.
- Decide who owns rotation, then test that path end to end.
Quick check
Is removing a leaked secret from git history enough?
No. Treat it as exposed, revoke and rotate it. Removing history is slow and does not undo exposure.
Do I need more than one scanner?
Not always, but OWASP notes that running more than one tool can catch gaps. Test coverage on your own code before deciding.
Sources
Last reviewed: 18 October 2026.
