Docker Vulnerability Scanners: What They Catch and Miss

A docker vulnerability scanner inspects the contents of a container image — operating system packages, language dependencies, and increasingly configuration and secrets — and matches what it finds against vulnerability databases to report known CVEs. Tools like Trivy, Grype, Clair, and Docker Scout are genuinely good at this, and equally, structurally limited: they catch known vulnerabilities in known package formats, and they miss logic flaws, runtime misbehavior, and software that entered the image outside a package manager. Knowing exactly where that line sits is what makes scan results useful instead of falsely reassuring.

How does a docker vulnerability scanner actually work?

Four stages, regardless of vendor. First, the scanner unpacks the image layers — an image is a stack of filesystem tarballs plus metadata, no running container required. Second, it builds an inventory: it reads the OS package database (dpkg status files on Debian/Ubuntu, rpm on Red Hat, apk on Alpine) and walks the filesystem for language ecosystem artifacts — package-lock.json, Python dist-info metadata, Java JAR manifests, Go build info embedded in binaries. This inventory is, in effect, an SBOM, and most modern scanners can emit it as CycloneDX or SPDX. Third, it matches the inventory against vulnerability data: the NVD plus distro-specific advisories (Ubuntu, Debian, Red Hat, Alpine secdb) and ecosystem databases like OSV and GitHub's advisory database. Fourth, it reports findings with severity, usually fixed-version information, and ideally which layer introduced the package — so you know whether the fix is "change base image" or "bump your own dependency."

The matching step is where quality varies most between tools: naive CPE matching against the NVD produces notorious false positives, while distro-advisory-aware matching correctly recognizes that, for example, a Debian package with a backported fix is not vulnerable despite its version string.

What does image scanning reliably catch?

The strike zone is broad and valuable:

• OS package CVEs. Every vulnerable openssl, glibc, curl, or libxml2 that came in through the base image or an apt-get install. This is the bulk of findings in most images, and it is why base image choice dominates vulnerability counts.
• Language dependency CVEs. Known-vulnerable npm, PyPI, Maven, Go, and RubyGems packages, including transitive dependencies captured in lockfiles — the same coverage as SCA, applied to the built artifact rather than the repo.
• Stale base images. The single most common finding pattern: an image built eight months ago on node:18 carries every OS CVE published since, fixed upstream but absent locally because the image was never rebuilt. Scanners make this rot visible.
• Embedded secrets and basic misconfigurations. Most current scanners also flag hardcoded credentials in layers, and Dockerfile-level issues like running as root or missing health checks — useful, though shallower than dedicated tools.

For all of this, scanners are fast (seconds to a couple of minutes per image), cheap to run on every build, and precise enough to gate CI on.

What does a docker vulnerability scanner miss?

The misses are structural, not bugs to be fixed in the next release:

1. Software outside package databases. A binary compiled from source, a vendored library copied into the image, a tool installed via curl | bash — none of these appear in dpkg or a lockfile, so most scanners never inventory them. Attackers do not restrict themselves to properly packaged software; neither should your inventory. Some tools attempt binary fingerprinting, but coverage is partial.
2. Your own code. The scanner matches known CVEs in third-party components. The SQL injection your team wrote last sprint has no CVE and is invisible to image scanning — that is SAST and DAST territory.
3. Unknown and unpublished vulnerabilities. By definition, database matching finds only what is in the database. A zero-day in a dependency scores a clean scan until disclosure day.
4. Runtime and orchestration context. An image scan cannot see that the container runs privileged, mounts the Docker socket, or sits exposed to the internet with an over-broad service account. Image scanning tells you what is inside the box, not how dangerously the box is deployed — that is the domain of Kubernetes configuration scanning and runtime security.
5. Reachability. A vulnerable function in a library that is present but never invoked still fires a finding. Without reachability analysis, scanner output over-reports true risk, which is precisely how teams end up with thousand-finding backlogs they stop reading.

How is this different from a source code or website vulnerability scanner?

Worth separating out, since the search terms overlap: a source code vulnerability scanner (SAST) reads your application's source before it is ever compiled, looking for logic flaws and injection bugs that will never have a CVE assigned to them, whereas a docker vulnerability scanner inspects a built image for known-vulnerable packages already sitting inside it. Searching for a free web vulnerability scanner, a website security vulnerability scanner, or a web vulnerability scanner free of licensing cost usually means something different again — a dynamic (DAST) scanner that crawls a running website looking for issues like injection, broken authentication, and misconfigured headers, not a tool that unpacks container layers. None of these three categories substitute for each other: a clean docker image scan says nothing about whether your own code has a SQL injection bug, and neither says anything about how the deployed website actually behaves under attack.

How should you choose and deploy an image scanner?

Selection criteria that actually separate tools: distro-advisory-aware matching (test it: scan a Debian image and check whether backported fixes are handled), lockfile and binary coverage for your languages, SBOM output, database freshness and offline support if you need it, and CI ergonomics — exit codes, policy thresholds, baseline suppression.

Deployment matters more than tool choice. Scan at three points: in CI on every build (gate on fixable criticals, so unfixable base-image noise does not train developers to ignore the gate), in the registry on a schedule (new CVEs are published against your existing images daily — a clean scan is a timestamp, not a property), and against production inventory, so you can answer "which running services contain the new OpenSSL CVE?" in minutes. Rebuild cadence is the quiet win: images rebuilt weekly on refreshed base images stay clean nearly for free, and consolidated platforms — Safeguard among them — tie image findings into the same prioritized backlog as code and dependency findings, which is where container CVEs stop being a separate silo. For choosing between platform and point tools, our Snyk comparison covers the container angle.

FAQ

What is the best docker vulnerability scanner?

For open source, Trivy and Grype are the current defaults — fast, actively maintained, distro-aware, with SBOM output. Docker Scout integrates tightly with Docker Hub and Desktop. Commercial platforms add prioritization, ownership routing, and unified backlogs across code, dependencies, and images. Most teams should start with Trivy or Grype in CI and graduate to a platform when finding volume outgrows spreadsheets.

Do image scanners find vulnerabilities in my application code?

No. They find known CVEs in third-party OS packages and language dependencies inside the image. First-party code flaws require static analysis (SAST) and dynamic testing (DAST), which complement rather than duplicate image scanning.

How often should Docker images be scanned?

On every build, plus a scheduled re-scan (daily or weekly) of images already in your registry and running in production. New CVEs are published continuously against existing software, so an image that passed last month may be critically vulnerable today without changing a byte.

Why does my base image have so many vulnerabilities?

Full OS base images carry hundreds of packages you never use, each a potential finding. Switching to slim variants, distroless images, or Alpine typically cuts findings dramatically — and rebuilding regularly picks up the upstream fixes that already exist for most of the rest.

Is a docker vulnerability scanner the same as a source code vulnerability scanner?

No. A source code vulnerability scanner reads source before compilation and catches logic and injection flaws with no CVE, while a docker vulnerability scanner matches packages already baked into a built image against known CVEs. Most mature programs run both, plus DAST against the running service.

Is there a free online vulnerability scanner for testing a website, not just a container image?

Yes, but it is a different tool category, and most tools in this category run as CLI or self-hosted scans rather than a hosted free online vulnerability scanner you point at any URL. Open source options like OWASP ZAP function as a free web vulnerability scanner or website security vulnerability scanner, crawling a live site rather than inspecting image layers. If you specifically need a web vulnerability scanner free of cost to test a running application, start there — it complements a docker vulnerability scanner rather than replacing it.