Automated scanning for committed credentials is a standard control. Explain what a scanner can and cannot establish, why some credential formats are far easier to find than others, and what that implies for teams that issue credentials.

## What a scanner is actually doing A secret scanner classifies text. Given a diff, a file, a repository's history or a built artifact, it must decide whether a run of characters is a live credential. Every property of the control follows from the difficulty of that classification. **Recognisable credentials.** When a credential has a distinctive fixed prefix and an embedded checksum over the random part, the classifier is essentially exact: the prefix narrows the candidate set to almost nothing else, and the checksum removes the remaining false positives. Better still, the issuer can be asked whether the value is live, turning a lexical match into a verified finding. Scanning at that quality can be run continuously across whole ecosystems, and issuers can act on a hit themselves. **Unstructured credentials.** A 32-byte base64 value has no distinguishing marks. It looks exactly like a hash, a UUID-ish identifier, a test fixture, an encoded certificate fragment or a chunk of minified output. The scanner is reduced to Shannon-entropy heuristics plus context guesses from nearby variable names, and it must choose an operating point: a low threshold buries the team in false positives until alerts are ignored, and a high threshold silently misses real credentials. **Passwords.** A human-chosen password has neither structure nor high entropy, so it is effectively undetectable by content. It is found only through context — an assignment to a variable named like a password, or a known connection-string shape. ## The claim this supports The most important consequence runs backwards, toward whoever *issues* credentials. **Detectability is a property you design into the credential, not a property of the scanner.** If your platform issues API keys, giving them a stable prefix and a checksum costs nothing and makes every scanner in the world — including the ones your customers run and the ones code-hosting platforms run by default — capable of finding your credential accurately and telling you about it. If you issue opaque random blobs, you have opted the entire ecosystem out of protecting your users. That is a design decision that most engineers have never considered and it is exactly the sort of point that distinguishes an answer at this tier. A second consequence: because verification is possible for structured credentials, findings can be prioritised by liveness rather than by count. A scanner that reports ten thousand possible secrets is useless; one that reports forty confirmed-live credentials is an incident queue. ## Where to run it, and why placement decides effectiveness - **Local pre-commit hooks** catch mistakes before they leave the machine and are the cheapest place to fix them, but they are advisory: they run on the developer's machine, are skipped by a bypass flag, and are absent on fresh clones. Never treat them as the enforcement point. - **Server-side, where code lands** (on push, or as a required check) is where enforcement belongs, because that is the boundary the code cannot avoid crossing. - **Full-history scans** matter because the interesting leaks are usually old. A control that only inspects new changes leaves the existing backlog invisible. - **Build outputs and images** deserve their own scan: credentials frequently enter through generated configuration, bundled assets or files copied into an image, none of which appear in source review. ## Responding to a hit The order mirrors any disclosure: **rotate first**, then investigate whether the credential was used during the window, then purge copies, then fix the path that allowed it. Investigating before rotating is the common and costly inversion, because triage takes hours during which the value stays live. If a hit is a false positive, the cost was a rotation; if it was real and you triaged first, the cost is unbounded. One organisational trap deserves naming: rolling out scanning before rotation is cheap produces a large backlog with no way to clear it, and teams then learn to suppress findings. Build the ability to rotate quickly first; then turn on detection. ## Placing it on the ladder Using the ordering that runs structural separation, then transformation, then scope-and-lifetime policy, then detection: scanning is the last rung and is inherently the weakest, for a specific reason rather than a stylistic one. Every rung above it holds a property that is true whether or not anyone is looking — the artifact contains no credential; the ciphertext is useless without a key held elsewhere; a short-lived narrowly scoped credential caps what its disclosure costs. Scanning holds only a probability, conditional on the pattern being recognisable, the scanner running over that location, and someone acting on the alert. It remains worth doing, because the rungs above are never deployed perfectly and detection is what tells you where they failed. But a programme that consists only of scanning has bought a sampling of its own failures, not a control.