Docker Scout shipped in Docker Desktop 4.17 and brought vulnerability analysis directly into the Docker developer workflow. No separate tool installation. No registry integration headaches. Just docker scout from the same CLI you already use to build and push images.
The question is not whether Docker Scout works. It does. The question is whether it catches enough for your risk tolerance, and where you need to supplement it.
What Docker Scout Actually Does
Docker Scout analyzes container images against multiple vulnerability databases and produces recommendations. It operates on two levels:
Image analysis: Inspects the image filesystem, identifies packages (OS packages, language-specific dependencies), and matches them against CVE databases.
Policy evaluation: Checks images against configurable policies—no critical CVEs, no outdated base images, no packages with known fixes available.
Basic Usage
# Analyze a local image
docker scout cves myapp:latest
# Quick overview with recommendations
docker scout quickview myapp:latest
# Compare two images (e.g., before/after a rebuild)
docker scout compare myapp:v1.2 --to myapp:v1.3
# Generate SBOM
docker scout sbom myapp:latest --format spdx-json
Output Breakdown
A typical docker scout cves output looks like:
Target: myapp:latest
digest: sha256:abc123...
Packages: 247
Vulnerabilities:
Critical: 2
High: 12
Medium: 34
Low: 18
CVE-2023-44487 Critical nghttp2 1.51.0 (fixed in 1.57.0)
HTTP/2 Rapid Reset Attack
...
Scout groups vulnerabilities by severity and shows the fix version when available. This is the actionable part—knowing that a fix exists is the difference between "acknowledge the risk" and "update and rebuild."
Setting Up Docker Scout
Docker Desktop
Docker Scout is integrated into Docker Desktop. Enable it in Settings > General > Docker Scout. Analysis runs automatically on images you build locally.
CLI-Only (Docker Engine)
For headless servers and CI environments:
# Install the Scout CLI plugin
curl -sSfL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | sh
# Authenticate (required for full database access)
docker login
# Verify
docker scout version
CI/CD Integration
GitHub Actions:
- name: Docker Scout Analysis
uses: docker/scout-action@v1
with:
command: cves
image: ${{ env.IMAGE_NAME }}:${{ github.sha }}
only-severities: critical,high
exit-code: true # Fail the build on findings
The exit-code: true flag is critical. Without it, Scout reports findings but the pipeline continues. For security gates, you need the build to fail.
Understanding Scout's Data Sources
Docker Scout pulls vulnerability data from:
- Docker Scout Advisory Database: Docker's curated database, updated continuously
- NVD (National Vulnerability Database): The standard CVE source
- GitHub Advisory Database: Covers language-specific ecosystems
- Distribution advisories: Ubuntu, Debian, Alpine, Red Hat security advisories
The breadth of data sources matters because different databases have different coverage and different lag times. A CVE might appear in GitHub Advisories days before NVD processes it.
Package Detection
Scout identifies packages through:
- OS package managers: apt, apk, yum/rpm packages
- Language ecosystems: npm, pip, Go modules, Maven, NuGet, RubyGems
- Binary analysis: Detects known binaries even when package metadata is missing
The binary analysis capability sets Scout apart from tools that rely purely on package manifests. If a Go binary is compiled statically with vulnerable dependencies, Scout can sometimes identify the embedded libraries through binary fingerprinting.
Docker Scout Policies
Policies move beyond individual CVEs to organizational standards:
# View available policies
docker scout policy myapp:latest
# Example output:
# ✗ No critical vulnerabilities FAILED (2 critical CVEs)
# ✗ No high vulnerabilities with fixes FAILED (8 fixable high CVEs)
# ✓ Up-to-date base image PASSED
# ✗ No outdated packages FAILED (14 packages outdated)
# ✓ Supply chain attestation PASSED
Custom Policies
Docker Scout supports organization-level policies through the Docker Scout Dashboard:
- Maximum age for base images
- Required SBOM attestation
- Approved base image list
- Maximum vulnerability count by severity
These policies map directly to compliance requirements. When an auditor asks "how do you ensure containers do not ship with critical vulnerabilities," you point to a policy that fails builds.
Scout Comparison Features
The compare command is underutilized but powerful:
docker scout compare myapp:v2.1.0 --to myapp:v2.0.0
Output shows:
- New vulnerabilities introduced
- Vulnerabilities fixed
- Package changes (additions, removals, upgrades)
This is invaluable for pull request reviews. Instead of scanning the new image in isolation, compare it against the current production image. A new image with 15 high vulnerabilities sounds bad, but if the current production image has 20, it is an improvement.
Where Scout Falls Short
No Runtime Analysis
Docker Scout analyzes images statically. It does not detect:
- Vulnerabilities introduced at runtime through package installation
- Configuration drift
- Runtime behavioral anomalies
For runtime security, you need Falco, Tetragon, or similar tools.
False Positives on Distroless Images
Scout sometimes flags vulnerabilities in packages that are present in the image but not actually reachable. A vulnerability in libcurl matters if your application uses HTTP. It is noise if libcurl was pulled in as an unused transitive dependency.
Limited First-Party Code Scanning
Scout focuses on third-party dependencies. It does not scan your application source code for vulnerabilities. For that, you need a SAST tool like Semgrep, CodeQL, or SonarQube.
Database Lag
New CVEs can take hours to days to appear in Scout's database. Zero-day response requires supplementing Scout with threat intelligence feeds and manual analysis.
Scout vs. Other Scanners
| Feature | Docker Scout | Trivy | Grype | Snyk Container | |---|---|---|---|---| | CLI integration | Native Docker | Standalone | Standalone | Plugin | | SBOM generation | Yes | Yes | Via Syft | Yes | | Policy engine | Yes | OPA integration | No | Yes | | Binary analysis | Yes | Partial | Partial | Yes | | Price | Free tier + paid | Free | Free | Free tier + paid | | Offline mode | No | Yes | Yes | No |
When to Use Multiple Scanners
Run multiple scanners. Each has different detection logic and database coverage. A vulnerability one misses, another catches:
# Scout first (fast, integrated)
docker scout cves myapp:latest --exit-code --only-severities critical,high
# Trivy second (broader coverage, offline capable)
trivy image --severity HIGH,CRITICAL myapp:latest
# Compare results for discrepancies
Integrating Scout into Development Workflow
The highest-leverage integration point is the developer's local machine. Fix vulnerabilities before they reach CI, let alone production:
# In your Makefile
.PHONY: scan
scan: build
docker scout cves $(IMAGE):$(TAG) --only-severities critical,high
@echo "Run 'docker scout recommendations $(IMAGE):$(TAG)' for fix suggestions"
Docker Scout also integrates with Docker Desktop's GUI, showing vulnerability counts directly in the image list. Developers see the security posture of every local image without running any commands.
How Safeguard.sh Helps
Safeguard.sh complements Docker Scout by providing continuous monitoring beyond the build phase. While Scout catches vulnerabilities at build time, Safeguard.sh tracks your entire container inventory across registries and running environments, alerting when new CVEs affect images already deployed in production. The platform aggregates findings from multiple scanners including Scout, Trivy, and Grype into a unified vulnerability dashboard, deduplicates results, and prioritizes remediation based on runtime exposure and exploit availability rather than raw CVSS scores alone.