Container image scanner or dependency scanner: do you need both?

If you ship container images, you usually need both views: application dependencies from your manifests and lockfiles, and operating system packages from the image layers. One tool may do both. If you deploy only libraries or serverless bundles with no base image, a dependency scanner may be enough.

What each one reads

A dependency scanner reads your application's package files and resolves the tree of libraries. It runs on source, early, and fits pull requests.

An image scanner unpacks a built image and lists everything inside: operating system packages, language packages found in layers, and sometimes binaries. It sees what actually ships, including the base image you did not write.

What each misses

• The dependency scanner does not see the base image, system libraries, or tools added in the Dockerfile.
• The image scanner may not know which packages are direct versus transitive, may lack source-level paths to fix, and runs later, after the build.
• Both can miss code copied into the image with no package record.

Decision guide

1. You ship images to production. Use both views, from one tool or two.
2. You ship libraries or packages only. Dependency scanning is the core. Add image scanning if you also publish images.
3. You run on managed platforms with vendor-supplied runtimes. Dependency scanning matters most, and the platform handles the base. Confirm that responsibility in writing.
4. You use minimal or distroless base images. The operating system surface is smaller, and image scans are quicker to triage, but you still need the application view.

Avoiding duplicate findings

An image scan will often report the same vulnerable library the dependency scan found. To avoid double work:

• Choose a primary source per finding type: application libraries from source scans, operating system packages from image scans.
• Link findings to the same component identifier.
• Fix in the right place. A base image update fixes dozens of operating system findings at once, while a lockfile bump fixes a library.

Where to scan in the pipeline

Scan dependencies on pull requests for fast feedback. Scan images after build, before push to the registry, and again on a schedule because new advisories appear after release. Rescanning stored images against fresh data is how you learn that last month's release is now vulnerable.

Questions for a vendor

• Does one product cover both, with one inventory, or two products with two?
• Can image findings point to the Dockerfile line or base image to change?
• How are findings deduplicated across both?
• Can registry images be rescanned continuously?

Where Safeguard fits: it covers container image scanning alongside SBOM and dependency scanning, and the free scan shows results for a public repository.

Try it yourself

Click through it at your own pace, or open it full screen.

See which layer each finding comes from and what the suggested fix is.

Quick check

Last reviewed: 19 October 2026.