Hardcoding a credential is usually taught as "don't put the password in the source file". Give the definition of the defect that also explains why the same value sitting in a container image layer, a build log, or a compiled binary is just as bad — and why deleting the line and force-pushing is the wrong frame for the fix.

## What a secret actually is Almost every secret an application handles is a **bearer authenticator**: a value such that presenting it is sufficient to be treated as the principal it belongs to. Passwords, API keys, database credentials, signing keys, webhook shared secrets and refresh tokens are all bearer values. Nothing in the bytes distinguishes the rightful holder from anyone who obtained a copy. Its security therefore rests on three *operational* properties, not on the value itself: 1. **Bounded distribution** — you can enumerate, at least approximately, which principals and which stores hold a copy. 2. **Revocability** — you can make every copy worthless quickly, without rebuilding and redeploying the world. 3. **Attribution** — when it is used, you can tell which holder used it. ## The defect, defined Hardcoding is one instance of a general defect: **placing a bearer authenticator into a store whose distribution you do not control and whose contents you cannot retract.** Source code is the textbook case only because it is the most visible one. What matters is the store's properties: is it replicated? is it append-only or immutable? is it readable by a broader set of principals than the credential's intended holder? Apply that test and the equivalences fall out: - **Version control.** History is content-addressed and append-only; every clone, fork, mirror, pull-request ref and CI cache is a full copy. A rewrite changes your branch, not other people's objects. - **Container image layers.** A layered filesystem unions layers; a later layer that deletes a config file leaves the earlier layer intact, and anyone who can pull the image can extract it. Registries are content-addressed and often retain digests after a tag moves. - **Compiled and packaged artifacts.** Literal strings are recoverable from a class file, a native binary, a WebAssembly module, a mobile package or a minified browser bundle. No language exempts you; obfuscation raises the cost of extraction, it does not change the security property. - **Build logs, backups, snapshots, error reporters.** These routinely capture full environment or configuration dumps, and they are usually readable by a wider audience than production itself. - **Public package registries**, which frequently forbid unpublishing entirely. Anything client-distributed is the extreme case: a secret shipped to a browser, a phone or a customer's server is public by construction, because the trust boundary runs between you and the device. ## Why "delete and force-push" is the wrong frame It answers the question "can the value still be read in the current tip?" but the property that was lost is *bounded distribution*, and that loss is irreversible the moment the artifact left your control. The only action that restores security is issuing a new credential and invalidating the old one. The correct incident order is: 1. **Rotate/revoke** the exposed credential — assume disclosure, do not investigate first. 2. **Look for use** of the old credential in access logs across the whole exposure window, which begins when the value was written, not when it was noticed. 3. **Purge** copies where cheap, as hygiene against casual reuse. 4. **Add the control** that makes recurrence structurally impossible, rather than relying on the reviewer who missed it last time. A useful consequence: if you cannot rotate a credential cheaply, you do not really have an incident response for it. Rotation cost is what turns "assume disclosure" from a slogan into a decision. ## Where the defences rank Secrets handling has the same ladder shape as injection defence — a guarantee at the top degrading into a heuristic at the bottom, in this order: - **Structural separation** — the artifact never contains the credential at all; a runtime identity the platform vouches for obtains it. The guarantee is absolute for the class: there is no value in the artifact to leak. - **Transformation** (encrypted config, sealed values) — better than plaintext, but it terminates in another secret that must itself be delivered. It relocates the problem one level down rather than eliminating it. That is exactly why it loses to structural separation. - **Validation/policy** (narrow scope, short lifetime, one credential per principal) — does not prevent disclosure, bounds what disclosure costs. It beats detection because it holds even when nobody is watching. - **Detection** (secret scanning, anomaly detection) — post-hoc and probabilistic; it finds some of what already escaped. ## What people misclassify Values that are secrets but get treated as configuration: token-signing keys, webhook validation secrets, internal service-to-service credentials, and above all any credential that unlocks the rotation path itself. Values that are *not* secrets and should not be managed as such: public keys, client identifiers, bucket names, and hostnames — treating them as secret adds ceremony without adding a property. And "it's a private repository" is not a boundary you can lean on: repository access changes with hiring, contracting, forking and misconfiguration, while the committed value does not.