How do you secure container images?

Containers feel disposable, so teams under-invest in image security — but a vulnerable or poisoned image runs everywhere it's deployed. The interview wants a layered approach, not one trick.

Build a small, clean image

• Minimal base images. A distroless or slim base strips out shells, package managers, and unused libraries. Fewer packages means less attack surface and far less scanner noise — most CVEs come from OS packages you never use.
• No secrets in layers. Anything COPY'd or set as a build arg persists in the layer history even if removed later; fetch secrets at runtime instead.
• Run as non-root. Set a USER so a container escape doesn't start with root-equivalent rights, and combine with read-only filesystems and dropped capabilities.

Verify and gate

• Scan in CI and in the registry. Tools like Trivy or Grype detect known CVEs in both OS packages and language dependencies. Fail the build on critical findings, and re-scan in the registry because new CVEs are disclosed after build time.
• Pin by digest, not floating tags. :latest is non-deterministic; a digest pin guarantees you run exactly what you scanned.
• Sign and enforce. Sign images (Sigstore/cosign) and use admission control (e.g. an OPA/Kyverno policy or signature verification) so the cluster only runs scanned, signed images.

Keep it fresh

A CVE patched in the base image only helps if you rebuild and redeploy. Automate periodic rebuilds so upstream fixes flow into running workloads.

What interviewers look for

Naming minimal base images and scanning first, then non-root, signing plus admission control, and the operational point that images must be rebuilt to inherit patches.