Secrets Scanning Explained: Finding Credentials in Code for DevSecOps

Hard-coded secrets — API keys, database passwords, private keys, access tokens — committed into source control are one of the most reliable ways into an organisation. Secrets scanning is the practice of finding them before somebody else does.

Why it is worse than it sounds

Three properties make a committed secret unusually dangerous.

Git history is permanent. Deleting the line and committing does not remove the secret. It remains in the history, retrievable by anyone who can clone the repository. The fix is rotation, not deletion — a point covered below, and the single most important thing to get right.

Repositories spread. Forks, clones, CI caches, developer laptops, backups. Once a secret is in history, every copy carries it.

Public exposure is exploited fast. Automated scanners watch public repositories continuously, and credentials pushed to a public repository are frequently used within minutes. Cloud keys in particular get picked up and used for cryptomining almost immediately.

How scanners find them

Two complementary techniques, and knowing both is the exam-level understanding.

Pattern matching. Many credentials have recognisable structure — a prefix, a fixed length, a character set. AWS access key IDs, GitHub tokens and Stripe keys all match specific regular expressions. High precision where the pattern is distinctive.

Entropy analysis. Random strings have higher entropy than ordinary code or prose. Flagging high-entropy strings catches credentials with no recognisable format. It also produces false positives on hashes, encoded blobs and test fixtures, which is why entropy alone is noisy.

The refinement that matters operationally is verification: the scanner takes a candidate credential and makes a harmless authenticated call against the relevant service to see whether it actually works. A verified live key is an incident; an expired one in old history is cleanup. Tools like TruffleHog do this, and it is what makes the output actionable rather than a list of thousands of maybes.

Where to scan

Pre-commit hooks catch a secret on the developer's machine before it ever enters history. Cheapest possible fix, but locally bypassable.

Pre-receive hooks on the server reject the push outright. Not bypassable, which makes it the strongest preventive control.

CI pipeline scanning on every build, failing the build on a verified secret.

Full history scanning across every branch and every commit, which is what you run once at the start and then periodically.

Beyond the repository. Secrets also appear in CI logs, container images, configuration files, wikis and ticketing systems. Scanning only the code misses a lot.

Remediating properly

The order matters, and getting it wrong is the common failure.

Rotate first. Revoke the exposed credential and issue a new one. Do this before anything else, because until it is revoked the secret is live regardless of what you do to the repository.

Then investigate. Check the service's audit logs for use of that credential by anyone unexpected, and for how long it was exposed.

Then clean the history if you need to — with git filter-repo or BFG. Understand that this rewrites history, breaks every existing clone, and does not reach forks or caches. It is worth doing for a private repository; for a public one that has already been cloned, assume the secret is gone forever and rely on rotation.

Then fix the cause. Move the secret into a proper store.

Where secrets should live

A dedicated secrets manager — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — providing centralised storage, access control, audit logging and automatic rotation. Applications retrieve secrets at runtime using a workload identity rather than holding a long-lived key.

Environment variables are a step up from hard-coding but are not a secure store: they leak into process listings, crash dumps and logs. Configuration files must be excluded from version control, with a committed .env.example containing placeholder values.

The strongest answer is to remove long-lived credentials entirely, using short-lived tokens and workload identity federation so there is no static secret to leak.

Where it appears on the exams

CySA+ (CS0-003) covers it under software assurance and secure coding practices.

Security+ (SY0-701) addresses secure coding and secrets management.

PenTest+ (PT0-003) comes at it offensively — repository mining is a standard reconnaissance technique.

What to remember

Deleting a secret from a file does not remove it from git history, so rotation comes first and always. Scanners combine pattern matching with entropy analysis, and verification against the live service is what separates real findings from noise. Pre-receive hooks are the strongest preventive control. Secrets belong in a secrets manager, ideally replaced by short-lived credentials.

Related reading: SBOM · Fuzzing · OWASP Top 10