Docker Scout: A ‘Magnifying Glass’ for Security Vulnerabilities and How to Patch Images from CLI to CI/CD

Docker tutorial - IT technology blog
Docker tutorial - IT technology blog

2 AM Nightmare: When the Security Audit Knocks

2 AM, an urgent email from the Security team arrives: “Production images have over 50 critical security vulnerabilities (CVEs), patch immediately.” Drowsiness disappears, replaced by panic as a stable system suddenly becomes a target.

That’s when I realized: build and push aren’t enough. Being preoccupied with features makes us forget that base images like node:latest often pull in dozens of outdated libraries. You feel completely helpless when you don’t know which layer the vulnerability is in: is it your code, or that base image from two years ago?

When I receive thousands of lines of JSON scan reports, I usually use Toolcraft’s JSON Formatter to reformat them. Looking at a clear layer structure helps you find the root cause instead of guessing amidst a mess of text.

Why is Your Image So “Sick”?

Vulnerabilities (CVE – Common Vulnerabilities and Exposures) usually don’t come from your code logic. In reality, they hide in three places:

  • Outdated Base Images: An unpatched ubuntu:20.04 image can contain hundreds of published security flaws.
  • Dependencies: npm packages, pip, or system libraries installed via apt-get are often “gateways” for hackers.
  • Excessive Tools: Including curl, git, or vim in a production image makes debugging easy but inadvertently gifts hackers a toolkit to sabotage your system.

Docker Scout – The Built-in Lifesaver

I used to use Snyk or Trivy, but Docker Scout provides a smoother experience because it’s built right into Docker Desktop and the CLI. It doesn’t just list raw errors. Scout acts like a consultant: “Hey, switch to the 20-alpine tag; you’ll clear 90% of the vulnerabilities.”

Step 1: Quick “Health Check” for the Image

Suppose you have an image my-app:v1. Instead of pushing to the cloud and waiting, run this command locally:

docker scout quickview my-app:v1

The result returns a summary table: Critical, High, Medium. If the Critical column shows numbers, that’s a red alert for your system.

Step 2: Inspecting Detailed CVE Codes

To know exactly what the vulnerability is (e.g., a remote code execution flaw in the OpenSSL library), use the command:

docker scout cves my-app:v1

This command lists each affected package and its patched version. If the list is too long, export it to a JSON file and drop it into Toolcraft to filter by priority quickly.

Step 3: Patching Based on Recommendations (The Best Feature)

Don’t waste time scouring Docker Hub for a safe tag. Docker Scout has an incredibly smart recommendations command:

docker scout recommendations my-app:v1

It will pinpoint the solution: update the base image to a minor patch or switch entirely to a minimal distribution like Alpine to reduce risk.

Blocking “Dirty” Images with GitHub Actions

Fixing errors locally is good, but to ensure no one “sneaks” a vulnerability-ridden image onto the server, you must block it at the CI/CD gateway. Here is how I configure it to automatically scan on every Pull Request.

name: Docker Scout Scan
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Build Docker image
        run: docker build -t my-app:${{ github.sha }} .

      - name: Docker Login
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Docker Scout Scan
        uses: docker/scout-action@v1
        with:
          command: cves
          image: my-app:${{ github.sha }}
          ignore-unchanged: true
          only-fixed: true
          write-comment: true
          github-token: ${{ secrets.GITHUB_TOKEN }}

With this workflow, Docker Scout will automatically comment its report on the Pull Request. If the security metrics don’t meet requirements, the pipeline will fail immediately, effectively preventing the deployment of vulnerable images to production.

Standard Process to Keep Images Clean

After many sleepless nights fixing bugs, I’ve distilled 4 golden rules for working with Docker Scout:

  1. Use Multi-stage builds: Only keep the executable files in the final stage. Completely remove compilers and source code to shrink the attack surface.
  2. Prioritize Minimal Base Images: Always choose -slim or -alpine versions. The lighter the image, the fewer files, the fewer vulnerabilities.
  3. Periodic Scanning: New vulnerabilities appear every day. A clean image today doesn’t mean it’s safe next week. Schedule weekly scans for running images.
  4. Compare Before Upgrading: Use the docker scout compare command to compare new and old versions, ensuring the update doesn’t introduce new flaws.

Security isn’t a one-time task. Make docker scout quickview a daily habit. Don’t wait until you’re attacked to scramble for patches; start proactively protecting your work now.

Share: