A secrets scanner has to read the very strings you most want protected, so ask how findings are masked, where full values are stored, who can see them and how they are deleted. Good answers are short: store a fingerprint and a masked preview, never the raw secret, and never write it to logs.
Why this deserves its own review
Most scanner findings are descriptions of a problem. A secret finding is the problem itself. If a vendor console, ticket integration or support export holds the full value, you have copied a live credential into another system.
GitHub's documentation notes that its secret scanning checks the full Git history across all branches, and also pull requests, issues and wikis. A third party scanner with similar reach will see old, forgotten credentials too, so the volume of sensitive material can be larger than teams expect.
Four places a secret can leak
- The console. Is the full value displayed, or masked with a few characters?
- Notifications. Do email, chat or ticket alerts include the string?
- Logs. OWASP's logging guidance lists access tokens, passwords, connection strings and encryption keys among things that should not be logged. Ask whether the vendor follows that rule in its own logs.
- Exports and support bundles. Do reports or diagnostic files include raw values?
What a good design looks like
| Aspect | Preferred answer |
|---|---|
| Storage | Hash or fingerprint plus location, not the value |
| Display | Masked, with a reveal action that is access controlled and logged |
| Alerts | Link to the finding, never the secret text |
| Retention | Findings deleted on a schedule you can set |
| Validation | Optional checks against the provider, documented, off or on by choice |
Validation is worth a question. Some tools test whether a found credential is live by calling the provider. That is useful for triage, but it means the tool makes outbound calls using your secret. Know whether it happens and who can turn it off.
After a finding: your job
Whatever the vendor does, the fix is the same. Revoke and rotate the credential first, then clean the code. Removing a string from the latest commit does not make it safe if it sits in history. Record the rotation in the ticket so the evidence exists for an audit.
Questions to put in the security review
- Is the raw secret ever persisted, even briefly?
- Which roles can reveal a value, and is each reveal audit logged?
- Are secrets excluded from AI features and from support access?
- What is the deletion timeline when we close the account?
For role design see RBAC roles to ask for in an AppSec tool.
Safeguard includes dependency and code scanning with policy gates, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Is a masked secret safe to share in a ticket?
A short masked preview is generally acceptable because it cannot be used. Check how many characters are shown, since long previews reduce guessing effort for the attacker.
Do we need to rotate a secret the scanner found in old history?
Yes. If it was ever committed, treat it as exposed, rotate it, then clean up the repository.
Sources
Last reviewed: 19 October 2026.
