Container Image Hardening: Reducing Your CVE Surface by 80%

The Base Image Problem

A standard ubuntu:22.04 base image ships with hundreds of packages that a typical application never touches: package managers, shell utilities, network diagnostic tools, text editors, and locale data. Every one of those packages is a potential CVE surface. When a scanner reports 150 CVEs in your container image, the majority are almost never in your application code — they are in the bash binary, the curl library, or the Python interpreter that was pulled in because the build stage needed it and no one remembered to strip it from the final image.

Distroless Images

Google's distroless images and Chainguard's hardened images take the opposite approach: include only the runtime the application requires, with no shell, no package manager, and no general-purpose utilities. A Java application deployed on gcr.io/distroless/java17-debian12 contains the JRE and its direct dependencies — nothing else. The CVE surface drops proportionally. In OSSeva's scanning data, migrating a typical Java microservice from eclipse-temurin:17-jdk to the equivalent distroless image reduces the reported high-and-critical CVE count by 75–85%.

Hardening Checklist

• Use multi-stage builds: compile and test in a full image, copy only the output artifact to a minimal final image.
• Run as a non-root user: add a USER directive and create a dedicated application user in the Dockerfile.
• Drop all Linux capabilities and add back only what the application requires using --cap-drop=ALL --cap-add=NET_BIND_SERVICE (or equivalent in pod security context).
• Set the filesystem to read-only where possible: --read-only flag or readOnlyRootFilesystem: true in Kubernetes.
• Pin base image digests, not just tags, to prevent silent updates from introducing new vulnerabilities between builds.
• Scan the final image — not the build stage — before pushing to the registry.

Automated Rebuild Pipelines

Hardened images decay over time as upstream base images receive security updates that your images do not inherit. An automated rebuild pipeline subscribes to base image update notifications and triggers a rebuild-and-scan-and-push cycle whenever the base image digest changes. This keeps your production images current without requiring manual intervention for each upstream patch.

OSSeva Patch Integration

OSSeva's Patch service monitors your container registries for images with known-vulnerable base image digests and initiates the rebuild pipeline automatically when the policy threshold is exceeded. The result is a continuous patching posture that keeps critical and high CVEs out of production images without creating toil for engineering teams.

Conclusion

Container image hardening is one of the highest-leverage security investments available to platform engineering teams. The combination of distroless base images, multi-stage builds, and automated rebuild pipelines eliminates the majority of reported CVEs and reduces the ongoing operational burden of vulnerability management. The remaining CVEs — those actually in your application's direct dependencies — are the ones that warrant detailed engineering attention.