Catching & Containing Leaks

One snapshot of one branch was searched. Every other branch and tag, every earlier version of every file on all of them, and every copy living outside that repository — forks, clones, mirrors, exported archives — were never read.

A stolen credential authenticates successfully, so failure-based alerting never sees it. The evidence lives in reads that were permitted — an unfamiliar caller, an odd source or hour, more names or more volume than the job needs.

A history rewrite reaches only the repository you rewrote. Clones, forks, mirrors, the hosting platform's cached view, build logs, published artefacts and every backup taken in those six weeks still hold the value - as does anyone who read it.

Treat the whole interval as unobserved use: assume the credential was copied by strangers throughout it, and scope the response to every right it carried for three weeks, not to the moment you found it.

Neither engine has anything to work with: no issuer stamped a recognisable prefix, length or checksum on a password a person typed, and at under twenty characters it sits below the minimum length an entropy score needs before it means anything.

Per identity: which names it reads, how many reads a start costs, how often it starts, from which sources, at which hours, and whether it ever lists. A departure needs a recorded shape to depart from.

It cannot say who changed a value or when a version appeared, who enumerated the names without reading them, or who was refused. Listing is disclosure, and an empty refusal history proves nothing if refusals were never emitted.

Scope follows the rights the credential carried, not the calls your own jobs happened to make. Enumerate every action and object it was entitled to, everywhere the value was accepted; observed traffic describes your usage, never a stranger's limit.

An entropy heuristic measures randomness and length, not meaning: a 40-character hexadecimal build identifier has the same character spread as a freshly minted key, so it clears the threshold. Nothing in the string says what produced it.

Each entry needs the acting identity as a stable identifier, how it authenticated, the value's name and version, the operation and its outcome, the source it came from, and a precise timestamp. It must not carry the value.

Private bounds how many parties could read the value, not whether the value must be replaced. Read access, automation, clones, forks, backups and the hosting platform itself all sat inside that boundary for six weeks, and reads are not enumerable.

Breadth beyond need. The identity is reaching past its job, and the listing already discloses what the branch holds even before any value is read — all of it permitted, so nothing in the outcome field reports it.

Only that the reads are far beyond any need this job has, and must be explained. A restart loop, a retry storm or a cache that stopped caching produces the same count. Volume says look, not guilty.

Two things: sealing each entry to its predecessor so an edit or a removal breaks the chain, and shipping entries continuously to a destination whose write rights are append-only and whose administrators are different people. Both give evidence, not prevention.

Rewriting first changes no copy's validity and broadcasts a precise signal: a rewrite landing on an old revision tells anyone watching which value mattered, while that value still works. Replace and withdraw the old value first; clean up afterwards.

Because the replacement travels the same route the old value escaped on. Until you know which copy left and how, you have re-supplied the leak, and every other value carried the same way is already out too.

The store's read record shows which identity fetched the value and when. The counterparty's usage record shows what was called with it, and from where. Neither sees the other side, so a response needs both.

Split it into two jobs: a one-off backlog, ranked by whether each value is still accepted and what it reaches; and a narrow, high-precision check on new material that nobody may mute. Suppress single findings, never engines.

Not the engineer who found it. A named decision-maker declares against a threshold agreed in advance, and a single named voice contacts the counterparty — which is also how you obtain the usage record only they can see.

The service being called records it — a successful authentication attributed to the credential's identity, from your address. If that service belongs to a partner, your test appears in their records as their credential used from somewhere new.

One each, on detectability alone: a shared identity averages 400 workers into one shape, so a thief's reads hide inside the fleet's normal spread. The cost is 400 thin baselines and churn that resets them whenever the fleet scales.

The longest realistic lag between a credential escaping and anyone noticing, plus the span of outside questions you must answer. Against that: a long-kept record maps which identity reads which credential, so protect it in step.