Container Image Strategy
also called Base Image Policy, Golden Image
The organisational decision about where images come from, what they are built on, and how a base layer fix reaches everything already deployed.
An estate that lets every team choose its own base image has, in practice, chosen to be unable to respond to a base-layer vulnerability, because the response requires locating and rebuilding an unknown number of images built on unknown foundations by teams with other priorities.
A workable strategy has four parts: a small set of approved base images maintained centrally and patched on a schedule; provenance enforced at admission so only images from the internal registry with a valid signature can run; rebuild automation so a base image update triggers downstream rebuilds without each team acting; and currency telemetry showing which running workloads are on stale bases, since the security question is about what is running, not what is in the registry.
Image size is the trade people argue about most and it matters least, though minimal and distroless bases genuinely reduce both attack surface and the volume of irrelevant vulnerability findings that exhaust teams. The harder trade is between a rich base image that includes the organisation's agents and conventions, and a minimal one that makes debugging painful because there is no shell inside the container when you need one.