Hardened Templates & Images

## Why the rebuild does not arrive on its own An internal hardened base image line exists so that patching the operating system layer and the shared runtime happens once, for everyone, on a schedule. The platform team rebuilds monthly and publishes. Consumers, correctly, pin their build to a digest rather than a moving tag, because a digest is content-addressed: it names exactly one image and cannot be moved under them. Those two good practices collide. A rebuild with new patches is, by construction, different content, therefore a different digest, therefore something nobody is referencing. Currency and immutability pull in opposite directions, and nothing about pinning is wrong — what is missing is a mechanism that moves the pin. ## The three mechanisms that actually move it **1. Raise the change for them.** The platform team's automation watches for a new base digest and opens a change in every consuming repository that updates the pinned reference, runs that repository's own test suite, and carries the changelog in the description. The important design point is who does the work: if adopting the monthly rebuild costs a service team a planning conversation, it will not happen. If it costs one review of an already-green change, it will. Where a team's tests are trusted, allowing that change to merge automatically on green pushes adoption further. **2. Make staleness fail rather than sit.** A build-time check compares the age of the pinned base digest against a maximum age and warns, then fails, once it is exceeded. This is the crucial inversion. Without it, a stale pin has no symptom at all: builds are green, the service runs, and the only person who knows is whoever later reads a scan report. With it, staleness becomes a build failure that lands on the team that owns the service, at a time of your choosing, with a documented fix. Roll it out as a warning first with a published date on which it starts failing, so the deadline is predictable rather than an outage. **3. Retire the old image.** A digest that stays pullable forever is a comfortable place to stay. A retirement policy — the old digest becomes unavailable, or builds against it are refused, after the support window — closes the option. This is the sharpest of the three and needs the most warning, because it turns a currency problem into a build outage for anyone who ignored the first two mechanisms. ## Rebuild is not redeploy A common mistake in interviews is stopping at the pin. Updating the base digest in a repository patches the *next image the service builds*. The service running in production is still the old image until it is rebuilt and rolled out. If the point of the monthly line is patch currency, the metric has to be the age of the base layer in what is *deployed*, not what is committed. That usually means the automation ends in a deploy, or that services rebuild and redeploy on a cadence of their own. ## The breakage budget A monthly forced upgrade is a monthly opportunity to break several hundred builds, and the goodwill you spend is finite. Three things keep it affordable. Keep the image line boring: a stable interface — the same paths, the same user, the same entrypoint conventions — so a patch rebuild is genuinely a patch. Separate the cadence: routine patch rebuilds flow automatically, while a change that moves a major runtime version gets its own announced track with a longer window. And publish what changed each time, so a team whose tests fail can tell in a minute whether the cause is theirs or yours. If teams learn that the monthly bump is safe, they stop reviewing it carefully — which is fine, because that is the outcome you wanted. ## What to say about the tradeoff The honest framing is that immutability of a reference and currency of its content are in permanent tension, and you resolve it not by loosening the pin but by owning the movement of the pin. A floating tag looks like a shortcut, and it does deliver patches automatically, but it also means the content of a build changes without a recorded decision and the same build cannot be reproduced later. Most estates land on pinned digests plus aggressive, cheap, automated movement — with the staleness failure as the backstop for the repositories where the automation is ignored.