What is secrets scanning?
Secrets scanning is the automated search for credentials that have ended up where they should not be, above all in source code repositories. A secret in this sense is any value that grants access by itself: cloud access keys, API keys, OAuth and personal access tokens, database connection strings, passwords and private keys. Git keeps every version of every file, and public repositories are watched around the clock by attackers' harvesting tools, so a key committed for a few minutes can be found and abused before anyone on the team notices. Secrets scanning finds these exposures early, ideally before they ever leave the developer's machine.
How scanners recognize a credential
- Known formats: many providers give their tokens a distinctive prefix or structure. AWS access key IDs start with
AKIA, and GitHub tokens start withghp_orgithub_pat_, so a pattern can find them with few false positives. - Entropy: long, random-looking strings assigned to variables named like key, token or secret are flagged even when the format is unknown.
- Live checks: some tools ask the issuer whether a found credential still works, so an active key is triaged ahead of an expired test value.
- Custom rules: organizations add patterns for their own internal token formats, which no vendor ruleset knows.
Gitleaks and TruffleHog are widely used open-source scanners, and GitHub, GitLab and other hosting services offer built-in scanning. GitHub also runs a partner program that alerts token issuers when their format shows up in a public repository, and some issuers revoke the key on the spot.
Where scanning runs
| Stage | What happens | Limitation |
|---|---|---|
| Pre-commit hook | Staged changes are scanned and the commit is stopped | Runs on the developer's machine, so it must be installed and can be skipped |
| Push protection | The hosting platform refuses a push that contains a detected secret | A bypass is possible, but it is recorded with a reason |
| Pipeline check | The pull request fails and cannot merge | The secret has already left the laptop |
| Full-history scan | Every branch and old commit is swept on a schedule | Finds old leaks after the fact |
Mature programs also scan container images, CI logs, wikis and ticket systems, since secrets leak into all of them.
Example: an old leak found by a history scan
A nightly full-history scan flags a payment provider's live API key in a configuration file committed eight months ago to an internal repository. The file was deleted two commits later, so the current code looks clean, but the key is still in history and readable by everyone who has had access, including contractors who have since left. The team first revokes the key in the provider's dashboard and issues a replacement stored in the secrets manager. Next it reviews the provider's logs for any use of the old key since the commit date. Only then does it rewrite history with a tool such as git filter-repo and have collaborators re-clone, and finally it turns on push protection for the repository. Revocation comes first because rewriting history cannot recall copies that were already cloned.
Secrets scanning vs. SAST and DLP
- SAST looks for insecure code patterns such as injection, and may report a hardcoded password as one finding among many. Secrets scanners specialize in credentials, search history and non-code files, and can test whether a key is live.
- DLP watches sensitive data such as card numbers leaving the organization. Secrets scanning watches credentials landing in repositories.
- A secrets manager is the prevention that keeps a scanner quiet, because code fetches credentials at runtime instead of storing them.
Secrets scanning on the CompTIA Security+ exam
Secrets scanning in code repositories is one of the items added to the mitigating controls in SY0-801 objective 4.1. Wording such as stop developers from committing API keys, find credentials already sitting in old repositories or reject a push that contains a token points to secrets scanning, at whichever stage the scenario describes. When the question asks what to do FIRST after a secret has been exposed, the answer is to revoke and rotate it at the issuer, not to scan. Distractors include deleting the file in a new commit, making the repository private and adding the file to .gitignore, none of which invalidates a key that has already been seen.