Distroless Images - Cut Container CVEs to Zero

A recruiter or hiring panel wants to know if you can reduce container attack surface without committing your team to an endless patch-and-rebuild cycle. This question comes up because "just patch the base image" is the answer most candidates give, and it doesn't scale once you have hundreds of images to track.

The answer interviewers want

Stop shipping containers with a full OS inside. Most CVEs in container scans come from OS packages you never actually use: package managers, shells, libc utilities, debugging tools. Distroless images strip everything except your app and its runtime dependencies. No OS, no shell, nothing for an attacker to exploit even if they get code execution.

In practice: multi-stage build your app, then copy just the compiled binary into a gcr.io/distroless base image. Scan the result with trivy or grype to confirm the CVE count actually drops.

The thing most people miss: no shell means no kubectl exec -it pod -- bash. If you need to inspect a running distroless container, use kubectl debug with an ephemeral container instead. That attaches a separate debug container with a shell and tools to the same pod's namespaces, without adding a shell to your production image.

The one-line answer that ends the CVE patching treadmill: ship distroless, not another full OS image.

Why interviewers ask this

They're checking whether you think about attack surface reduction as a design decision, not just a patching chore. Anyone can say "run a scanner and fix what it finds." Fewer candidates can explain why removing the OS layer changes the problem entirely, and even fewer know the operational tradeoff: you lose your usual debugging shell and need a different workflow for it.

Follow-ups to expect

How do you debug a distroless container when something breaks in production? Use kubectl debug to attach an ephemeral container with a shell and tooling to the same pod, since the production container itself has no shell to exec into.

Does this fit into your CI pipeline, or is it a one-off build step? The multi-stage build and the trivy/grype scan both belong in CI, so the distroless image is built and verified on every change, not assembled manually.

What do you lose by going distroless? You lose the convenience of a shell and OS tools inside the running container, which is exactly the tradeoff that removes the attack surface in the first place.

The common wrong answer

Most candidates describe a patching process: pin base image versions, run Dependabot or Renovate, rebuild on a schedule, re-scan, repeat. That's a reasonable hygiene practice, but it doesn't answer the question. It keeps you on a permanent treadmill chasing CVEs in OS packages your app never calls. The stronger answer removes the OS layer entirely so there's far less to patch and far less for a scanner to flag, and it pairs that with a real plan for debugging without a shell, which is the part people forget to mention.