Docker Scout: Using Built-In Image Analysis and CVE Overview

1. What Docker Scout Is and How It Is Integrated

Docker Scout is Docker's own analysis tool for container images, built into Docker Desktop and the Docker CLI for several versions now, and it works without installing a separate external scanner. It analyzes the Software Bill of Materials (SBOM) of an image, meaning the complete list of all contained packages and libraries with their versions, and checks it against known vulnerability databases.

The big practical advantage over separate scanning tools lies in the seamless integration: docker scout commands sit right alongside docker build and docker push, and Docker Desktop partly shows analysis results automatically as soon as an image is built or pushed locally, without an extra step in the workflow.

2. CVE Scanning With docker scout cves

The docker scout cves command provides a detailed list of all CVEs found in an image, grouped by severity (critical, high, medium, low), with a reference to the affected package including installed and patched version. This granularity makes it possible to focus specifically on critical and high findings instead of overlooking the actually relevant problems in a long list of low-priority notices.

Filter options like --only-severity critical,high let you reduce the output directly to the most important findings, which is especially helpful in CI pipelines, where a compact, focused output can be evaluated faster than a full report, often several hundred lines long, covering every theoretically present vulnerability.

# Create a full CVE report for a local image
docker scout cves myapp:latest

# Show only critical and high severities
docker scout cves myapp:latest --only-severity critical,high

# Export the result as JSON for further processing
docker scout cves myapp:latest --format json --output scout-report.json

3. Recommendations for Leaner Base Images

Beyond the plain vulnerability list, docker scout recommendations provides concrete suggestions for making an image safer and smaller, for example switching from a full Debian base to a leaner Alpine or distroless variant, if the application can technically handle that change. The recommendations take into account both the reduction in attack surface and the actually measured CVE count of the suggested alternative.

These recommendations are especially valuable for older, historically grown Dockerfiles where nobody can precisely explain anymore why a certain base image version was originally chosen. Docker Scout provides a concrete, data-based foundation for modernization here, instead of teams switching to a newer version on a hunch.

# Fetch recommendations for an image
docker scout recommendations myapp:latest

# Compact summary with score and key metrics
docker scout quickview myapp:latest

4. A Fast Overview With docker scout quickview

For daily use, for instance right after a local build, docker scout quickview is usually the most practical entry point, because it prints the total number of vulnerabilities by severity, the base image version, and a short note on available updates in just a few lines, without requiring the full detail of docker scout cves.

This quick overview works well as a gate in the local development workflow: before every push, a developer can check in a few seconds whether a newly built image suddenly contains new critical CVEs, for example because a recently updated dependency brought in a new vulnerability, and fix it before pushing if needed.

5. Comparing Images Across Versions

A particularly useful feature is docker scout compare, which directly juxtaposes two image versions and shows which CVEs are newly introduced between versions, which were fixed, and how the total size changed. This is especially valuable for dependency updates, to check whether an upgrade actually brings the expected security improvement or unexpectedly introduces new problems.

In release processes, this comparison between the currently live image and the new candidate can be established as an additional check step before rollout, so security regressions surface early, before a new image is rolled out to production and quietly creates additional attack surface there.

# Compare two image versions directly
docker scout compare myapp:1.2.0 --to myapp:1.3.0

# Compare against the currently live image from the registry
docker scout compare myapp:latest --to registry.example.com/myapp:prod

6. Integrating Into the CI/CD Pipeline

Docker Scout can be integrated via a dedicated GitHub Action, and via the docker scout CLI into any other CI system such as GitLab CI or Jenkins, by running the scan right after the build step and storing the result as a build artifact or a comment on the merge request. This turns security checking into part of the normal pipeline run instead of a separate, often forgotten manual task.

For authenticated access to Docker Hub or a private registry within the pipeline, a Docker Hub access token or corresponding registry credentials are needed, since Docker Scout requires a logged-in account for extended analyses and higher usage limits, while simple local scans usually work without login as well.

7. Docker Scout Compared to Trivy and Grype

Trivy and Grype, already covered in detail in an earlier article, are standalone open-source scanners that can be installed independently of Docker and integrated into any environment, even where no Docker daemon runs at all, for example when analyzing an OCI image tarball in a pure Kubernetes environment. Docker Scout, by contrast, is tightly bound to the Docker ecosystem and delivers its convenience advantage mainly where work already happens with the Docker CLI or Docker Desktop anyway.

In scan quality and database coverage, all three tools are close to each other since they draw on similar public vulnerability sources; small discrepancies in individual CVEs are normal and not a sign of one tool being fundamentally better or worse. The essential difference is workflow: teams already deep in the Docker toolchain save an installation step with Docker Scout, while those needing a tool-agnostic solution usable outside Docker too are better served by Trivy or Grype.

8. Policy-Based Gates and Score Thresholds

Docker Scout supports policies defined through Docker Organizations that specify which conditions an image must meet, for example no critical CVEs or a certain maximum age of the base image version, to be considered compliant. These policies can be defined centrally for an entire team or organization, instead of every project maintaining its own thresholds in individual CI scripts.

In the pipeline, the exit code of docker scout cves or the policy evaluation can be used to build a hard gate that blocks a merge or deploy as soon as an image violates the defined policy. It is important to set the thresholds realistically, since an overly strict gate on base images with constantly newly reported low-severity CVEs quickly leads to frustration and workaround attempts within the team.

9. A Practical Takeaway for Daily Use

For teams already working with Docker Desktop, Docker Scout is the most natural entry point into automated image analysis, because no additional installation is needed and results appear directly in familiar Docker commands. The fast quickview command is well suited for daily developer work, while compare and policy integration belong more in release and CI processes.

Teams that already run an established scanning infrastructure with Trivy or Grype do not necessarily need to switch, both approaches can also run in parallel, for example Docker Scout for fast local feedback and Trivy as a tool-agnostic gatekeeper in the actual CI pipeline. More important than the choice of a specific tool is that CVE scans happen at all, regularly and automated.

10. Summary

11. FAQ: Docker Scout: The Essentials at a Glance