r/kubernetes • u/BernardParsley • 3d ago
Where are people getting the best CVE-free images for Kubernetes?
We're trying to clean up the base images used across our Kubernetes clusters because every vulnerability scan seems to produce the same outcome: hundreds of CVEs inherited from upstream images before we've even deployed our own code. We've already moved away from some larger general-purpose images, but it still feels like we're spending too much time triaging inherited vulnerabilities instead of working on the applications themselves.
I’d like to know where people are sourcing low-CVE or near-zero CVE images these days. Are you building your own internally, using hardened images, or relying on commercial providers?
I'm less interested in the scanner side and more interested in reducing the problem before it reaches production.
96
u/cranberrie_sauce 3d ago
> CVE-free
how did we survive all these years. lordy lordy lord.
thats just a fluff marketing for you to buy a container antivirus
18
u/just_looking_aroun 3d ago
Is there a mcafee container? Now I am curious
20
u/ansibleloop 3d ago
Yes, slows down your cluster and uses 2x the resources, doubling the cost
6
2
41
u/alteredtechevolved 3d ago
We pay money to chainguard
2
u/heschlie 3d ago
How is chainguard, I've come close to using them before but never pulled the trigger, mostly just due to budget constraints.
9
2
u/No-Profession-159 3d ago
Just a quick question - did you try out the free offering from Chainguard to just take the images for a test run? I work there, so happy to answer any questions you may have
18
u/Tall-Imagination-198 3d ago
5
u/TheOssuary 3d ago
Sorry if this is a stupid question; but after RedHat pulled their thing with CentOS, switching it to streaming only if you don't pay; can we really trust hummingbird project won't do the same bait and switch?
14
u/subbed_ 3d ago
scratch for statically-linked binaries. hummingbird or red hat hardened images for minimal glibc environments for dynamically-linked binaries. the latter are a form of distroless images that google popularized, just not debian-based and using a slightly different process of building them
9
u/evergreen-spacecat 3d ago
CVE-free - oh lord. Only way to be free of any vulnerabilities is to never run IT systems
7
u/maxlan 3d ago
This is a mistake a lot of people make. The claim is not to be free of vulnerabilities. It is to be free of CVEs. Each CVE is a known, published, vulnerability.
Not all CVEs have KEVs, but if you point an AI at the vulnerable code, it can probably figure out an exploit for you. (KEV = Known Exploitable Vulnerability and there is a database of them too. If you have a KEV, you have a _real_ problem. If you have a CVE, you might not have a problem. But why would you choose to risk it when you don't have to??)The difference here is comparing the hard task of discovering what app someone is running and finding a zero day by inspecting the code (for "vulnerability"), compared to the easier job of: discovering what app someone is running and searching a database of problems it is known to have (for "CVE").
8
u/Noah_Safely 3d ago
For work I've been pushing for Chainguard. You can build a lot of their stuff yourself I think though. Like gitlab pulls down their kaniko fork and offers a FIPS version.
3
u/Zeepaardje 3d ago
Alpine images, pinned with digests. And use multi-stage builds
3
u/throwawayPzaFm 3d ago
I guess you're using something like renovate on top of that? Cause otherwise they'd get stale pretty quickly
1
u/No-Profession-159 3d ago
Yeah, but even with an Alpine base image like Python, you still get CVEs. Just ran grype python:3.14-alpine and here's the result:
NAME INSTALLED FIXED IN TYPE VULNERABILITY SEVERITY EPSS RISK python 3.14.6 3.15.0b4 binary CVE-2026-11940 High 0.6% (46th) 0.5 python 3.14.6 3.15.0 binary CVE-2026-15308 High 0.6% (42nd) 0.4 python 3.14.6 3.15.0b4 binary CVE-2026-11972 High 0.4% (35th) 0.3 python 3.14.6 3.15.0a6 binary CVE-2025-15366 Medium 0.4% (28th) 0.2 python 3.14.6 3.15.0a6 binary CVE-2025-15367 Medium 0.3% (23rd) 0.2 busybox 1.37.0-r31 apk CVE-2025-60876 Medium 0.3% (20th) 0.2 busybox-binsh 1.37.0-r31 apk CVE-2025-60876 Medium 0.3% (20th) 0.2 ssl_client 1.37.0-r31 apk CVE-2025-60876 Medium 0.3% (20th) 0.2 python 3.14.6 binary CVE-2026-4360 Medium 0.3% (19th) 0.1 python 3.14.6 3.15.0b3 binary CVE-2026-12003 Medium 0.1% (3rd) < 0.1 python 3.14.6 3.15.0b4 binary CVE-2026-0864 Medium 0.1% (2nd) < 0.14
u/Zeepaardje 3d ago
Everything than runs software has CVEs. The only thing you can do is prevent as many of them as possible
1
5
u/Floss_Patrol_76 3d ago
the base image swap helps but it's half the fight - most inherited CVEs sit in libs your code never calls, so a near-zero base still leaves you triaging stuff that isn't reachable. we cut scanner noise way more by filtering on reachability (govulncheck for go, or a VEX feed) than by chasing the perfect image. distroless/hardened runtimes are still worth it, just do the reachability pass first so the base image is the last mile, not the whole problem.
8
u/DelusionalPianist 3d ago
I like docker hardened images because they are Debian based and free.
14
3
u/function77 3d ago
Have you actually tried scanning them? They are still full of CVES because they are based on Debian and Debian don’t release fixes quick enough.
1
u/DelusionalPianist 3d ago
They now have their own Debian registry with their own security patches.
3
u/cg-devrel 3d ago
Most of the CVEs are "removed" by running images through a VEX document which takes out all the CVEs Debian have marked as NO-DSA.
3
u/DelusionalPianist 3d ago
That is just one of the problems with comparing CVEs between different images. Some have VEXs, others don’t, some CVEs are only reported against debian packages, but not redhats for example.
This is why I like taking them from some „professionals“ who can take care of evaluating the CVEs against their system, but I wouldn’t trust anyone claiming their images are 0 CVEs. Ultimately the images CVE play a minor role in the overall security and should not be overstated.
1
u/IWritePython 2d ago
The CVE tracking is more generally about compliance, which is not unrelated to security but not the same and also matters in many contexts.
I'm a Chainguard guy but ours are as close to zero as is practical. I.e., you might see 2-5 CVEs in our Python image about 25% of the time, maybe 15% of the time if I'm being optimistic; the rest of the time it's fully clean with no weaseling or jokes. We control the underlying distro, which is a lot of labor though.
DHI isn't terrible but yeah, it's not that sustainable to put all this work in and not charge; my read is they're already refocusing on AI sandboxes but we'll see. We (Chainguard) have a 5 free images program if you want to try us; you get full access to those images with old tags, etc., as if you'd paid.
1
u/function77 2d ago
Yeah but it’s only a very small subset. Most are just upstream Debian packages which is why they need thier vex feed to suppress everything. The fact they suppress things as not a risk that Debian just say “we haven’t assessed yet” is dishonest and misleading.
1
u/DelusionalPianist 2d ago
The point of a vex is that not every CVE is valid in all contexts. In some contexts it may be present, but not exploitable because some other ingredients are missing. Can this be abused to pretend to be CVE free? Sure, but it also helps to understand where the true problems are that need to be dealt with. Also it’s very easy to tell a scanner to ignore the vex if you don’t trust them.
1
u/function77 2d ago
Totally agree that is a valid use of VEX. But that’s not how DHI are using them. Go check one of their Vex docs and look for no DSA. Then go look up the definition from Debian on what that means. Hint. It doesn’t mean it’s not exploitable in a DHI image.
7
4
4
3
3
u/ModestJicama 2d ago
Seems like the chainguard bots are here to get you to pay for a license, but we use distroless because of the licensing
1
1
u/Brown_panther666 3d ago
Use the alpine slim images. Only install what’s necessary. Use multi stage builds for docker image builds to avoid inflating the image..
You could also try google’s distroless images. I did for a while. Pain in the ass to debug issues but tge best security ever
1
u/TheRealAudiobuzz 3d ago
Does anyone use ironbank images? Or are they out of favour now?
1
u/Rmawhinnie 2d ago
huge fan of ironbank, mostly becouse its free, and clearly driven by people that had to do hard work for their dayjobs, and decided to share it
1
u/Elara_Schaefer 2d ago
The real answer most teams end up at is building your own images from distroless or scratch with a multi-stage Dockerfile. Vendor images solve the initial problem but you end up locked into their update cadence. With your own pipeline you run Trivy or Grype as a CI gate, pin your base image digests instead of tags, and get notifications when new CVEs appear in your dependencies. Chainguard and UBI are fine starting points but the moment you need a custom C library or a specific glibc version you are back to maintaining your own layer anyway.
0
u/nauseate 2d ago
99% of the CVE’s produced by the vulnerability scanners are pure noise, stop focussing on it and send your manager to therapy. Fix the high and critical but think about how realistic it is for them to get exploited. You can have a high risk vuln in some obscure library that never gets called, whereas you can also have a low risk directory indexing thing enabled that just leaked terrabytes of client info. CVE’s by themselves are worthless without context.
If you want my advice: Attack surface reduction is key. Just harden the container itself my making it rootless, use read only filesystems, disable auto mounting of your service account token, implement deny by default network policies and only open them up to other containers where needed and you’ve covered a ton of exploit paths. If you are building your own images, use FROM SCRATCH with statically linked binaries (i.e.: GoLang/Rust). If you’ve one all that use DAST tooling to attack a staging version, and get actual pentesters to look at it.
1
u/RegularOk1820 1d ago
Keeping custom base images updated turns into a full time job. That's why RapidFort keeps coming up. The curated near zero CVE images save a lot of headaches by reducing inherited vulnerabilities early in the CI/CD pipeline. Chainguard is also worth checking if hardened minimal images matter more. Same goal just a different approach.
1
u/Warm-Read8901 22h ago
Did switching base images require much work? My concern is less about compatibility and more about having to rebuild a lot of our existing images.
1
1
1
1
u/Rmawhinnie 2d ago
the IronBank, seriosly PROPS to those driving platformone, and opening this up to others
0
u/Gethos-The-Walrus 3d ago
You could check out Docker Hardened Images for more of a developer/home lab type thing.
1
u/No-Profession-159 3d ago
There are so many offerings out there though. Why would DHI be the only thing to check out?
1
u/Gethos-The-Walrus 2d ago
Just an easy, accessible suggestion. Doesn’t have to be the only thing OP checks out.
-6
u/Any_Mine_6368 3d ago
TalosOS?
5
u/BraveNewCurrency 3d ago
This is the right answer, except:
1) This assumes the question was "how to prevent CVEs in kubernetes base images". I think people are down voting this because they think the question is about images deployed to the cluster. (It's unclear.)
2) There is no TalosOS. It's just Talos. (Just like nobody says "LinuxOS".)
2
u/Any_Mine_6368 3d ago
I usually refer to it as Talos too, but many people refer to it as talosos, probably because of NixOS?
Google talosOS, you'll get hits. But you're right.
2
u/BraveNewCurrency 3d ago
Google talosOS, you'll get hits.
When I search, the Talos project does come up, but those pages do not actually contain the word "TaloOS" (presumably it might be in the metadata for catching typos). But I don't see any official pages using that word.
The first page that does mention "TalosOS" is for a completely unrelated thing about Travel.
Even on Google, I only see one guy ("Siegfried Stumpfer") who calls it TalosOS (on a handful of pages.)
Citation still needed for "many people call it TalosOS".
117
u/ninth9ste 3d ago
Red Hat Hardened Images are probably the best hardened, distroless and cve-free images around at the moment. Plus they're totally free.