What is secrets detection? Finding credentials in code and history
Secrets detection scans code, configuration, git history, and build artifacts for leaked credentials: API keys, tokens, database passwords, and private keys. Because git history is immutable, a secret committed once persists in every clone even after deletion, so a complete scan covers full history and archives, not just the current files. The remediation for a found secret is rotation, never just deletion.
Secrets detection is the practice of finding credentials that have leaked into places they should never live: source code, configuration files, git history, container images, and build artifacts. The credentials in question - cloud API keys, access tokens, database passwords, signing keys, SSH private keys - are the most directly monetizable thing an attacker can find, because they skip the exploit and go straight to access.
Why this class of leak is special
Two properties make leaked secrets different from other vulnerabilities.
First, exploitation is trivial. A SQL injection takes skill to weaponize; a leaked cloud key takes a copy-paste. Real intrusions regularly begin with a credential found in a repository rather than with anything resembling an exploit.
Second, git makes leaks permanent. Version control is an immutable ledger: a secret committed once and deleted in the next commit still exists in every clone of the repository, retrievable with a one-line command. It also propagates into forks, mirrors, CI caches, and the vendored copies inside build outputs. This is why your git history is the part that needs scanning most, and why “we deleted it” is never remediation.
What a complete scan covers
- The working tree - current source and configuration files.
- Full git history, every branch - where the deleted-but-not-gone credentials live.
- Archives and artifacts - packages, container images, and compressed bundles, with nested archives and common encodings unwrapped before matching, because a base64-wrapped key is still a key.
Detection itself should be provider-aware: recognizing the concrete formats real credentials take, using context to separate keys from coincidental high-entropy strings, and assigning each finding a fingerprint so it keeps its identity across scans.
From finding to remediation
The correct response to a found secret is always rotation: revoke the credential at its issuer, issue a replacement, store the new one properly. Rewriting history is optional hygiene afterward, never a substitute, because every pre-rewrite clone still holds the value.
The sustainable steady state is a baseline plus a gate: the initial scan’s findings each get a decision (rotate, or accept with a recorded justification), keyed to stable fingerprints, and from then on the CI pipeline fails only on genuinely new leaks. That keeps the gate quiet enough to stay enabled and catches new leaks within minutes of commit, when rotation is cheapest.
The architectural question to ask any tool
Where do candidate secrets travel during detection? Tools that upload content for analysis, or that validate candidates by calling the real provider with them, are transmitting the most sensitive strings you own as a feature. SecuSecret takes the opposite stance: history-deep, archive-deep scanning that runs entirely inside your network, with nothing ever transmitted anywhere - detection of secrets that does not itself create a secrets exposure.
Frequently asked questions
Why scan git history if the secret was already deleted?
Because deletion removes a secret from the current files, not from history. Anyone who can read the repository can retrieve every version ever committed, and the repository has been cloned, forked, mirrored, and cached in places you cannot enumerate. A secret that ever touched history should be treated as exposed and rotated.
How does detection avoid flagging every random-looking string?
Naive entropy-only detection drowns teams in noise. Provider-aware detection recognizes the actual formats credentials take and uses surrounding context, which separates a real cloud key from a checksum. Baselines then ensure known findings are triaged once, so pipelines only alert on genuinely new leaks.
Should a scanner verify secrets by testing them against the real service?
Some tools do, and it is worth understanding what that means: transmitting your candidate secrets to external services. In restricted environments that is disqualifying, and everywhere it widens the exposure the scan was meant to reduce. Fully local detection avoids the question entirely.