Tell your CFO that secrets scanning is a smoke alarm for passwords and keys that engineers accidentally leave in code. A leaked key is a spare door key left outside. The scanner finds it early, when removing it is cheap, instead of after someone else has used it.
What is a secret, in plain terms?
A secret is anything that proves identity to a system: a cloud access key, a database password, an API token, a private certificate. Engineers need them to make software work. The risk is that they get copied into source code, a config file or a chat, and from there into places many people can read.
Once a secret is in version control, it stays in the history even if someone deletes the line. Anyone with access to the repository, now or later, can find it.
Why should finance care?
Not because of a statistic we would invent. The reasoning is simple.
A leaked cloud key can be used to run services on your account, read customer data or move money, depending on what the key allows. The cost has three parts: direct charges, cleanup time and the trust of customers and auditors. Preventing a leak costs a scan and a few minutes of an engineer's time.
Also, customers and auditors increasingly ask how you protect credentials. Being able to show a control that runs automatically makes security questionnaires shorter.
What does the scanner do?
It reads code, history and configuration looking for patterns that look like keys and tokens. Some scanners also check whether a found key is still active. Safeguard's secrets scanning is built for this, including checks while code is being pushed, and you can try it in the demo.
Open the secrets scanning demo
The important step comes after the find. A leaked key must be revoked and replaced. Deleting it from the code is not enough. The OWASP secrets guidance says the same about revocation: stopping a consumer does not revoke its credentials.
What should you measure?
Pick numbers a CFO can follow and that you can actually count.
- How many repositories are covered by scanning, out of the total.
- How many exposed secrets were found, and how many were revoked.
- How long it takes from finding a secret to revoking it.
- How many secrets were stopped before reaching the main branch.
Report trends, not a single score. If found secrets rise after you start scanning, that is the scanner working, since it is finding old problems.
What does it not do?
Be honest about limits. A scanner will miss secrets that do not match a known pattern. It cannot protect a key someone pastes into a chat tool or a ticket. It does not fix the habit that put the secret there.
The longer term answer, per OWASP's Secrets Management Cheat Sheet, is to avoid long lived secrets: use short lived and dynamic secrets, scope access narrowly and log who requests a secret. Scanning catches mistakes while you move to that model.
How much work is it?
Setup is usually small compared with other security projects, since scanners plug into the code host and the pipeline. The work is the cleanup of the first results and the revocation process. We have not quoted prices, because they vary by product; ask vendors for a written quote.
What to do
- Run a scan on all repositories, including history, to get a baseline.
- Revoke and replace every active secret found.
- Turn on scanning in the pipeline and before code is pushed.
- Name an owner for revocation and set a target time.
- Report coverage, found, revoked and time to revoke each quarter.
- Start moving toward short lived credentials.
Quick check
If we delete the key from the code, are we safe?
No. It remains in history and may already have been copied. Revoke it and issue a new one.
Is secrets scanning a one time project?
No. New secrets leak all the time. It works as a continuous check, like a smoke alarm.
Sources
Last reviewed: 18 October 2026.
