Secrets management is how you store, issue, rotate and audit credentials. Secrets scanning is how you find credentials that ended up where they should not be, such as source code, logs and chat. One prevents sprawl; the other catches what slips through. Most teams need both.
What does secrets management do?
It gives credentials a controlled home, usually a vault or a cloud provider's secret store, with access rules and an audit trail. Applications fetch secrets at run time instead of carrying them in files. The OWASP Secrets Management Cheat Sheet covers topics such as logging and accounting, rotation versus dynamic creation, CI/CD, cloud providers, containers, encryption, detection and incident response.
The goal is that a secret has an owner, a scope, an expiry and a record of who used it.
What does secrets scanning do?
Scanning looks through repositories, commit history, container images, logs, tickets and sometimes chat for strings that look like credentials, such as keys and tokens, and flags them. It matters because people paste secrets into commits and config files, no matter how good the vault is. OWASP's cheat sheet lists detection as its own topic for that reason.
How do they differ?
Direction. Management is preventive and design time: where credentials should live. Scanning is detective: where they actually are.
Coverage. A vault only protects secrets that were put in it. Scanning finds the ones that never made it.
Outcome. Management reduces how many secrets are exposed. Scanning gives you a list to fix, and a prompt to rotate.
Failure mode. Without management, scanning is endless whack a mole. Without scanning, a single stray key can sit in history for years.
A constructed example
A team stores database passwords in a vault and gives services short lived credentials. A developer debugging locally copies a cloud access key into a test file and commits it. The vault knew nothing about it. A scan on the pull request flags the key, the developer removes it, and the security lead revokes the key because it was already in history. The lesson: finding the key is step one, rotating it is step two. Deleting a commit does not undo exposure.
What does a minimal setup look like?
Use a vault or provider store for production secrets. Prefer short lived, scoped credentials over long lived ones. Scan on pull requests and in a periodic sweep of full history. Define who rotates a leaked secret and how fast. Extend scanning to logs and build output, where secrets often leak.
How to check or apply this
- List where secrets live today, honestly, including laptops and CI variables.
- Move production secrets into a managed store.
- Reduce lifetimes and scope.
- Add scanning to pull requests and run a history scan once.
- Write a leak runbook: revoke, rotate, check usage logs, clean up.
- Block commits of known secret patterns where practical.
- Review access to the vault.
- Track time to rotate after a finding.
Safeguard's secrets scanning is built for the detection side, and its pull request gates can block merges with findings. It does not replace a vault.
What gets missed most often?
History and side channels. Teams scan the current branch but not old commits, forks or archived repositories. They scan code but not CI logs, container layers, wiki pages or chat exports. They find a key but do not check access logs for use before rotation. And they keep long lived keys because rotation is painful. The fix is shorter lived credentials issued by the management side, which shrinks the damage window when scanning does catch a leak. Track two numbers: how many findings are open, and how long it takes from detection to rotation.
Quick check
If we use a vault, do we still need scanning?
Yes. A vault cannot see secrets that were copied into code, logs or tickets.
Is deleting the commit enough after a leak?
No. Treat the secret as exposed and rotate it.
Sources
Last reviewed: 18 October 2026.
