Container Scanning: How It Works and What It Can't See

How container scanning works

Unpack the image. The scanner reads the image's layers without running them.
List the contents. It reads operating system package databases and application manifests, such as a package-lock.json copied into the image.
Match the data. It compares packages with vulnerability data from distributions and advisory databases.
Check the configuration. Some tools also flag things like running as root or secrets left in a layer.

Where to run a scan

Stage	What it gives you	Limit
CI, after the image build	Fails the build before an image is pushed	A snapshot of that day's advisories
Registry	Rescans stored images as new advisories appear	Finds issues after the image is published
Kubernetes admission	Blocks unscanned or failing images at deployment	Needs a policy and a way to handle exceptions
Runtime	Shows which images are running now, and what is loaded	Needs an agent on your clusters

Container scanning tools

Open source: Trivy and Grype are the common free choices, and both fit easily into CI.
Built into registries and platforms: Docker Scout and the major cloud registries offer scanning.
Commercial platforms: Snyk and Anchore add policy, reporting and workflow.

How to reduce the findings

Start with a smaller base image. Slim or distroless images contain fewer packages, so fewer advisories apply.
Rebuild regularly. Base images get patched, and an image that was clean in March is not clean now.
Use multi-stage builds. Compilers and build tools should stay out of the final image.
Pin base images by digest. A tag can change under you, and a digest cannot.
Prioritize. Many findings have no fix yet or sit in packages your application never uses. See how to prioritize vulnerabilities.

What a container scan can't see

Compiled code. A Go or Rust binary in the image carries limited metadata, and a scanner has to work out what went in.
Files with no package record. Software added with curl or copied into a layer has no entry in a package database.
What the build used and left behind. Multi-stage builds discard the tools that produced the image. If one of those was compromised, nothing in the final image says so.
Where it came from. A scan describes the image, not the build that produced it.

See what a Docker image SBOM misses for a closer look, and the best SBOM tools for the options.

Scanning images and recording builds

Scanners are the right tool for images you did not build, along with clusters and configuration. For images you do build, CRACI takes a different route. As your GitHub Actions runner, it sees what comes into the build, including the base image and its operating system layers, so it records what went in rather than working it out afterward. It then keeps checking those SBOMs as new vulnerabilities are published.

CRACI does not scan images you did not build, clusters, VM images or misconfigurations. Trivy does, so keep it for those. See CRACI vs Trivy.

Container scanning: frequently asked questions

What is container scanning?

It is the process of inspecting a container image for known vulnerabilities, outdated packages and risky configuration, usually without running it.

When should you scan container images?

In CI after the image is built, and again in the registry as new advisories appear. Scanning only once leaves you with a snapshot that ages quickly.

What is the best free container scanner?

Trivy and Grype are the most widely used free options. Both run in CI and cover operating system and application packages.

What is the difference between image scanning and an SBOM?

An SBOM lists what is in an image, while a scan checks those contents for known issues. Many scanners build an SBOM first and then match it against advisories.

Why does my container image have so many vulnerabilities?

Mostly because of the base image, which brings in an operating system's packages. A smaller base image and regular rebuilds remove most of them.

Can a container scanner read compiled binaries?

Partly. Go and Rust binaries can carry some dependency metadata, but much compiled code gives a scanner little to go on, so it has to infer what went in.