How would you reduce the attack surface of a container image you're shipping to production?

technical-conceptual · Junior level · cloud-devops-security

What the interviewer is really asking

Check whether the candidate knows the practical image-hardening levers — minimal/distroless base images, vulnerability scanning in CI, pinned and trusted base images, no secrets or build tooling in the final image — rather than treating the image as just a package format.

What to say

• Start with the base image: the fewer packages, the fewer vulnerabilities and the smaller the attack surface. Use a minimal or distroless base (or even scratch for a static binary) so there's no shell, package manager, or extra libraries for an attacker to use after a compromise.
• Scan for known vulnerabilities in CI: run a scanner like Trivy on every build so CVEs in your dependencies and OS packages fail the pipeline before the image ships, and re-scan periodically because new CVEs are disclosed against images you already built.
• Keep secrets and build-time junk out of the final image: use a multi-stage build so compilers and dev dependencies stay in the builder stage and never reach production, never bake credentials into a layer (they persist in image history even if deleted later), and pin the base image to a specific digest from a trusted registry rather than a floating 'latest' tag.

What to avoid

• Thinking a smaller image is only about faster pulls and disk usage — the bigger reason is fewer installed packages means fewer vulnerabilities and fewer tools an attacker can pivot with.
• Baking secrets into the image and assuming a later RUN rm removes them — they remain in the earlier layer's history and are extractable.
• Scanning once at build and never again, or skipping scanning entirely because 'the base image is official'.

Example answers

Strong: I moved our Go service from a full Debian base to a distroless image and a multi-stage build: the builder stage compiled the binary, and the final stage was a minimal runtime with no shell or package manager. That alone dropped the Trivy CVE count dramatically, and there was no /bin/sh for an attacker to drop into if they got code execution.

Weak: I'd use the standard ubuntu:latest base and install whatever I need; the image being a bit big is fine, it just takes longer to download.