Hardcoded secrets are detected by scanning files for strings that match known credential formats, strings that look random enough to be keys, and names such as password or token assigned to a literal value. Good scanners combine all three, because each method alone misses things or raises false alarms.
What counts as a hardcoded secret
A hardcoded secret is a credential written directly into code, config or a script: an API key, a database password, a private key, a signing token. The OWASP secrets guidance notes that plaintext secrets in source and config files are common and spread easily, and that a secret committed to code can persist in git history even after it is removed from the current files.
The three detection methods
| Method | How it works | Strength | Weakness |
|---|---|---|---|
| Pattern matching | Matches known formats, such as a fixed prefix and length | Few false alarms for known providers | Misses custom or unknown formats |
| Entropy analysis | Flags long strings with high randomness | Finds unknown token types | Flags hashes, IDs and test data |
| Context rules | Looks at variable names and file types, such as a password assigned a literal | Catches human chosen passwords | Noisy in test and example files |
OWASP advises balancing pattern based detection against entropy based detection so that passwords chosen by people are not missed, and running more than one tool to find coverage gaps.
Where to run detection
Earlier is cheaper. Run it in the editor or as a pre-commit hook so the secret never reaches the repository, then again in CI as a backstop, then across the full history on a schedule. Each stage catches what the previous one missed.
Steps to set it up
- Scan the current working tree first and fix what is found.
- Scan the full git history, since old commits still hold old secrets.
- Add a pre-commit hook and a CI check so new secrets fail the build.
- Decide a policy for test fixtures, such as one agreed fake value per credential type, so reviewers can tell fake from real.
- Write down the rotation steps before you need them.
Detection is not the fix
Finding a secret is only the start. Revoke it, issue a replacement, and then remove it from code and logs. A restart does not revoke a stolen credential. See what to do after a secret reaches git history for the response order.
How Safeguard helps
Safeguard covers SBOM and dependency scanning, reachability analysis, and policies and gates that apply in pull requests. The free scan is a quick way to see your dependency findings.
Quick check
Is entropy detection enough on its own?
No. It flags random looking values such as hashes and identifiers, so it is noisy, and it needs patterns and context rules next to it.
Does deleting the secret from the file fix the problem?
No. The value stays in git history and must be revoked and replaced.
Sources
- OWASP Secrets Management Cheat Sheet (fetched 19 October 2026): plaintext secrets, git history persistence, pattern versus entropy balance, rotation after leak.
Last reviewed: 19 October 2026.
