Most of your container vulnerabilities are not yours to fix

Point any scanner at a Kubernetes cluster for the first time and the result is a number with four digits. Nobody reads four-digit lists. The team skims the criticals, finds that the first twenty are in libssl, glibc and a Grafana image they did not build, and quietly stops opening the report. The scanner was right about every finding and still failed at its job.

The problem is not the count. It is that one list mixes three kinds of finding, each fixed by a different person in a different way. StackRadar now separates them with two filters that sit on the dashboard and on every list of vulnerabilities, packages and containers. This post explains the split, what each part is for, and the rules that stop a filter from hiding something that matters.

One list, three different fixes

Take any finding in a running cluster and ask two questions.

Who builds the image? If your organization builds it, you control the Dockerfile and the dependency manifest. If it is Prometheus, cert-manager or an ingress controller that a public Helm chart installed, you control neither.

Where in the image is the package? A dependency your build added, such as an npm or PyPI package, a Go module or a Maven artifact, is fixed by bumping it. An operating-system package, or the copy of npm, pip or the JDK that ships inside the language image, came with the base image, and no change to your dependencies will touch it.

The answers give three groups, and each has exactly one kind of fix:

Sorted by severity in one list, the second and third groups bury the first. The first group is the only one where the work is a pull request somebody on your team can open this afternoon.

The two filters

Images has three settings: All images, Organization images and Third-party images. Findings has three as well: All findings, Application findings and Base image findings. Set them to Organization images and Application findings and the dashboard, the severity cards, the trend charts and every list show the part of the problem that is yours and fixable with a dependency bump.

As an illustration, with made-up but typical proportions for a small cluster:

All images · All findings                       1,840
Organization images · All findings                410
Organization images · Application findings         37

Thirty-seven is a list a team reads to the end. The other findings have not gone anywhere, and the next two sections are about what happens to them.

Base image findings: one rebuild, not a ticket per CVE

Two hundred findings in node:20-bookworm-slim are not two hundred pieces of work. They are one: rebuild on a newer base image. Often that needs no Dockerfile change at all, because a tag like that is rebuilt upstream for months and an image built on last spring's copy clears findings simply by being built again today. For images you build, StackRadar checks the candidates and tells you what a rebuild would remove. The mechanics, and how the boundary between base image and application is found, are in the Application vs base image docs page; the patching workflow around it is in how to patch a CVE in Kubernetes.

One detail matters here. With scanner 0.4.0 the split follows the image's layers, not only the kind of package. An apt-get install in your own Dockerfile is an operating-system package, and it still counts as yours, because the layer that added it is yours.

Third-party images: one action per image

For an image you do not build, splitting application from base image changes nothing, because you can change neither. There is one action per image: upgrade the chart, override the image tag, or wait for upstream. StackRadar groups these into Upgrade upstream, where a newer release removes findings, and Waiting on upstream, where none does yet. The second group is the most useful thing a report can say about those findings: nothing to do this week, and here is why.

StackRadar works out which images are yours from the registry, the chart that delivered them and the namespace they run in, and asks once about the ones it could not tell. Your answer always beats the detection.

What keeps a filter honest

A filter that reduces noise can hide risk just as easily. Several commercial tools filter by a reachability or runtime signal you cannot inspect, and the reader has to trust that whatever was dropped did not matter. These are the rules this split follows instead:

• Exploited findings ignore the Findings filter. A base image finding in the CISA KEV catalogue, or with an EPSS score of 0.1 or more, is listed under Application findings too, labelled "Base image · exploited". An exploited flaw in glibc is not something to discover by changing a menu.
• The score counts everything. The Radar Score sums every finding in every image. The filters change what you are looking at, never what is counted against you.
• Nothing is suppressed for you. Suppression is a manual decision with an owner, a reason and an expiry. No filter makes one.
• The rule is readable. Which package kinds belong to the base image, and the five ways the base boundary is found, are written down in the docs. When the split is wrong for your images, you override it with a rule of your own, and the change is recorded.

How other tools handle it

Stated as fairly as we can. Docker Scout and Snyk Container both attribute findings to the base image and recommend a better one, and both do it well for images that pass through their build or registry integration. Trivy records the layer a package came from in its JSON output, but Trivy Operator reports one flat list per workload, and Dependency-Track does the same per project. None of them separates the images you build from the ones a Helm chart brought in, which in most clusters is the larger share of the list. The wider comparison is in the container scanning tools roundup.

Try it

The live demo runs a real cluster's worth of public charts: open the dashboard and change the two filters in the bar under the title. Without an account, the free CLI applies the same Application and Base image rules locally:

stackradar scan --image nginx:1.27-alpine --min-severity high
  Nothing in the application packages.
  + 41 in the base image (5 critical, 36 high) — fixed by rebuilding on a newer base; --all to list

Frequently asked questions