Application vs base image

Scan a container image and most of what comes back is not about your code. It is libssl and glibc from the distribution the image is built on, the copy of npm that ships inside the Node image, the JDK's own jars. Those findings are real — and none of them is fixed by bumping a dependency. Mixed into one list sorted by severity, they bury the handful of findings you can actually act on today.

StackRadar splits every findings table into Application and Base image, opens on Application, and tells you what would remove the rest.

The two buckets

Every findings table has the same three-way control, with the count in each segment, so the bucket you are not looking at is never invisible:

Application (12) · Base image (231) · All (243)

The choice is part of the page's URL (?tier=application, base or all), so a link you paste shows its recipient the view you were looking at.

Exploited findings are always shown

A view is a default, never a verdict. A finding that is in the CISA KEV catalogue, or has an EPSS score of 0.1 or more, is listed under every view, whichever bucket it is in, with a label saying why: "Base image · exploited". An actively exploited flaw in glibc is not something to discover by clicking a tab.

Folded, not hidden

• The Radar Score counts every finding, in both buckets. The split changes what is listed first, never what is counted.
• Nothing is suppressed automatically. Suppression in StackRadar is a manual decision with an owner, a reason and an expiry, and this feature never makes one for you.
• The severity cards on the dashboard count everything; they link to the full list, not the Application view, so the number you click is the number you land on.

How the base image is detected

StackRadar starts from what kind of package a finding is in, which it can tell from any SBOM ever uploaded. From scanner 0.4.0 the agent also reports the image's ordered layers (see what data leaves the cluster), and StackRadar works out where the base image ends. When it can, the layer decides: a package belongs to the base image if the layer it first appears in does. That is what makes an apt-get install in your own Dockerfile count as yours — it is an operating-system package, and it is yours to fix.

The boundary is found by the first of these that answers:

1. The image says so. OCI annotations org.opencontainers.image.base.name and .base.digest. Docker Official Images carry them; add them to your own builds and detection is exact.
2. A known public image is its prefix. The first layers of your image are exactly the layers of a public image StackRadar has seen.
3. A shared prefix inside your organization. Two of your images that start with the same layers share an internal base image.
4. Buildpacks metadata, for images that have no Dockerfile history.
5. Build history. A base image ends with its own CMD or ENTRYPOINT, and its layers are older than yours. Where that instruction and the largest jump in layer build time agree, that is the boundary — named only when a registry confirms the guess layer for layer.

When none of them answers, StackRadar says nothing about where the base ends and falls back to the kind of package. It never guesses a base image name.

What removes the base image findings

For an image you build, StackRadar checks the base nightly: what its tag points to today, and the newest tag of the same variant (it will never suggest moving from -slim to -alpine, or from one major version to the next when a newer release of yours exists). It scans those candidates itself and compares them with the findings in your image's base layers:

Rebuilding on node:20.18.1-bookworm-slim removes 212 of 231 base image findings.

Often the answer is the same tag: it has been rebuilt upstream since you built on it, and a rebuild with no Dockerfile change picks the fixes up. It is advice — nothing in StackRadar can rebuild your image, and it says what a rebuild clears, not whether it is safe to deploy.

Images you do not build

The split matters most for images you build. For a third-party image — Prometheus, Grafana, an ingress controller delivered by a public Helm chart — you cannot change the application or the base, so there is one action per image: upgrade the chart, override the image tag, or wait for upstream. StackRadar works out which images are yours (private registry, not delivered by a public chart, not a vendor namespace), asks you once to confirm the ones it could not tell, and groups every recommendation into In your control, Upgrade upstream and Waiting on upstream. You can change the answer any time under Organization settings → Image ownership.

When it is wrong

• An image is filed under the wrong owner. Organization settings → Image ownership: tick or untick the repository. Your answer always beats what was detected.
• A package is in the wrong view. Organization settings → Findings views → Rules: "package URL starts with pkg:npm/%40mycorp/ → Application", or a path in the image, or an exact package name. Rules apply after StackRadar's own, the most specific one wins, and every change is recorded. They move packages between views; they never hide a finding. The same tab sets which view your organization opens on by default.
• The boundary is missing or unnamed. Add the two OCI base annotations to your build, or upgrade the scanner to 0.4.0 so it reports layers at all.
• You do not want the scanner to send image metadata. Set scanner.imageMetadata=false. The split then works from the kind of package alone; findings and scores are unaffected.

In the CLI

stackradar scan applies the same rules locally, with no account. The per-image table lists application packages and gives the base image one line; every total, -o json and --fail-on still see every finding.

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