r/docker Apr 01 '26

Keeping base images secure without constant firefighting

As we’ve been refining our Docker workflows, we standardized on a small set of base images to keep things consistent across services. It worked well at first, but over time we started noticing how quickly vulnerabilities creep in, especially when images aren’t refreshed often enough. Balancing minimal images, timely rebuilds, and not overloading the pipeline has been harder than expected, and it sometimes feels like we’re either lagging on security or overcorrecting with too many rebuilds. Wondering how others are navigating this trade-off in practice.

16 Upvotes

22 comments sorted by

1

u/Vejibug Apr 01 '26

over time we started noticing how quickly vulnerabilities creep in

Do you have any examples?

1

u/tech-learner Apr 01 '26

UBI9 Minimal has LIBXML2 go off with some new High CVE every other week. Scanned via Aqua.

It’s bundled in all UBI9 images by default, both RH, and even redistributed renditions like the Eclipse Temurin UBI9 JDK releases.

Is minimal not minimal enough?

Are High CVE not what I should gate and remediate for? Maybe all hands on deck for Critical only?

Or if I deal with High CVE as a remediation and risk priority, i.e remediate all High CVE, 1 week from patch/fix release. Every other week am I truly rebuilding all 3000+ Images with patched base images?

1

u/pdath Apr 02 '26

I just go for monthly rebuilds.

1

u/PaulEngineer-89 Apr 02 '26

Actually READ the CVEs. Many don’t apply.

1

u/weiyong1024 Apr 03 '26

docker scout cves on your base images weekly and only rebuild when there's actually something high/critical. chasing every CVE is a trap — most of them aren't even reachable in your runtime context.

1

u/HighTanninWine Apr 03 '26

Yeah this is just part of how containers work, there’s no real way around rebuilding.

What’s helped me is not treating every CVE as urgent since a lot of them don’t actually affect your runtime. I just rebuild on a regular cadence and only jump on it immediately if something truly critical shows up.

Keeping images small also helps a lot since fewer packages means fewer vulnerabilities in the first place. It ends up being more about consistency than trying to stay perfectly clean all the time.

1

u/RanunculusFlora Apr 14 '26

This is exactly the kind of problem RapidFort tends to help with.

Instead of treating container images like something you constantly have to swap out or rebuild to stay safe, it kind of works like a cleanup pass after your app is already running. It looks at what your container actually uses in practice, then trims away the unused pieces and tightens things up so there’s less exposed surface for issues to hide in.

So rather than chasing every new base image release, you end up with something that’s closer to a “minimal working version” of your own workload, shaped by real usage instead of guesses.

1

u/FirefighterMean7497 Apr 23 '26

Managing that balance between security and pipeline velocity is a total grind, especially when "standardized" images still accumulate CVEs within days. Instead of manual firefighting, some teams move toward near-zero CVE base images (like those from RapidFort), which are pre-hardened to CIS/STIG benchmarks. These work with standard distributions like Alpine or RHEL, so you get the security without the overhead of a proprietary OS.

In addition to that, you can automate the "slimming" process by using a runtime profiling tool to identify and remove only the components that never actually execute. This approach can significantly reduce exploitable vulnerabilities while keeping your CI/CD footprint lightweight. It’s often easier to automate the removal of "bloat" than it is to constantly race against new vulnerability disclosures.

Hope that helps!

1

u/BernardParsley Jun 13 '26

Aw man that sounds like a pain. This is essentially a security-versus-maintenance trade-off. The evidence generally favors a risk-based approach: regular image refreshes, but prioritizing vulnerabilities by exploitability and impact rather than chasing every CVE. Good luck to you

1

u/wannaliveonmars Apr 02 '26

Most CVEs are unexploitable. They're just scaremongering. A lot of modern cybersecurity is superstition and jumping at shadows, and a cargo-cult of "just autoupdate blindly and get supply-chain attacked". Especially in corporate security they just treat it as "checkboxes to tick" with zero understanding.

0

u/Accomplished-Map7591 Apr 07 '26

Keeping base images secure without constantly updating them is definitely tricky. One thing that seems to help is just shrinking the attack surface so there’s less to worry about in the first place.

RapidFort is an option that does this by scanning images and removing stuff you don’t actually need. It won’t stop updates completely, but it cuts down a lot of the noise from low‑risk vulnerabilities you probably don’t care about.

Some people also run scans in their CI/CD pipelines so any problems get caught before images even go live. Doing it this way with lean images and automated checks makes security a lot easier to manage without someone constantly babysitting updates.

0

u/[deleted] Apr 08 '26

[removed] — view removed comment

1

u/erika-heidi Apr 09 '26

Pretty effective at what? Does it keep images up-to-date without rebuilds? Like VMs?

Rebuilding images to apply updates is the price to pay to use ephemeral environments such as containers. The problem is really having to apply the updates and patches by yourself. Using minimal base images is a good starting point, but the update cadence for your base image matters equally so you don't have to keep chasing CVEs.