Secret Scanning: A Practical Guide to Finding Leaked Keys

What secret scanning is

Secret scanning is the automated search for hardcoded credentials in the places software lives: source files, configuration, git history, container images, and pipeline logs. The targets are the strings that grant access — cloud provider keys, database passwords, OAuth tokens, private keys, webhook signing secrets. The goal is simple: find an exposed credential and get it rotated before it is abused.

It sits in the same family as other pre-production checks but answers a distinct question. A vulnerability scanner asks “does anything I ship have a known flaw?”; secret scanning asks “did we accidentally publish a key?” Both belong in a mature program, the same way the container image security checklist and supply chain security each cover a slice of the same surface.

Why a leaked secret is so dangerous

The damaging property of a secret is that it is persistent and portable. Commit a key once and it stays in git history forever, even after you delete the file in the next commit — the blob is still reachable in the repository's object store. Push that repository to a public host and the key is now indexed, cloned, and scraped by automated bots within minutes. The same key copied into a Docker image during a build persists in that layer regardless of whether a later layer removes the file.

This is why “we deleted it” is never the fix. Deleting the visible copy leaves the credential valid and leaves copies in history, images, backups, and logs. The credential has to be rotated at the source, which we come back to below.

Where secrets hide

• Source and .env files — the obvious case, a key pasted in to “just get it working.”
• Committed config — a settings file with a real value where a placeholder was intended.
• Git history — a secret added, noticed, and reverted, but still present in an old commit.
• Container image layers — a credential COPYied in during a build and never truly removed.
• CI/CD logs — a pipeline step that echoes an environment variable into readable output.
• Notebooks and scripts — ad-hoc files shared over chat or attached to a ticket.

How detection works

Secret scanners lean on three techniques, usually in combination:

• Pattern rules.Regular expressions describe the shape of a specific credential type — a provider prefix, a fixed length, a checksum. This is precise for well-structured keys and is how most tools cover the long tail of providers.
• Entropy analysis. Random-looking strings score high on Shannon entropy. Flagging high-entropy tokens catches keys that do not match any known pattern, at the cost of more noise.
• Verification. The scanner makes a read-only call to the issuing service to confirm the credential is live. This is the strongest signal because it separates a real active key from a realistic-looking fixture, but it requires network access.

The trade between them is noise versus coverage versus reach. Pattern-only tools are fast and offline but flag test data; verification is quiet and confident but needs to reach the provider. Good programs accept that no single technique is complete and tune allowlists to keep the signal usable.

The tool landscape

The open-source ecosystem is healthy, and most teams standardize on one or two tools:

• TruffleHog — detector-driven with active credential verification, strong for confirming live secrets across code, history, and images.
• Gitleaks — fast, offline, regex and entropy based, highly configurable through TOML; a common pre-commit and CI gate.
• detect-secrets — a Yelp project built around a baseline file, designed to stop new secrets while accepting a documented backlog.
• git-secrets — a lightweight AWS project focused on blocking commits that contain provider keys.
• Platform scanning — GitHub and GitLab offer built-in secret scanning and push protection that catch many credentials at the source.

Commercial services layer on managed detectors, dashboards, and automatic revocation integrations. The right choice is less about the tool and more about where you place it in the workflow.

A workflow you can adopt

Secret scanning is most effective in layers, each catching what the previous one missed:

• Pre-commit hook — scan staged changes so a developer is stopped before a secret is ever committed.
• Push protection — a platform-level gate that blocks a push containing a recognized secret, backstopping the local hook.
• CI on every pull request — a repository scan that fails the build, so nothing merges with a fresh leak.
• Periodic full-history sweeps — a deeper, sometimes verified, scan of the whole history to find what predates your tooling.
• Artifact scans — check built images for credentials and key material that entered outside the source tree.

Remediating a leak properly

When a scanner finds a real secret, the order of operations matters. First, rotate the credentialat the provider so the exposed value stops working — this is the step that actually closes the risk. Only then clean up the copies: purge it from history if warranted, rebuild any image that baked it in, and scrub the logs that captured it. Finally, prevent the recurrence by moving the secret into a proper store — a managed secrets service or a vault — and injecting it at runtime rather than committing it. Treat rotation as non-negotiable and cleanup as follow-through.

Where ScanRook fits

ScanRook is a vulnerability scanner, and a dedicated secret scanner is the right tool for credentials in source and git history — we would rather say that plainly than overclaim. Where ScanRook contributes is at the artifact boundary. When it scans a container image or source tree, it inventories the cryptographic material present — the private keys and certificates baked into the build — as part of the work we describe in what is a CBOM. That catches key material that entered the image outside your source tree, which a repository-only secret scan never sees.

The complete picture, then, is layered: dedicated secret scanning across code and history, push protection at the platform, and a vulnerability-plus-key-material scan of the image before it ships. If you want to see how much of a typical image lives below the source you wrote, our walkthrough of how to scan a Docker image covers the mechanics.

Frequently asked questions