A container scanner should read operating system packages and application dependencies in every image layer, tell you which layer introduced each issue, and recognise your base image's distribution. Ask vendors which distributions and package types they cover, and whether they can scan images without a shell, such as minimal or distroless ones.
Definitions
A container image is a layered package of files: a base image (often a stripped down Linux distribution), then operating system packages, then your application and its libraries. Scanning an image means unpacking those layers and listing what is inside, then matching the list against known vulnerabilities. A registry is where images are stored and pulled from.
Where claims differ
Two scanners can both say "container scanning" and find very different things.
| Capability | Question |
|---|---|
| OS packages | Which distributions and versions are recognised? |
| Application packages | Does it find language libraries inside the image, not just OS packages? |
| Layer attribution | Can it say which layer introduced a package? |
| Base image advice | Does it suggest a safer base image or a newer tag? |
| Minimal images | Does it work on images with no package manager? |
| Binaries | Does it identify statically compiled software? |
| Registries | Which can it pull from, and with what credentials? |
| Running workloads | Can it map an image in production back to its build? |
The minimal image row is a common surprise. Distroless images have no package database to read, so a scanner built around listing OS packages can report nothing and look clean. Read deep visibility into minimal container images for what to check.
Distribution vendor status
Operating system vendors sometimes mark a vulnerability as not affected, deferred or fixed in a backport without changing the version number. A scanner that ignores this will over report. Ask how it uses distribution advisories. Our note on distro CVE statuses explains the labels.
Steps for a trial
- Choose three images: one standard base, one minimal, and one large application image.
- Scan each and save the package list.
- Compare the OS package count with the distribution's own package manager output where you can.
- Check that an application library inside the image appears with the right version.
- Ask the tool to show which layer added a known vulnerable package.
- Rebuild on a different base and confirm the findings change as expected.
Scan timing
Scan at build time to block bad images, in the registry to catch newly published advisories against old images, and at deploy time as a last check. Ask which of these the product does and how they connect. Building from a smaller base also helps, though it is not a guarantee, as discussed in does a smaller container image mean fewer vulnerabilities.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are tied to image layers, then ask other vendors to show the same view.
Quick check
Do we scan the base image or our app image?
Scan the final image you ship. It contains both, and the base layers often hold most of the findings.
Why did a scanner find nothing in my distroless image?
Possibly because it reads package databases that the image does not have. Check that it also reads application files and binaries.
Safeguard offers SBOM and dependency scanning; try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
