CVE patching in Kubernetes: fix versions, base images, and what "fixed" means

On a server you patch a CVE with apt-get upgrade. In Kubernetes that does not stick: anything you change inside a running container is gone at the next restart. The fix for a CVE in a pod is always a new image. If you build the image, that means rebuilding it on a newer base or bumping a dependency. If someone else builds it, you bump the chart or the image tag. Then you roll it out and confirm that the digest the kubelet runs actually changed.

The hard parts come after that: the "fixed in" version depends on who packaged the software, "no fix available" covers four different situations, and the order you work in decides whether the list gets shorter. This post covers each one, and ends with a playbook.

The unit of fix is the image, deployed by something

A finding lives in an image: a specific digest that contains a specific package version. That image runs because something deployed it, such as a Helm release pinning a chart version, an Argo CD application pointing at a Git path, or a Deployment someone applied by hand. So every fix has two halves, and scanners tend to forget the second:

1. Produce an image without the vulnerable package version. Rebuild your own on a newer base. For someone else's, find the tag that has the fix.
2. Change the thing that deploys it (a chart bump, a values change, a Git commit) so the new digest is what the kubelet runs.

Many of the images in a typical cluster are third-party: ingress controllers, cert-manager, monitoring agents, CSI drivers, the service mesh. For those, a list of CVEs is not actionable, but a chart version is. That is why StackRadar attributes every finding to the Helm release or Argo CD application that deployed it. The guidance on a release page reads "upgrade cert-manager from v1.15.3 to v1.16.2", not "libcurl in 14 images".

What "fixed in" means: backports change the version numbers

An advisory says a vulnerability is fixed in some version. Which version depends on the ecosystem, and comparing across ecosystems is the most common way to get the wrong answer.

Here is what goes wrong. A scanner that compares your Debian openssl 3.0.15-1~deb12u1 against upstream's "fixed in 3.3.2" reports a vulnerability that Debian fixed months ago:

Good matchers check distro packages against the distro's own security data. That is why the package URL carries the distro (pkg:deb/debian/openssl@3.0.15-1~deb12u1?distro=debian-12), and why version-range evaluation has to understand Debian's epoch-and-tilde ordering, RPM's release field and Alpine's -rN. When two scanners disagree about a distro package, this is nearly always the reason.

"No fix available" and "won't fix"

Many findings on a Debian- or Ubuntu-based image have no fixed version. Four different situations hide behind that, and each needs a different response:

• Not yet. The advisory is new and the distro has not shipped a backport (Debian shows it as unfixed, Ubuntu as needed or needs-triage). Serious issues are often fixed within days, while low-priority ones can wait much longer. Track it, and mitigate in the meantime if it is being exploited.
• Deliberately not. The distro has decided the issue does not justify an update. In Debian it is <no-dsa>, typically with the note "Minor issue". That means no advisory, though a fix may still arrive in a point release, and the sub-states <postponed> and <ignored> tell you which way it is leaning. Ubuntu marks such issues deferred or ignored, often with priority negligible. Red Hat uses "Will not fix": the product is affected, but no fix is planned. The finding is real, and upgrading will not fix it.
• End of life. The release line gets no security fixes at all, so every future CVE in it will show as "no fix". Debian 11 is the current example: its LTS ended on 31 August 2026. Debian tags packages it has stopped supporting <end-of-life>, and Red Hat's "Out of support scope" means the product's lifecycle phase no longer covers issues of that severity. The same happens to charts: ingress-nginx was retired in March 2026 and will not get another release. The only remedy is to migrate, which is a bigger piece of work than a tag bump. StackRadar labels these findings as an end-of-life base rather than as waiting for a fix, and it never marks a release line EOL when it cannot tell.
• Not affected. The distro says the vulnerable code is not in its build (Debian <not-affected>, Ubuntu not-affected, Red Hat "Not affected"). No action is needed. If your scanner still reports it, you are looking at the upstream-versus-distro mismatch from the previous section.

For the deliberately-not class you have three honest options. You can move to a base image that ships the fix (Alpine, distroless or a Wolfi-based image often does), you can mitigate it (for example, by turning off the vulnerable feature), or you can record an accepted risk with an owner, a reason and an expiry so that someone revisits it. Suppressing a finding without an expiry is how a cluster ends up with three-year-old "temporary" exceptions.

Base images do most of the work

On an application image built on a full distro base, most findings are usually in the OS layer, and none of them is fixed by changing your code. They are fixed by rebuilding on a newer base, and three practices make that cheap:

1. Pin the base by digest and automate the bump. Write FROM debian:12-slim@sha256:… and let Renovate or Dependabot open a pull request when the tag moves. Each fix then arrives as a reviewed one-line change, and builds stay reproducible.
2. Rebuild images nobody is touching. A digest bump only helps an image that gets rebuilt, and an image built six months ago carries six months of unpatched OS packages. Rebuild and redeploy every image when its base bump merges, or at least weekly, even when its code has not changed.
3. Use a smaller base. Fewer packages means fewer findings and fewer "won't fix" rows. Distroless, Alpine, Wolfi-based and UBI-micro images ship a fraction of the packages of a full Debian or Ubuntu base. You give up debuggability, and with Alpine you also switch to musl.

# Pinned by digest; Renovate bumps the digest when a new 12-slim is published.
FROM debian:12-slim@sha256:<digest-of-the-current-12-slim>
# No apt-get upgrade here: the fix comes as a base-image bump, not a build-day surprise.
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates \
 && rm -rf /var/lib/apt/lists/*

Before merging a bump, check that it clears what you expect. The free stackradar scan CLI needs no account. It scans a candidate image locally with your Docker credentials and folds the base-image findings into one line. For images you build, StackRadar also checks your base every night against its current tag and the newest tag of the same variant, and tells you which rebuild removes more findings.

stackradar scan --image registry.example.com/checkout:1.42.1 --min-severity high

A patching playbook: the order to work in

The list is long, and the order you work in matters more than how fast you go. This sequence works:

1. Start from what is running, not what is in the registry. Scan the digests the kubelet reports. An image nobody runs is a cleanup task, not an incident.
2. Fix anything in CISA KEV this week, whatever image it is in. These are observed exploitation, and the list is short. If there is no fix yet, mitigate now and track the backport.
3. Then fix anything with EPSS ≥ 0.1 that has a fix, highest CVSS first. That list is still short.
4. Upgrade third-party charts, starting with the biggest win. Rank chart upgrades by how many findings each one closes. A single chart that deploys several images can close dozens with one version bump. Read the changelog, because chart majors do break values.
5. Bump the base images of your own images, oldest base first. This is where most of the long tail goes, and with the digest-pin setup above it is mostly merging pull requests.
6. Deal with the no-fix residue deliberately. Migrate end-of-life bases, mitigate what you can, and record the rest as accepted risk with an owner and an expiry.
7. Confirm every fix by digest, as the next section shows. Nothing is fixed until the vulnerable digest stops running.

In StackRadar, each finding's contribution to the Radar Score is likelihood × consequence. KEV membership sets the likelihood to certainty and EPSS weights the rest, so steps 2 and 3 come out at the top of the list. Helm release pages cover step 4, showing the findings a release carries, the images it deploys and what an upgrade would clear. Image pages cover step 5 with the rebuild advice above. StackRadar deliberately does not claim that a bump is safe. It tells you what the change fixes, and reading the changelog is still your job.

Confirming it is actually fixed

The Deployment says :1.42.1, but the pod might still be running :1.42.0. The rollout may have failed or been paused, or a node may have reused a cached copy of a tag that was pushed again (imagePullPolicy: IfNotPresent). Wait for the rollout, then check the digest each container is actually running:

kubectl rollout status deployment/checkout -n checkout
kubectl get pods -n checkout -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'

A scanner keyed on running digests stops reporting the finding when the vulnerable digest stops running, and not before. A ticket marked "done" is not proof. The fix is real when the kubelet reports the new digest.

Frequently asked questions