Security · Updated 2026-09-17
Secret scanning
Detecting credentials — API keys, tokens, private keys, connection strings — committed into source control or present in a proposed change.
Also called: Credential scanning
What it is
Secret scanning matches content against patterns for known credential formats, plus entropy heuristics for the ones with no fixed shape. It runs on diffs, on full history, or at the pre-commit stage.
Why it is one of the few findings worth blocking on
Most automated findings are advisory. This one is not. A committed credential is compromised the moment it is pushed — history rewriting does not help once a mirror, a fork, or a CI log has it, and scrapers watch public pushes continuously. The correct response is always rotation, not deletion.
That makes it the clearest candidate for a required check: the false positive rate is low, the cost of a miss is high, and the fix is unambiguous.
Where it belongs in the pipeline
As early as possible. A pre-commit hook that refuses the commit is worth more than a pull request comment, which is worth more than a nightly scan of history. Every stage later is a stage where the secret has already left the developer’s machine.
Why it matters when you are evaluating
Check three things: whether scanning covers full history or only the diff, whether the tool can be given custom patterns for your own internal token formats, and whether detection triggers an alert path that someone actually watches. A finding in a dashboard nobody opens is not a control.
Common mistakes
- Removing the secret in a follow-up commit and considering it handled.
- Not scanning CI configuration and infrastructure files, where credentials cluster.
- Allowing developers to suppress a finding without recording why.