Secrets scanning is the better tool for hardcoded credentials, because it matches known token formats and searches git history and other text. SAST can flag a password assigned to a variable, but it focuses on code flaws, so treat any secret it finds as a bonus rather than your control.
How each approach finds a secret
A secrets scanner uses patterns for credential types, such as cloud access keys or personal access tokens, and checks every plaintext file against them. Trivy's secret scanner, for example, inspects container images, filesystems and git repositories and ships built in rules for several providers, with custom and allow rules available.
SAST looks at code structure. It may notice a string literal passed to a login call or a variable named password, and report it as a weak practice. It is less likely to recognise a token pasted into a config file, a test fixture or a comment.
Where secrets leak that SAST never looks
GitHub's documentation lists what its scanning covers: the full git history of all branches, issue and pull request text, discussions, wikis and secret gists. A key committed once and deleted in the next commit is still in history. A SAST run on the current branch tip will not see it.
Container images are another place. A secret copied into a layer during a build stays in that layer even if a later step deletes the file. Scanning images catches that.
What secrets scanning still misses
- Credentials with no recognisable format, such as a generated password in a config file.
- Secrets in files a scanner skips by default. Trivy notes that files in built in allowed paths are skipped.
- Secrets held in memory or sent over chat, which no repository scanner sees.
Add custom rules for your own token formats and review the allow lists now and then.
What to do when a hit is real
GitHub's advice is blunt: rotate the affected credential immediately. Rewriting history is slow and often unnecessary once the credential is revoked. Treat the key as public from the moment it was pushed, then check access logs for use you did not make.
A simple way to combine them
- Run secrets scanning on every push and across history once, to find old leaks.
- Keep SAST for flaw patterns, and accept its secret findings as a second opinion.
- Use push protection to block new leaks before they land.
Quick check
Is deleting the file enough after a secret is committed?
No. The secret remains in history and in clones. Rotate it first, then clean up if needed.
Can SAST replace a secrets scanner?
Rarely. SAST does not search history or non code text the way a dedicated scanner does.
Sources
Last reviewed: 19 October 2026.
