Open Source Docker Image Vulnerability Scanners Compared

The average container image ships with 180 known security flaws, and roughly 17% of those get flagged high or critical. That's the baseline reality across most of Docker Hub. Throw in the fact that Dockerfiles, manifests, and dependency bumps increasingly get written by AI agents rather than humans, and you've got image variants multiplying faster than any human review process can keep up with. The code carries the same CVE burden it always did. The attack surface just grows faster now, because whatever's generating it doesn't get tired or take weekends off.

So what does a scanner actually do about any of this? It unpacks the image, catalogs the OS packages and libraries and config files, and checks the lot against vulnerability databases and security benchmarks. Simple enough in concept. The real work happens in the matching logic and the database curation behind it, which is exactly why two scanners pointed at the same image can hand you two different answers. That gap is what this piece digs into.

How the open-source scanner landscape is structured today

The field has consolidated some. A handful of well-maintained projects, Trivy, Grype (paired with Syft), Clair, and Docker Scout, cover most real-world usage now, and each is built around a different idea of what a scanner is even for. Two older tools, Dagda and Tern, are still technically installable but barely see active development anymore. Worth naming just so you can cross them off the list without guilt.

What separates these tools isn't always obvious from the README. Scope is one piece of it: is this a single-purpose vulnerability scanner, or does it also touch infrastructure-as-code, Kubernetes manifests, secrets, Git repos? Architecture is another: whether it's a CLI binary you call from CI, a long-running service, or something baked into the registry itself. And then there's where it sits in your pipeline: standalone tool, or one node in a more modular, SBOM-driven setup.

Trivy has north of 34,000 GitHub stars, which makes it the most visible project in this space by a wide margin. A star count tells you nothing about whether a given tool matches the shape of your actual pipeline, though. Worth naming that trap before going any further, because it's the same trap that gets a lot of teams three months into a rollout before they realize the tool doesn't cover what they actually needed.

Trivy's breadth and the supply-chain incident every team should know about

Trivy's whole pitch is coverage. One binary scans container images, filesystems, infrastructure-as-code, Git repositories, Kubernetes clusters, and cloud configs. Nothing else on this list touches that much surface, which is the main reason Trivy has become the default pick for teams that want one tool spanning the entire DevSecOps footprint.

The database work backs up the breadth. Trivy checks OS packages across Alpine, RHEL, Debian, Ubuntu, Amazon Linux, SUSE, Oracle, and Photon OS, and reaches into language ecosystems too: Go, npm, pip, Cargo, Composer, NuGet, Maven, pipenv, poetry. Output comes as JSON, SARIF, CycloneDX, SPDX, table, or template, with SBOM generation built right in. It does secret scanning, catching hardcoded credentials sitting in Dockerfiles and configs, and it runs offline for air-gapped environments. For a lot of teams that's the whole reason to pick it: one tool, one config file, most of the surface covered without stitching together three separate products.

Now, the part every team running Trivy needs to know about. Attackers force-pushed 76 of 77 version tags in the aquasecurity/trivy-action repository and published a malicious binary to GitHub Releases. The exposure window ran about 12 hours. During that window the compromised code scraped CI runner memory for secrets, cloud credentials, SSH keys, and Kubernetes tokens, then shipped whatever it found off to a typosquatted domain. Any team pinning their workflow to a mutable version tag, instead of a fixed commit digest, was exposed and had no way of knowing it at the time.

The lesson reaches past Trivy specifically. Pinning to a commit SHA in CI rather than a version tag is baseline hygiene for any GitHub Action that touches your secrets. Treating it as optional hardening is how teams get caught out. Trivy just happened to be the project that made the stakes visible to a lot of teams at once, and honestly, it probably won't be the last one. If you need the full-surface coverage it offers, keep using it. Just pin it the way you'd pin any dependency that runs with access to your credentials.

Grype's design philosophy: one job, precise results, SBOM-first workflow

Grype takes the opposite bet from Trivy. Its scope is deliberately narrow: container images, directories, filesystems, and SBOMs. No infrastructure-as-code scanning, no Kubernetes awareness, no secrets detection. That's the design.

Because it does one thing, it does that thing fast. In pure vulnerability scanning, Grype runs somewhere around 30 to 40% faster than Trivy, mostly because it isn't dragging along a dozen scan modes it doesn't need. Speed is nice. Accuracy is the claim that actually matters here, and it's worth digging into. After triage on a 500-image enterprise test set, Trivy produced roughly 18% more findings than Grype, and about 60% of that surplus turned out to be false positives, driven mostly by distro maintainers backporting security fixes without bumping the package's version string. Grype's curated database, grype-db, leans on tighter version matching specifically to cut down on that category of noise.

Grype also supports Vulnerability Exploitability eXchange (VEX) documents, which let a team formally suppress findings already confirmed non-exploitable in their own environment. That's a bigger deal than it sounds, especially in regulated industries, where every false positive a human has to manually clear is a real compliance cost, not just an engineering annoyance.

The more interesting piece, at least to me, is how Grype pairs with Syft. Syft builds a full software inventory of an image, an SBOM, once. Grype then re-scans that same SBOM against updated vulnerability feeds as new CVEs get published, without ever re-pulling or re-unpacking the image itself. That decouples the build event from ongoing monitoring entirely: a genuinely different mental model than Trivy's scan-on-demand approach. Both Syft and Grype ship under Apache 2.0, with no telemetry and no paid tier hiding the useful bits behind a wall. Teams that like a modular pipeline, where the scanner does one job and separate tools cover IaC, secrets, and SBOM generation, tend to end up here.

Clair and Docker Scout: the registry-native options

Clair and Docker Scout both sit closer to the registry than to a CI pipeline, which changes the whole question you're asking. The question shifts from which scanner to add to your build to what's already scanning images by the time they land.

Clair was built to analyze images as they hit a registry, not as a discrete CLI step buried somewhere in a build script. It powers Quay.io's vulnerability scanning and runs as a long-running service that ingests image layers over an API and performs layer-by-layer static analysis. That layer-level view is genuinely useful: it can tell you which specific layer introduced a given vulnerability, something a flat scan of the finished image usually can't answer cleanly. Clair skips infrastructure-as-code scanning, Kubernetes scanning, and secrets detection entirely, narrower even than Grype, and on purpose. Development has slowed since the CoreOS era; Clair v4 was a real architectural rewrite, but adoption still trails Trivy and Grype in the wider community. In practice, if you're running Quay or OpenShift in 2026, Clair is probably already scanning your registry. The decision isn't whether to adopt it, but how to configure what's already sitting there.

Docker Scout takes the same registry-native idea and bakes it straight into the Docker workflow people already use every day: Docker Desktop, the Docker CLI, Docker Hub. About as low-friction an entry point as this category gets. It handles real-time image analysis, base image comparisons, fix recommendations, and SBOM generation for Docker Hub images. It doesn't touch IaC, Kubernetes, Git repos, or secrets. Its scope stops right at the Docker-native boundary. Pricing includes a free basic plan covering a limited number of repositories plus unlimited public images, with paid tiers at $9/month for Pro, $15 per user per month for Team, and $24 per user per month for Business. Worth mentioning alongside Scout: Docker's Hardened Images, a distroless line launched in 2025, aim for near-zero CVEs with a claimed 95% reduction in image size. Useful context if you're trying to figure out how much of your CVE count actually lives in the base image versus your own application dependencies. Both Clair and Docker Scout reward a threat model that starts at the registry rather than at the build step, a genuinely different posture than what Trivy or Grype assume.

The tools that don't make the shortlist and why

Dagda deserves a mention, if only because its core idea is unusual: it pairs static CVE scanning with runtime monitoring, watching Docker's event stream and integrating with Falco. That's a real capability gap most scanners don't even try to fill. Even so, Dagda sits around 1,222 GitHub stars, a small community by any measure, and it depends on MongoDB, which is operational overhead most teams have zero appetite for in 2026. Teams that actually want static scanning and runtime monitoring together are usually better served running Trivy alongside a dedicated runtime tool. That combination delivers more depth and a far better maintenance cadence than Dagda does on its own.

Tern is a Python-based SBOM generator that scans both Dockerfiles and built images, a genuinely useful niche back when it was active. Its last release, v2.12.1, shipped in July 2023. Effectively unmaintained territory for anyone making a decision today. Teams evaluating SBOM generation now reach for Syft almost by reflex, partly because it's actively maintained, and partly because it slots directly into the Grype workflow covered above.

Why scanner accuracy is harder than finding counts suggest

Academic research measuring container scanners at the package-version-matching level, the approach every tool here uses in some form, found a false positive rate around 92.0%. That number is worth sitting with, because it means the dominant scanning method in this entire category is, by design, noisy in a specific and predictable way. It is a structural property of the approach itself, not a bug in any one tool.

Why does version matching over-report in the first place? A scanner flags a package because its version string falls inside a range known to be vulnerable. But distro maintainers routinely backport a security fix into an existing package without bumping the version number, because that's how Linux distribution patching has worked for decades. The fix is real. The scanner just can't see it, because all it's reading is a string.

But what about the other direction? The false negative problem is the flip side, and arguably the scarier one: real vulnerabilities sitting in an image that a scanner simply doesn't flag. That's the more dangerous failure mode, since a false negative never shows up anywhere for a team to triage. It just sits there, quietly, until it doesn't.

Put those two failure modes together and finding count stops being a useful proxy for scanner quality on its own. A tool that reports more CVEs might just be worse at recognizing backport patches, rather than more thorough. A tool that reports fewer might be missing real vulnerabilities, rather than running cleaner. It's also worth considering that Trivy and Grype both pull from the same underlying sources: NVD, GitHub Security Advisories, Linux distro security trackers. Whatever divergence shows up in their output comes entirely from matching logic and database curation, not from one tool having access to information the other lacks. So what does that mean for building a pipeline? Scanner output is a starting point for triage, never a verdict on its own. Every team needs an explicit policy on which severity levels actually block a build and which just get filed for later, because the raw finding count won't tell you that by itself.

How to pick the right scanner for your pipeline

Start with scope. If you only need to scan images and want the cleanest possible signal, Grype paired with Syft for SBOM persistence is the tighter combination. If you need images plus infrastructure-as-code, Kubernetes, secrets, and Git repos all under one tool, Trivy casts the wider net, with the caveat already covered: pin to a digest, never a mutable tag. If you'd rather scanning just happen automatically at the registry with no separate CI step at all, Clair fits teams already running Quay or OpenShift, and Docker Scout fits teams already living inside the Docker Hub ecosystem day to day.

Then think about pipeline philosophy, because underneath the tooling question is really a question about how your team likes to build things. A monolithic approach, where one tool owns the whole surface, points toward Trivy. A modular, SBOM-first approach, where separate tools handle inventory, scanning, and runtime monitoring on their own, points toward Syft plus Grype plus whatever runtime layer you trust.

False-positive tolerance matters too, and this is where the accuracy discussion above actually earns its keep. Regulated environments with strict build gates and low patience for noise do better with Grype's curated database and VEX support, since every false positive there costs real compliance time, not just engineering annoyance. Teams that can absorb more triage work in exchange for broader coverage may prefer Trivy's wider net, even knowing it surfaces more findings a human will have to sort through by hand.

One more axis, and it's the one most teams skip entirely: supply-chain posture. The Trivy incident is a reminder that a scanner is itself a dependency that runs in CI with access to your secrets and credentials. Every team, whichever tool they land on, should pin to digests and verify signatures on anything running in that context. This is a lesson about running third-party code in CI generally, and it reaches well past anything specific to Trivy.

If you want a single starting point rather than a philosophy debate: run Trivy in CI for breadth, pair it with Grype in a nightly SBOM-diff job for precision, and let your registry, whether that's Quay or Docker Hub, handle the push-time layer on its own. A few tools, each doing the one part it is actually good at, tend to serve a team better than any single tool trying to do all of it at once.