How does a secret scanner decide a string literal in source is a live credential?

### Why a credential is hard to recognise Every other finding a security analyzer produces is about *structure* - a path, a call, a shape. A hard-coded credential is about *content*: a run of characters that looks like a key. There is no dataflow to follow, so a detector has to guess from the string itself and from its surroundings, and that is why this detector family has such a distinctive error profile. ### The three detector families **1. Provider-shaped patterns.** Many credential issuers emit tokens with a fixed prefix, a fixed length and, increasingly, an embedded checksum over the body. A rule matching that grammar is extremely precise: a match is nearly always a genuine token of that type, and the checksum lets the detector reject look-alikes without contacting anyone. The weakness is coverage - it recognises only the issuers someone wrote a pattern for, and it recognises nothing about a database password chosen by a human. **2. Entropy heuristics.** A generic detector extracts candidate tokens (quoted literals, values after an assignment, long unbroken runs of characters) and scores their **Shannon entropy** - the average information per character over the string's own character distribution. Random-looking material scores near the alphabet's ceiling: roughly 6 bits per character is the maximum for a 64-symbol encoding, about 4 for a hexadecimal one, while ordinary identifiers and prose score far lower because their characters are unevenly distributed. Detectors set a threshold, often somewhere around 4.5 bits per character over a minimum length, and flag what clears it. High recall against unknown issuers; poor precision, because the world is full of high-entropy strings that are not secrets. **3. Contextual heuristics.** The name beside the value carries signal: an assignment target or key containing words for password, token, key or secret raises the score, and a path or filename containing test, sample, fixture or example lowers it. This is usually a multiplier on the other two rather than a detector on its own. **4. Verification (optional, and a judgement call).** Some scanners take a candidate and ask the issuing service whether it is live. That converts a guess into a fact and collapses false positives to near zero for supported issuers - but it sends candidate credentials to a third party, and it must be a deliberate, documented decision rather than a default someone turned on. ### Why real keys are still missed A credential assembled from concatenated fragments has no single high-entropy literal. A credential wrapped in an extra encoding layer looks like data. A weak human-chosen password has low entropy by definition and cannot clear an entropy threshold without drowning the report in prose. Secrets living outside the scanned tree - a build configuration, a container image layer, a deployment manifest, a notebook, a binary asset - are missed simply because they were never fed in. And a scan of the working tree only says nothing is there *now*: a credential removed in a later commit is still present in the history, still readable by anyone with a clone, and still live until it is rotated. ### Why innocent strings are flagged Digests, content hashes, opaque identifiers, lockfile integrity fields, sample keys copied from documentation, deliberately fake fixtures used by tests, minified assets and encoded test payloads all look exactly like credentials to an entropy detector. On the 11-person ride-hailing dispatcher team, a first history-wide scan flagged 213 candidate strings across the repository; 26 were real credentials, 9 of which had already been rotated for unrelated reasons, and the largest single false-positive family was a fixture file of encoded dispatch payloads used by the routing tests. ### Triage differs from every other finding The point worth making in an interview is that a confirmed secret finding is an **incident**, not a backlog item, and the order of operations is fixed: 1. **Rotate first.** Assume disclosure from the moment the value was committed. Deleting the line changes nothing - the old commit still carries it. 2. **Then check use.** Look at the issuer's own logs for use of that credential from unexpected places or at unexpected times, and be careful reading those timestamps: on the dispatcher's estate, a clock-skew artefact between build agents once made a rotation look as if it had happened *after* a suspicious use, which sent the team chasing a compromise that had not occurred. 3. **Then remove and prevent.** Take the literal out of the code, move it behind a runtime-supplied value, and add the pattern to the detector so the family cannot come back silently. And the program-level move: because precision decides whether anyone keeps reading, most teams run the high-precision provider patterns as a blocking check on new changes, and keep the broad entropy sweep as a periodic, human-reviewed pass over the whole history rather than something that stops a change.