A shared build pins its base image by digest and nobody owns moving that pin — how do you resolve integrity versus freshness?

## What a digest pin actually promises Pinning a base image to a content digest gives you one thing precisely: the bits you build on are the bits whose hash you recorded. Nobody upstream can move a name to different content, and two builds a year apart start from the identical foundation. That closes a real attack — a trusted name silently republished with hostile content — and it makes your build inputs auditable. It promises nothing at all about whether those bits are still worth trusting. A digest is immutable by construction, which means it can never be updated in place; the layer that was current when you pinned it is exactly as old today as the day you pinned it, and every advisory published since applies to it untouched. ## The obligation transfer nobody writes down This is the insight the question is really testing. Before pinning, freshness was **implicit and accidental**: a floating reference re-resolved and you got whatever the publisher last pushed, including patches, including regressions, including anything malicious. After pinning, freshness is **explicit and owned**: it happens only when a person changes a digest string, tests it, and merges it. That is a strictly better model — you traded an unreviewed automatic change for a reviewed deliberate one — but only if the second half exists. In a shared enterprise build where the pin lives in a template that many teams consume and no single team feels responsible for, the second half quietly does not exist. Twelve months later the pin is doing its integrity job perfectly while holding an operating-system layer with a year of unpatched advisories in place across the fleet, and every consuming team assumes someone else owns it. **The failure is not the pin. It is a control that created an obligation without creating an owner.** ## Making the obligation real Four moves, in order of how often they get skipped: **1. Name the owner, and pick one who can act.** A pin that many teams consume should be moved by whoever can test the move — typically the platform group that maintains the shared build — not by each consumer independently, which produces either divergence or paralysis. If the pin genuinely belongs to a product team, say so in the same place the pin lives. **2. Make staleness visible and gated.** Pin age is a first-class signal: the build should be able to tell you that its base digest is N days old, and there should be a threshold at which that becomes a failure rather than a line in a log. Staleness that only shows up in a report nobody reads is indistinguishable from no control at all. **3. Automate the proposal, keep the decision human.** Tooling that opens a change proposing the new digest turns the work from *discovering* that an update exists into *reviewing* one. The human still decides; they no longer have to notice. **4. Record what the pin was assessed against.** Keeping the assessment attached to the digest — what was in it, what was accepted — means moving the pin is a small delta rather than a fresh investigation, which is the difference between a monthly habit and an annual project. ## The trades a principal has to own - **Pin age versus change risk.** Every base move can break something, and a fleet-wide base move can break many things at once. The organisation that never moves is exposed; the one that moves on every publish absorbs constant regression risk. A stated age budget makes that trade explicit instead of resolving it by neglect. - **Central pin versus per-team pin.** One pin for everyone gives you a single lever and a single blast radius; per-team pins give isolation and guarantee drift. Both are defensible; leaving it undecided is not. - **Who eats the regression.** If the platform team moves the pin and a product team's service breaks, the response to that incident determines whether the pin ever moves again. If the first bad move gets punished, you have re-created the frozen pin with extra steps. - **Unpinning is not the fix.** The tempting response to a year-stale pin is to float the reference again so updates arrive automatically. That trades away integrity to solve an accountability problem, and it reintroduces exactly the silent-republish exposure the pin existed to close. ## How to answer Say first what the pin did and did not promise, in one sentence each, so the interviewer knows you have the direction right. Then name the transfer of obligation as the actual mechanism of the failure. Then give the organisational fix — owner, visible age, automated proposal, retained assessment — and finish with the trade you would be prepared to defend to leadership: an explicit maximum pin age, accepted alongside the regression risk that comes with meeting it.