Docker Scout — Scan Images for Vulnerabilities and Fix Them

The Problem

You built a slim, well-structured image — but the base layer still ships an old OpenSSL with a known critical CVE, and you have no idea. Vulnerabilities enter images through base images and transitive dependencies you never chose directly. Docker Scout scans an image, maps its contents to a software bill of materials (SBOM), matches that against vulnerability databases, and tells you not just what is wrong but how to fix it — usually "bump the base image one tag."

What Docker Scout Is

Docker Scout is a software supply-chain tool built into the Docker CLI. It generates an SBOM for an image (the full list of packages and versions it contains), compares that against continuously updated vulnerability advisories, and surfaces actionable recommendations. It works on local images and on images in a registry.

# Confirm Scout is available
docker scout version

quickview — The 30-Second Summary

Start with quickview to see severity counts for your image and its base.

docker scout quickview myapp:1.0

Target     │  myapp:1.0          │    2C     5H    11M     8L
    Base image │  node:20-alpine   │    1C     2H     4M     3L

This tells you how much of the risk comes from the base image versus your own layers — the single most useful number for deciding where to fix.

cves — The Detailed Report

docker scout cves lists each vulnerability, the affected package, the installed version, and the version that fixes it.

# Full list
docker scout cves myapp:1.0

# Focus on what matters most
docker scout cves --only-severity critical,high myapp:1.0

# Only show vulnerabilities that have a fix available
docker scout cves --only-fixed myapp:1.0

Reading CVE Severity

Severity usually derives from the CVSS score. Prioritize top-down:

Also weigh whether a CVE is fixable (a patched version exists) and whether the vulnerable code path is actually reachable in your app.

recommendations — How to Fix

Scout does not just report problems; it proposes concrete remediation, most often a better base-image tag.

docker scout recommendations myapp:1.0

A typical recommendation is "update node:20.9-alpine to node:20.11-alpine3.19 to clear 1 critical and 2 high." Applying it is a one-line Dockerfile change:

# Before
FROM node:20.9-alpine

# After — Scout's recommended tag
FROM node:20.11-alpine3.19

Rebuild and re-run quickview to confirm the counts dropped.

Comparing Two Images

When you change a base image or a dependency, prove the new image is actually better by diffing it against the old one.

docker scout compare --to myapp:1.0 myapp:1.1

The comparison shows CVEs added and removed between the two images — ideal in a pull request to demonstrate "this change removes 2 criticals and adds none."

SBOM Basics

An SBOM is the inventory Scout builds internally; you can export it for compliance or to feed other tooling.

# Human-readable package list
docker scout sbom myapp:1.0

# Export as standard SPDX JSON
docker scout sbom --format spdx --output myapp-sbom.spdx.json myapp:1.0

An SBOM answers "am I affected by the next big CVE?" instantly — you grep the inventory instead of rebuilding and rescanning everything.

Integrating Scanning into CI

Fail the pipeline when a new image introduces critical or high vulnerabilities that have a fix.

name: image-scan
on: [pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Scan with Docker Scout
        uses: docker/scout-action@v1
        with:
          command: cves
          image: myapp:${{ github.sha }}
          only-severity: critical,high
          exit-code: true   # non-zero exit fails the job

Scanning on every pull request stops a vulnerable image from ever reaching a registry.

Common Mistakes to Avoid

• Scanning only once, manually. Vulnerability databases update daily; an image that was clean last week may have new CVEs today. Scan in CI and on a schedule.
• Chasing every low CVE. Fix critical and high first, and prefer fixable, reachable issues. Drowning in low-severity noise delays the fixes that matter.
• Ignoring the base image split in quickview. Most CVEs usually come from the base image. Bumping one tag often clears more than hand-patching packages ever will.
• Not failing CI on new criticals. A report nobody acts on is theater. Use exit-code: true with a severity threshold so bad images block the merge.
• Treating an SBOM as a one-time artifact. Regenerate it on every build so it reflects the image you actually ship, not an older one.

FAQ

What is the difference between quickview and cves in Docker Scout?

quickview gives a one-line severity summary for the image and its base, ideal for a fast go/no-go check. cves lists each individual vulnerability with the affected package, current version, and the version that fixes it. Use quickview to triage and cves to act.

How does Docker Scout decide the severity of a vulnerability?

Severity is based primarily on the CVE's CVSS score, grouped into critical, high, medium, and low bands. Scout also indicates whether a fix is available, which helps you prioritize fixable issues. Always consider whether the vulnerable code is actually reachable in your application before treating a score as the whole picture.

What is an SBOM and why does it matter?

An SBOM (software bill of materials) is a complete inventory of the packages and versions inside an image. It lets you answer "are we affected by this new CVE?" by searching the inventory instead of rescanning everything. Scout can export SBOMs in standard formats like SPDX for compliance and downstream tooling.

How do I fix the most vulnerabilities with the least effort?

Run docker scout recommendations and apply the suggested base-image update. Because most vulnerabilities come from the base image, bumping to the recommended tag typically clears several criticals and highs in a single one-line Dockerfile change. Rebuild and run quickview again to confirm the counts dropped.