Docker Security Scanning Tools Compared (2026)

Most Docker security scanning tools cover the same ground, so the real question is which one fits your setup. For most teams in 2026, Trivy is the default choice for scanning Docker images: it's free, fast, catches OS and language-package CVEs, and runs anywhere. Grype is the strongest alternative when you want a small, scriptable binary. Docker Scout wins if you already live in Docker Desktop and want SBOM-based policy checks. Paid options like Snyk add fix advice and license scanning. The right pick depends on where the scan runs and who reads the output.

Below is what each tool actually does, the commands to run them, and where each one falls short once you've used it on real images.

What a Docker security scanner actually checks

Most of these tools do the same core job. They read the image, build a list of installed packages (the OS layer plus language dependencies like npm, pip, or Go modules), and match those packages against public vulnerability databases such as the NVD, GitHub Security Advisories, and distro-specific feeds.

That matching is where quality shows up. A scanner that only reads OS packages will miss a vulnerable lodash buried in your node_modules. One that's too aggressive floods you with CVEs that don't apply to your base image, and your team starts ignoring the report. Good scanning is mostly about signal.

A few also generate an SBOM (software bill of materials), check for misconfigurations in the Dockerfile, or flag hardcoded secrets. Those extras matter more than the raw CVE count once you're past the basics.

The Docker security scanning tools, compared

Trivy

Trivy from Aqua Security is the one I reach for first. It's a single Go binary, scans OS packages and language dependencies out of the box, and finishes a typical image in a few seconds after the first DB download.

# Scan an image, show only fixable HIGH and CRITICAL findings
trivy image --severity HIGH,CRITICAL --ignore-unfixed nginx:1.27

The --ignore-unfixed flag is the one that makes the report usable. It hides CVEs with no available patch, so you see what you can actually act on today. Trivy also scans Dockerfiles, IaC, and secrets if you point it there:

trivy config ./Dockerfile
trivy fs --scanners secret ./

Weak spots: the vulnerability DB is large, and first-run downloads can surprise CI if you don't cache it. Trivy can be chatty on base images you don't control.

Grype

Grype, from Anchore, pairs with Syft (its SBOM generator). It's lean, easy to script, and its output is clean enough to pipe into other tools. If you want to generate an SBOM once and scan it repeatedly, this is the natural fit.

# Generate an SBOM with Syft, then scan it with Grype
syft nginx:1.27 -o json > sbom.json
grype sbom:sbom.json --fail-on high

The --fail-on high flag returns a non-zero exit code, which is what you want in a pipeline gate. Grype tends to produce slightly fewer false positives than Trivy on language packages in my experience, though the gap is small and both improve constantly.

Weak spots: no built-in Dockerfile or secret scanning. It does one job.

Docker Scout

Docker Scout is built into recent Docker Desktop and the CLI. It leans on SBOMs and adds policy evaluation, so you can define rules like "no critical CVEs" or "base image must be updated within 30 days" and get a pass/fail.

docker scout cves nginx:1.27
docker scout recommendations nginx:1.27

The recommendations command is genuinely useful. It suggests a newer or slimmer base image and shows how many CVEs that swap would remove. That's the kind of output an engineer acts on.

Weak spots: the richer features and higher pull limits sit behind a Docker subscription, and it's most comfortable inside the Docker ecosystem rather than as a neutral CI tool.

Clair

Clair, from Red Hat / Quay, is a server, not a CLI. It's designed to sit behind a registry and scan images as they're pushed. If you run Quay or want scanning as a service for your whole registry, Clair is the classic answer.

It's more work to stand up than a binary you drop into a script. For a single team scanning a handful of images, it's overkill. For a platform team gating an internal registry, it earns its keep.

Snyk

Snyk is the main commercial player worth naming. Beyond CVE matching it gives you fix guidance (which upgrade closes the most issues), license compliance, and tight IDE and Git integrations.

snyk container test nginx:1.27 --severity-threshold=high

If your organization already pays for Snyk on the app-security side, extending it to containers is low friction. If you don't, the free tier is limited and the value is mostly in the paid features.

Which one should you use?

Start with Trivy or Grype. Both are free, both cover the important cases, and you can have one running in CI this afternoon. Pick Trivy if you also want Dockerfile and secret scanning in the same tool. Pick Grype if you prefer a minimal binary and already generate SBOMs.

Reach for Docker Scout if your workflow is Docker-native and you want policy gates with base-image suggestions. Stand up Clair when you're scanning at the registry level for many teams. Pay for Snyk when fix advice and license checks justify the cost.

Honestly, the scanner matters less than the habit. A mediocre scan that runs on every build beats a perfect one you run twice a year.

Wiring it into your workflow

Scanning during the build is only half the job. The image that was clean at build time collects new CVEs as advisories land, so you also need to scan what's already running. A quick way to do that on a remote host over SSH:

ssh you@prod-host "docker images --format '{{.Repository}}:{{.Tag}}'" \
  | grep -v '<none>' \
  | xargs -I{} trivy image --severity CRITICAL --ignore-unfixed {}

In CI, fail the build on new critical findings but let existing ones through with a .trivyignore file so you're not blocked on CVEs you've already triaged. A GitHub Actions step is three lines:

- name: Scan image
  run: trivy image --exit-code 1 --severity CRITICAL --ignore-unfixed myapp:${{ github.sha }}

The harder part is noticing when a running container drifts out of policy days after deploy. If you manage servers from your phone, Docker HQ can scan the images on your connected hosts and push an alert when a new critical vulnerability shows up, so you find out from a notification instead of the next audit. You can see what's covered on the pricing page.

Scanning is one layer. For the surrounding practices, see Docker Security Best Practices for Production, lock down the daemon with How to Secure the Docker Remote API, and go deeper on the scanning process itself in Docker Image Vulnerability Scanning: A Practical Guide.

Frequently asked questions

Are free Docker scanners good enough for production?

Yes, for most teams. Trivy and Grype use the same public advisory databases the paid tools do, so their CVE detection is comparable. What you pay for with commercial tools is fix guidance, license scanning, reporting dashboards, and support, not fundamentally better vulnerability data.

How often should I scan my images?

On every build, and on a schedule for images already running. New advisories are published daily, so an image that passed last week can have a critical CVE today without anything changing in your code. A nightly or weekly re-scan of production images catches that drift.

Why do two scanners give different results on the same image?

They pull from different combinations of advisory sources and apply different matching logic. One might include a distro feed the other doesn't, or handle version ranges more conservatively. Small differences are normal. If one tool flags something the other misses, check the CVE directly against the package version rather than assuming either is wrong.

What's the difference between scanning an image and scanning an SBOM?

Scanning an image reads its layers and builds the package list on the spot. Scanning an SBOM uses a package list you generated earlier. The SBOM approach is faster to re-run and lets you rescan without pulling the image again, which is handy when a new CVE drops and you want to check old builds fast.

Pick one scanner, put it in your build pipeline today, then add a scheduled scan of production images this week. That order gets you the most coverage for the least effort.