A Docker image security scan examines every layer of a container image for packages with known vulnerabilities, so you catch a critical CVE in a base image before it reaches production rather than after. An image is not just your application code; it is an entire filesystem, often built on a Linux distribution with dozens of system packages plus your language runtime and dependencies. A Docker security scan reads the software bill of materials of that image and matches it against vulnerability databases. This guide covers which tools to use, the exact commands, and how to make container scanning something your pipeline enforces rather than a manual afterthought.
Why images need their own scan
Scanning your source code and your dependency manifest is necessary but not sufficient. The base image you inherit from, say python:3.12-slim or node:20-alpine, brings its own operating-system packages: OpenSSL, glibc, zlib, curl, and more. Those get security advisories of their own, and a base image that was clean when you pinned it three months ago may now carry several known criticals. A Docker image security scan sees the whole picture: OS packages, language dependencies baked into the image, and sometimes application libraries copied in during the build.
The other reason is drift. Even if you never change your Dockerfile, the vulnerability databases change daily. An image that scanned clean last week can light up today because a new CVE was published against a package it already contained.
Docker Scout: the built-in option
Docker's own scanner is Docker Scout, and it ships inside Docker Desktop 4.17 and later. It replaced the older docker scan command, which was powered by Snyk and was deprecated after April 13, 2023. If you have a recent Docker install, you already have Scout available.
The basic command scans an image and lists CVEs:
docker scout cves my-app:latest
For a quick prioritized summary and recommendations on which base image to move to, Scout offers:
docker scout quickview my-app:latest
docker scout recommendations my-app:latest
The recommendations output is the underrated part: it often tells you that bumping to a newer patch of your base image clears a batch of vulnerabilities for free, which is usually the cheapest fix available.
Trivy and Grype: open-source workhorses
If you want something that runs anywhere without Docker Desktop, Trivy from Aqua Security is the most widely used open-source option. It scans images, filesystems, and Git repositories, and it is a single binary:
trivy image my-app:latest
Trivy is fast, has good defaults, and integrates cleanly into CI. You can fail a build on severity with a flag:
trivy image --severity CRITICAL,HIGH --exit-code 1 my-app:latest
Grype from Anchore is the other strong open-source scanner, often paired with Syft for SBOM generation. Both are worth knowing because they draw on overlapping but not identical vulnerability data, so occasionally one flags something the other misses.
Where a Snyk scan of a Docker image fits
Many teams reach for a Snyk scan of a Docker image because Snyk integrates deeply with developer workflows and IDEs. The Snyk CLI scans container images and, importantly, tries to attribute findings to specific layers and Dockerfile instructions, which helps you see which RUN or base-image choice introduced a vulnerability:
snyk container test my-app:latest --file=Dockerfile
Passing the Dockerfile with --file is what unlocks the base-image upgrade advice. Note that Snyk's free tier limits the number of tests per month, so heavy CI usage typically needs a paid plan. Whatever tool you choose, the workflow matters more than the brand: scan, prioritize, fix or upgrade, rescan.
Reading the results without drowning
A first scan of a fat base image can return hundreds of findings, which is demoralizing and useless if you treat every line as equally urgent. Prioritize with three filters. First, severity: focus on critical and high before anything else. Second, fixability: a vulnerability with an available fixed version is actionable today, while one with no fix yet is something to track, not something to block a release on indefinitely. Third, reachability and exposure: a CVE in a package your application never invokes is lower priority than one in your request-handling path, though most image scanners cannot tell you that on their own.
The single highest-leverage move after a first scan is almost always switching to a slimmer base image. Moving from a full distribution image to a -slim or distroless variant removes dozens of packages you never used, and each removed package is one fewer thing that can carry a CVE. Rebuild on the smaller base, rescan, and watch the finding count drop.
Make it part of the build, not a chore
A scan you run by hand once a quarter is theater. The value comes from running it on every image build in CI and failing the pipeline when a new critical with an available fix appears. A sensible policy: block on critical and high severity findings that have a fix available, warn on the rest, and record an SBOM as a build artifact so you can answer "which of our images contain package X" instantly when the next big CVE lands.
Container scanning pairs naturally with dependency scanning of your application code, and running both from the same pipeline gives you coverage from source through shipped artifact. An SCA and container platform can consolidate the findings so your OS-package and application-dependency risks land in one view rather than two disconnected reports. For the broader picture of hardening what runs inside the image, our guide on secure container software goes further into runtime and build-time controls.
FAQ
What is the best tool for a Docker image security scan?
There is no single best tool. Docker Scout is convenient because it is built into Docker Desktop. Trivy is the most popular open-source choice and runs anywhere as a single binary. Grype and Snyk are strong alternatives, with Snyk offering good Dockerfile-layer attribution. Most mature teams run one in CI consistently rather than switching between them.
Is docker scan still available?
The old docker scan command, which used Snyk's engine, was deprecated after April 13, 2023 and replaced by Docker Scout. Use docker scout cves on current Docker installations, or install the Snyk CLI directly if you specifically want Snyk's output.
How often should I scan container images?
On every build in CI, and ideally on a schedule for images already in registries, because new CVEs are published daily against packages your images already contain. An image that scanned clean last week can show new criticals today without any change to your Dockerfile.
How do I reduce the number of vulnerabilities in an image?
Switch to a slimmer base image such as a -slim or distroless variant, keep base images updated to the latest patch, remove build tools from the final stage using multi-stage builds, and avoid installing packages you do not need. Fewer packages means fewer potential vulnerabilities.