You find a published image ships a valid private-feed token — what has to happen beyond fixing the build, and why?

## Why publication is one-way An image is copied by design. Once it has been pushed, its holders are a set you cannot enumerate: hosts that pulled it, mirrors and pull-through caches that fetched it on their own schedule, images built on top of it, and copies exported to files and passed around. Every one of those holds the same layers, including the one carrying the token. So the incident has a fixed shape. **The value is out. The only variable you still control is whether it is accepted.** ## What each tempting cleanup actually buys | Action | What it does | What still holds the value | |---|---|---| | Delete the tag | Stops that name resolving to the image | Pulls by the image's content identity, plus every existing copy | | Republish the tag from a fixed build | Points the name at a clean image | The earlier image, unchanged and still pullable | | Delete the repository | Stops new pulls from that registry | Mirrors, caches, hosts that already pulled, exported files | | Rebuild with a scoped mount | Prevents recurrence | Everything published before the fix | | Revoke and rotate at the issuer | Makes the leaked value useless | Nothing that matters — the copies remain, the credential does not work | Only the last row changes the fact the attacker cares about. ## The response, in order 1. **Scope it.** Name what the token can do and where it can be used from — read a feed, publish to it, reach other systems on the same identity. That sets urgency, and it sets who needs to be told. 2. **Rotate at the issuer.** Issue a replacement, cut over the consumers that legitimately use it, and stop the old value being accepted. Do this before the fix is advertised. 3. **Look for use you did not make.** Whatever issued the credential is the place with the record of its use; check it over the window from first publication, not from discovery. 4. **Fix the build.** Hand the replacement to the one step that needs it through a step-scoped mount, so the new value is never in a layer or in the recorded build inputs. 5. **Republish and move consumers forward.** Then, separately, clean up the old images — worth doing to limit further spread, as long as nobody mistakes it for the remediation. ## Sequencing, and why it is the senior part of this question The ordering is the judgment being tested. Two pressures pull against each other: - **Rotate too early and you break consumers.** If other systems use the same token, cutting it before they are moved turns a disclosure into an outage. This is why long-lived credentials shared across consumers are expensive to rotate — and why that expense is itself the argument for short-lived, narrowly scoped ones. - **Rotate too late and you advertise the target.** A commit and a rebuild that visibly remove a baked credential tell anyone watching that a specific published image contains one. The window between the fix becoming visible and the value dying is the dangerous one. The usual resolution is to issue the replacement and move consumers first, then revoke, then publish the fix — compressing the visible window as far as the consumer cutover allows. ## The honest edge case If the value was short-lived and had already expired before you found it, the exposure is historical rather than live, and the work is the build fix plus a check of use during the window it was valid. That is an argument for issuing short-lived, narrowly scoped credentials to builds in the first place — not an argument that baking them in is acceptable when they are short-lived. ## What "fixed" means here A build-time credential leak is closed when three statements are all true: the leaked value is no longer accepted anywhere; the build can no longer produce an image containing a credential; and someone has checked what the value was used for while it was live. A green rebuild satisfies only the second.