Secrets Detection
Finding credentials that have been committed to source, images, or logs.
What is secrets detection?
Secrets detection finds credentials that have ended up somewhere they can be read: an API key committed to a repository, a database password baked into a container image, a token printed into a log file or a CI transcript. The credential is usually valid, and usually nobody remembers putting it there.
The hard part is not spotting high-entropy strings — it is deciding which of them matter. A repository contains thousands of random-looking values: hashes, test fixtures, minified identifiers, base64 assets. A detector that reports all of them is discarded within a week.
How it works
Three stages, and skipping the second is what makes secret scanning unusable:
- 01
Scan the full history, not the working tree
A secret deleted in a later commit is still in the history and still retrievable by anyone with a clone. Scanning
HEADalone misses the majority of real exposures. - 02
Match structure, then entropy
Most credentials have a recognisable shape — a provider prefix, a fixed length, a checksum. Structural matching produces far fewer false positives than entropy thresholds, and the two together are better than either.
- 03
Verify against the issuer
A candidate credential can be tested, read-only, against the service that issued it. That single call sorts a thousand suspicious strings into the handful that are live — which is the only list anyone will act on.
Why it matters
A leaked credential needs no exploit. There is no vulnerability to chain, no privilege to escalate — the attacker simply authenticates. Automated scrapers monitor public commit feeds and use newly-published cloud keys within minutes, which is faster than most incident processes can revoke them.
The response is also routinely wrong. Deleting the line and force-pushing feels like a fix and is not: the credential is still valid, it is still in every existing clone, and it is in the platform's own commit history. Rotation is the fix. Removal is cleanup. A tool that reports a finding without saying that is teaching the wrong response.
What value it adds
Catches the shortest path to compromise
A valid credential skips every other control you have.
History-aware
The exposure is in the commit history whether or not it is in the current tree.
Verification collapses the noise
Live-credential checking turns an unreadable report into a short, actionable list.
Covers more than source
Container image layers, CI logs and build artifacts leak credentials as readily as repositories do.
Prevents the next one at the gate
A guardrail at pull-request time stops the commit rather than reporting it afterwards.
How Safeguard uses it
Safeguard scans full history, container layers and build output, matches structurally before falling back to entropy, and verifies candidates against their issuer so the report is credentials that are live rather than strings that look random. See Safeguard Code and the secret detection workflow.
Find the keys that still work.
Safeguard scans history, images and logs, then verifies which credentials are live so you rotate the ones that matter.
Self-healing security runs on Safeguard.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.