Docker Scout and Supply Chain Security: From Build to Production

The SolarWinds attack of 2020 and the log4j crisis of 2021 taught the industry a painful lesson: you cannot secure what you cannot see. Most teams had no idea log4j was in their images until scanners found it — and even then, mapping which images needed patching across hundreds of microservices took weeks. Supply chain security isn't just about scanning at build time; it's about knowing what's in every running container, every hour, and having the policy infrastructure to block a compromise before it reaches production.

Docker Scout was launched as Docker's answer to this gap. Rather than being yet another standalone scanner, it's a platform that embeds security into the existing Docker workflow. You already run docker build and docker push — Docker Scout hooks into those commands to analyze images as they're built, store the SBOM alongside the image in the registry, and continuously evaluate against fresh CVE data. When a new CVE is published that affects a package in your image, Docker Scout alerts you — even if the image was built six months ago.

The result is a shift from reactive scanning ('we scan before deployment') to continuous governance ('every image is evaluated on every push, and policy violations block deployment'). This article covers how to set up Docker Scout, interpret its output, write policy files, integrate with GitHub Actions and GitLab CI, generate and export SBOMs, and compare it against other tools like Trivy and Grype so you can decide where it fits in your security stack.

Setting Up Docker Scout and Running Your First Scan

Docker Scout is included with Docker Desktop (enabled by default) and available as a CLI plugin for Docker Engine. To verify it's installed: docker scout version. If not installed, you can add it via docker scout install or download the plugin from the Docker Hub marketplace. You need a Docker Pro/Team/Business subscription for full functionality — the free tier includes basic CVE scanning but lacks policy enforcement and auto-fix PRs.

The first step is enrolling your image or repository: docker scout enroll <image> registers it with Scout's analysis engine. Once enrolled, Scout builds an SBOM and runs vulnerability analysis. You can see the results with docker scout quickview <image> (summary) or docker scout cves <image> (detailed CVE list).

The output shows CVEs grouped by severity (critical, high, medium, low), with columns for package name, installed version, fixed version (if available), and a CVE ID linking to the advisory.

# Check Scout is installed and get version
docker scout version

# Enroll an image for Scout analysis
docker scout enroll myapp:latest

# Quick summary
docker scout quickview myapp:latest

# Detailed CVE report
docker scout cves myapp:latest

# Get recommendations for base image upgrades
docker scout recommendations myapp:latest

# Generate SBOM in CycloneDX format
docker scout sbom --format cyclonedx myapp:latest > sbom.cyclonedx.json

# Generate SBOM in SPDX format
docker scout sbom --format spdx myapp:latest > sbom.spdx.json

Policy-Based Governance: Blocking Vulnerable Images in CI

The real power of Docker Scout isn't CVE scanning — it's policy-based governance. You define a policy file (.scout-policy.yaml) that specifies rules like 'no critical CVEs', 'must use approved base images', or 'must have SLSA provenance attestations'. When the policy is evaluated during CI, Scout checks the image against every rule and returns a pass/fail result.

A policy file uses a simple YAML syntax. Each rule has a name, a type (severity, base_image, provenance), and parameters. Rules can be combined with AND logic. The block_on directive determines when a violation prevents deployment: push blocks the image from being pushed to the registry, while warn only logs a warning.

Policies are version-controlled and stored alongside your application code. This means security rules evolve with your application.

# Docker Scout Policy File
version: v1
rules:
  - name: no-critical-or-high-cves
    type: severity
    params:
      max_severity: medium
    block_on: push
  - name: approved-base-images
    type: base_image
    params:
      allowed:
        - docker.io/library/node:20-slim@sha256:abc...
    block_on: push
  - name: require-provenance
    type: provenance
    params:
      level: 2
    block_on: push

Generating and Exporting SBOMs (CycloneDX and SPDX)

A Software Bill of Materials (SBOM) is the foundation of supply chain security. Docker Scout generates SBOMs in two industry-standard formats: CycloneDX (OWASP's format, preferred for most use cases) and SPDX (ISO standard, required for some regulatory compliance). The SBOM lists every OS package, language dependency (npm, pip, go, maven, nuget), and binary component in the image, along with version information and licenses.

To generate an SBOM: docker scout sbom --format cyclonedx <image> > sbom.json. The output is a standardized JSON document that can be consumed by other tools, uploaded to S3, or attached to a release. Docker Scout also stores the SBOM alongside the image in the registry.

For CI/CD integration, generate the SBOM as a build artifact and store it in your artifact repository alongside the image. This gives auditors a complete history of what was in every image at every point in time.

# Generate SBOM in CycloneDX format (recommended)
docker scout sbom --format cyclonedx myapp:latest > sbom-cyclonedx.json

# Generate SBOM in SPDX format
docker scout sbom --format spdx myapp:latest > sbom-spdx.json

# Compare SBOMs between two images
docker scout compare myapp:latest myapp:v1.2.0 --format diff

# Upload SBOM to Docker Scout cloud (auto-stored after enrollment)
docker scout enroll myapp:latest

Docker Scout vs Trivy vs Grype: Which Scanner to Use When

Docker Scout, Trivy, and Grype are all capable container scanners, but they serve different niches. Docker Scout is the only one that integrates natively with the Docker ecosystem — it scans images as part of docker build, stores SBOMs in the registry, and provides policy-based governance. Trivy is the most comprehensive standalone scanner — it scans not just containers but also filesystems, Git repos, Kubernetes clusters, and IaC templates. Grype is a lightweight, fast scanner focused specifically on container vulnerability scanning, often paired with Syft for SBOM generation.

Pricing: Docker Scout is included with Docker Pro ($5/month), Team ($9/month), and Business ($21/month) subscriptions. Trivy is free and open-source (Apache 2.0). Grype is free and open-source (Apache 2.0). All three can be run in CI pipelines.

# Docker Scout
docker scout cves myapp:latest

# Trivy
trivy image myapp:latest

# Grype (+ Syft for SBOM)
grype myapp:latest
syft myapp:latest -o cyclonedx > sbom.json
grype sbom:sbom.json

CI/CD Integration: GitHub Actions and GitLab CI

Docker Scout integrates natively with both GitHub Actions and GitLab CI. For GitHub Actions, use the docker/scout-action action. It supports analyzing images, evaluating policies, and outputting results as SARIF for GitHub's security tab. For GitLab CI, use the docker/scout-gitlab-ci template or the docker scout CLI directly.

The recommended flow is: build image → run Scout analysis → evaluate policy → push to registry. If policy evaluation fails, the pipeline stops before the push.

name: Docker Scout CI
on:
  push:
    branches: [main]
jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Docker Scout scan
        id: scout
        uses: docker/scout-action@v1
        with:
          image: myapp:${{ github.sha }}
          dockerhub-user: ${{ secrets.DOCKER_USER }}
          dockerhub-password: ${{ secrets.DOCKER_PAT }}
          command: cves,policy,recommendations
          policy-file: .scout-policy.yaml
          sarif-file: scout-report.sarif
          only-severities: critical,high
      - name: Upload SARIF to GitHub Security tab
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: scout-report.sarif
      - name: Push image (only if policy passes)
        if: steps.scout.outcome == 'success'
        run: docker push myapp:${{ github.sha }}