Our Python, Node, and JVM containers pick up hundreds of findings from their base images, including some high-severity ones. We use standard runtime images and add a few debugging tools.
What helps reduce inherited vulnerabilities before deployment? Is it better to slim down images ourselves, standardize on minimal bases, or use a managed catalog?
A general-purpose image brings along a lot more than your app needs. Every library and utility is another package that can show up in a scan. The debugging tools you add can contribute too.
Try a multi-stage build: compile or install dependencies in a fuller image, then copy only the runtime artifacts into a minimal or distroless final image. Alpine is another option, though check that your runtime and dependencies work with it. For a suitable self-contained binary, a scratch image can be an option as well.
Less in the image usually means less to patch and triage, but it doesn't make the application or its dependencies automatically safe.
I'd standardize on a small set of maintained bases for the runtimes you actually use. Rebuild application images when those bases get security updates, scan the rebuilt images, and roll them out. Just changing the base once won't keep deployed containers patched.
Pinning a base by digest gives you a known input, but it also means you need a deliberate process to update that digest. Pulling package upgrades during every build can pick up fixes sooner, but builds become less reproducible and updates can introduce breakage.
g.31+tramline:
That distinction helps. A pinned image gives us a stable starting point, not a patching schedule.
Don't treat the raw CVE count as the whole story. Check the affected package, severity, whether a fix is available, and the distro's advisory for the version you actually have. Some findings may be disputed, marked as not requiring a fix, or reported incorrectly by a scanner.
That doesn't mean dismissing the high-severity tail. Start there, verify which findings apply, and update or replace the affected packages where fixes exist.
Hardened image catalogs are worth evaluating if maintaining your own bases sounds like a distraction. There are options from Docker, Red Hat, and Chainguard, as well as distroless images and Wolfi-based options. Compare the runtime support, update cadence, licensing, cost, and how you consume updates before choosing.
Be skeptical of a permanent zero-CVE promise. New vulnerabilities get disclosed and patches take time to reach an image, so you'll still need to monitor and rebuild.
7q!portshift_368:
Also check which images and features are covered by the current terms. A free option today isn't necessarily a guarantee about future pricing.
Building an internal base on top of a maintained upstream can make sense if you need shared configuration and controls across teams. You own the work though: keeping packages current, testing changes, and getting updated bases into application builds. A managed catalog shifts some of that maintenance to a supplier, but doesn't remove the need to update your own images.
Answers are reviewed before publication.
Fexwick.9:
Distroless can make interactive debugging less convenient, so plan how you'll troubleshoot without relying on tools inside the production image.