Most of the pages ranking for "Trivy vs Grype" answer the wrong question. They line the two tools up on a single-image speed benchmark, declare Grype 30 to 40 percent faster, and call that a decision. It isn't. These are not two builds of the same product. They do two different jobs, and swapping one in for the other is exactly how you end up with a gap in your pipeline that nobody notices until an auditor does.

And here's the part the benchmark posts skip entirely: in the first quarter of 2026, both tools had a defining incident. One went blind. The other got backdoored. Neither shows up in a feature matrix, and both change how you should be running these scanners right now.

They are not competitors, they are different jobs

Trivy, from Aqua Security, is the all-in-one DevSecOps scanner. One binary covers container images, filesystems, git repos, VM images, and live Kubernetes clusters, plus IaC misconfiguration checks, secret scanning, and license scanning. You point it at almost anything and it tells you what's wrong.

Grype, from Anchore, does one thing. It matches packages against known CVEs. No IaC, no secrets, no license compliance. It is the vulnerability-matching half of a pipeline, and its other half is Syft, Anchore's SBOM generator. Syft builds the bill of materials, Grype scores it.

So the real question was never "which is faster." It's "what job am I filling." If you want a single tool for CVEs and misconfig and secrets and cluster posture, that's Trivy. If you're building an SBOM-first supply chain and want a clean, auditable matcher on top of a generated bill of materials, that's Syft plus Grype. Choosing Grype to cover Trivy's IaC scanning, or Trivy to replace a dedicated SBOM flow, means quietly dropping capability you may be assuming you have.

The speed gap is real and mostly a distraction

Multiple 2026 comparisons do put Grype ahead: roughly 30 to 40 percent faster on pure vulnerability matching, around 0.7 seconds versus 1.2 seconds per scan with a warm cache. Fine. But on a cold first scan of a 500 MB image, both land near 8 to 9 seconds, and in a pipeline that already burns minutes building and pushing layers, half a second of matcher time decides nothing.

I've never once had a platform team come to me and say the image scan was the bottleneck in their build. The bottleneck is the base image download, the layer export, the registry round-trip. Picking your security scanner on a 0.5s delta is optimizing the wrong number. If speed genuinely matters to you, it's usually because you're running the scan hundreds of times an hour, and at that point cache behavior and DB freshness matter far more than a warm-cache micro-benchmark.

Grype quietly went blind on March 6

Here's the incident nobody benchmarks. Per Anchore's community announcement, Grype DB schema v5 reached end of life on March 6, 2026, and publishing of v5 updates was disabled around March 9. Any Grype older than v0.88.0 stopped receiving new vulnerability data on that date.

Read that carefully, because the failure mode is nasty. The old Grype doesn't error. It keeps running, keeps exiting zero, keeps printing findings against a frozen database. A pinned-and-forgotten Grype baked into a CI image three quarters ago is now a scanner that cannot see a single CVE disclosed after early March, and your build stays green the whole time. That's the worst kind of security control: one that reports success while doing nothing.

The upgrade is not optional. Grype on schema v6 also ships something genuinely useful, which softens the pill.

What v6 actually buys you: EPSS and KEV in the database

Per Anchore's schema write-up, DB v6 embeds the CISA KEV catalog and EPSS scores directly in the database. So the output now carries an EPSS score like 0.97112 at percentile: 0.9989 sitting next to the CVSS severity. That's the difference between "this is rated High" and "this has a 97 percent modeled probability of exploitation and is already in the known-exploited catalog." One of those you can triage by. The other is a label.

The v6 archive also dropped from 210 MB to 65 MB compressed, a 69 percent cut. If you run air-gapped scanners or bandwidth-constrained runners that pull the DB on every job, that's a real operational win, not a footnote.

The scanner that finds compromised software got compromised

Now the Trivy side, and it's a darker story. Per Aqua Security's own incident write-up (GitHub discussion #10425), on March 19, 2026 a threat actor used a compromised credential to publish malicious versions of Trivy. The bad v0.69.4 went out across GHCR, ECR Public, Docker Hub, deb, rpm, and get.trivy.dev, and the latest tag pointed at it for roughly three hours, 18:22 to about 21:42 UTC. The trivy-action GitHub Action was poisoned for about twelve hours, setup-trivy for about four. Malicious v0.69.5 and v0.69.6 followed on Docker Hub on March 22 to 23.

The detail that should bother you most is the cause. Aqua notes this followed incomplete containment of an earlier March 1 incident: they had rotated secrets, but "the process wasn't atomic and attackers may have been privy to refreshed tokens." A partial rotation left a window, and the window got used. That is a textbook supply-chain lesson, and it landed on a supply-chain tool.

Aqua also paused updates to vuln-list, trivy-db, and trivy-java-db during the investigation, then restored them. So if your pipeline pulled the DB inside that window, don't assume it caught up on its own. Confirm it refreshed.

The honest limit: neither tool would have caught this

This is where I want to be blunt, because the marketing around image scanning encourages a dangerous assumption. Neither Trivy nor Grype would have flagged the poisoned Trivy binary. A backdoored release is not a package with a published CVE. Image scanning is disclosed-vulnerability detection, full stop. It tells you which known CVEs affect your packages. It does not prove the binary you pulled is the one the maintainer built.

Treating a scanner as build-provenance verification is the gap that Q1 2026 exposed. The tool you install to catch compromise is itself a dependency at your most sensitive control point, and if you pull it as latest, it's an unpinned one. The fix for compromised software was never the vulnerability scanner. It's signature and provenance verification, sitting alongside the scanner, doing the job the scanner was never built to do.

Running both scanners is a legitimate strategy in regulated shops: two independent matchers with different databases catch more than either alone. But be honest about the cost. After Q1 2026, keeping both toolchains current, both DBs fresh, both binaries pinned and verified, is real ongoing work. Two half-maintained scanners are worse than one you actually keep up.

What to fix this week

Pick by job first, then harden the runtime. Concrete steps, in the order they bite:

  1. Upgrade every Grype to at least v0.88.0 and confirm schema v6. Anything older went blind on March 6, 2026 and is scanning against a dead database while exiting zero. Grep your CI images for pinned Grype versions today.
  2. Add a DB-freshness gate. Fail the build if the vulnerability database is older than a threshold you set (a day or two for a matcher that ships daily). A frozen DB must never pass silently. This is the single check that would have caught the March 6 blind spot on its own.
  3. Pin Trivy to a known-good version. Aqua flags v0.69.3 as the safe immutable release around the incident. Pin trivy-action and setup-trivy to safe tags too, not floating ones. latest at a security control point is a liability.
  4. Verify the binary you install. Check the checksum or the Cosign signature on the Trivy you pull, in the same job that installs it. If you pulled anything in the March 19 to 23 window, re-verify against a clean release.
  5. Confirm your Trivy DB refreshed after the incident pause. Updates to trivy-db and friends were suspended during the investigation. If you cached the DB then, force a refresh.
  6. Pair scanning with provenance. Add signature and SBOM-attestation verification next to the scan. Q1 2026 proved the scanner is part of your attack surface, and no CVE matcher will ever tell you the tool itself was swapped.

Choose Trivy or Grype on the job you need covered. Then treat both as what they are: dependencies you pin, verify, and keep fresh, because the quarter just showed you what happens when you don't.

Sources