A platform must define a container image strategy for many teams. What decisions matter, and what is the security constraint?

The decisions

1. Curated base images, maintained by the platform. A small set — one per language runtime — patched centrally, so a vulnerability fix reaches everything through a rebuild rather than through each team updating independently. This is the single highest-value decision.

2. Minimal images. Every package is attack surface and every megabyte is multiplied by pull count. Multi-stage builds discarding toolchains, and base images without shells or package managers where the workload permits.

3. Layer ordering stable-to-volatile — base, system packages, dependency manifests, dependency installation, source. Getting this backwards means every source change re-resolves dependencies, which is the most expensive common mistake in CI.

4. Pinned by digest, not by tag. Tags move; digests do not. Mutable tags are the source of "it worked yesterday", and pinning is what makes builds reproducible.

5. A rebuild cadence, so images are refreshed with patches even when application code has not changed. Without it, a service that has not been deployed for six months is running six months of unpatched base image.

6. Provenance and scanning in the pipeline, with results attached to the image and verified at deployment.

The security constraint

Build containers execute semi-trusted code. For a platform running builds — particularly with external contributions — ordinary container isolation is insufficient, because containers share a host kernel and kernel escapes are a real category.

That requires either stronger isolation (lightweight virtual machines, sandboxed runtimes) or strict egress control and short-lived narrowly-scoped credentials. And critically, a build container must never hold a credential that outlives it or reaches beyond its own job — most serious CI breaches are credential-scope failures rather than escapes.

The trade-off to state

Curated base images centralise both the benefit and the risk. A vulnerability in the base image affects everything, and the platform team becomes responsible for patching the fleet. That is the correct trade — a central team patching once beats every team patching individually — but it makes the rebuild-and-redeploy pipeline a security-critical capability rather than a convenience.