Trivy vs Grype: choosing a container image scanner

Both scanners read the same alpine:3.18.0 tar on the same morning. They agreed on 49 findings, split on 14 more and on seven severities, and exit differently; what that means for the gate.

Most Trivy-versus-Grype pages list features. The question a pipeline owner has is narrower: for the image we build, will the two tools report the same thing, and when they differ, whose number goes in the ticket? The only honest way to answer it is to hand both scanners the same bytes on the same morning and read the JSON, which is what this article does: alpine:3.18.0 pulled by digest, saved once with docker save, scanned by Trivy 0.74.0 through --input and by Grype 0.118.0 through docker-archive:, with both vulnerability databases refreshed in the same run and then frozen. The image is deliberately old (May 2023, end of life since May 2025), so it carries fixed CVEs and shows what each scanner does when the distribution feed has stopped.

What each scanner found in the same tar

Forty-nine rows are common to both: the same (package, CVE) pairs, with the same fixed versions, across busybox, busybox-binsh, ssl_client, libcrypto3, libssl3, musl and musl-utils. Every one of Trivy's rows names alpine as its data source, and every one of Grype's forty-nine has the namespace alpine:distro:alpine:3.18. Both scanners built that list from the Alpine security database, and for this image they built the same list. Grype reports fourteen more rows that Trivy does not: NVD records, matched by CPE, for busybox 1.36.0, musl 1.2.4 and zlib 1.2.13, none with a fixed version. Grype's apk matcher, in its own words, treats the distro feed as the authority and lets NVD count only where the feed is silent, and it strips the fix state from those NVD rows because an upstream release number is not an apk version. The Alpine feed for 3.18 has been silent since the branch reached end of life in May 2025, and none of these six CVEs (two published in April 2025, four in 2026) has an entry in it, so they reach Grype's table through NVD and never reach Trivy's, whose documented source for Alpine packages is the security database alone.

Recorded counts for the same image (databases of 2026-09-13; they move with every update)

Whether those fourteen rows are findings or noise depends on what you want the scanner to say about an image whose distribution has stopped tracking it. They are not wrong: busybox 1.36.0 is inside every range NVD lists. They are also not actionable inside Alpine 3.18, because no package upgrade fixes them, which is why --only-fixed moves all fourteen into ignoredMatches and leaves Grype with the same forty-nine rows Trivy prints. Trivy answers the question with a warning and, if you ask for it, an exit code. Grype answers it with rows. On a supported base image the two behaviours converge, because the distro feed is rarely silent for long; on an image past its end of life they do not, and a comparison that only ever scans alpine:latest never sees it.

Seven CVEs, two severities

Of the twenty-two CVEs both scanners agree exist, fifteen carry the same severity and seven do not. The seven are all OpenSSL, all in libcrypto3 and libssl3, and all rated LOW by Trivy while Grype says Medium, High or, for CVE-2024-5535, Critical. The JSON explains the split without guessing. Trivy's VendorSeverity map for each of the seven has no nvd entry and SeveritySource is empty: NVD has never produced its own analysis for them (their NVD status is Deferred), and Trivy's documented rule, when NVD is silent, is to take the next vendor in the trivy-db source order, which is Red Hat. Red Hat rates all seven Low, and Low is what Trivy printed. Grype's record for each carries exactly one CVSS 3.1 vector, marked Secondary, from source 134c704f-9b21-4f2e-91b3-4a467353bcc0, which NVD's source registry names CISA-ADP; the severity Grype prints is the band of that score (9.1 is Critical, 7.5 High, 4.1 to 5.9 Medium). Two defensible rules, two answers, from the same NVD page.

The seven disagreements (recorded 2026-09-13; all in libcrypto3 and libssl3 3.1.0-r4)

Exit codes: what the pipeline actually sees

The gating flags are not symmetric, and the asymmetry decides how a CI job tells an outage from a finding. Trivy exits 0 on findings unless --exit-code N is set, and the caller chooses N; its own errors exit 1. Run the popular --exit-code 1 and a missing database, a bad archive and a CRITICAL all look identical to the job. Grype's threshold exit is fixed at 2 and its errors are 1, so a wrapper can react differently to each without parsing output. Trivy has a second gate Grype does not: --exit-on-eol N returns N for an end-of-life OS, and in this run it took precedence over --exit-code when both applied. Grype has a guard that Trivy's database options do not describe: it refuses to scan with a database older than five days (db.max-allowed-built-age), exit 1, unless db.validate-age is switched off.

Exit codes observed on the same tar

Exceptions: the same CVE in two files

A gate needs a way to accept a finding for a while, and the two mechanisms differ in ways that matter for review. Trivy's .trivyignore.yaml (still marked experimental) takes an id, an optional statement and an expired_at date, and it is applied only when --ignorefile names the file. Grype's .grype.yaml ignore rules take a vulnerability, a package name, version, type or location, a fix state and VEX fields; the documented field list has no expiry and no reason, so the ticket goes in a YAML comment and the lapse is a calendar entry. Grype reads .grype.yaml from the working directory without being asked, which is convenient in a repository and surprising in a shared runner. Both accept VEX documents (--vex) for the more formal version of the same statement.

The same one-line exception turns Trivy's CRITICAL gate green and leaves Grype's red, because Grype also rates CVE-2024-5535 Critical and Trivy files it under LOW. Nothing about that split says which scanner is right, and it is not a reason to add a second ignore rule. It is a reason to open the record: an OpenSSL bug with no NVD analysis, a 9.1 from CISA's enrichment and a Low from Red Hat, fixed in 3.1.6-r0, on a base image that should have been rebuilt long before the question came up. The exception you write should name that reasoning, and in Trivy's case it can also name the date it stops applying.

SBOMs: each scanner reads its own

Both tools scan an SBOM instead of an image (trivy sbom, grype sbom:), so the SBOM-first workflow that used to be described as Grype's distinguishing feature is available on either side. What the run shows is that the SBOM has to come from the same family as the scanner that will read it. Trivy re-reading its own CycloneDX found all forty-nine rows; Grype re-reading its own found all sixty-three. Crossed over, Grype found nothing in Trivy's SBOM, and Trivy found six rows in Grype's. The reason is visible in one component. Trivy records the origin package of libssl3 as a property, aquasecurity:trivy:SrcName=openssl, and writes the distro qualifier as distro=3.18.0; Syft, which Grype embeds, writes upstream=openssl and distro=alpine-3.18.0 into the purl. Each reader ignores the other's field, so the Alpine feed, which is keyed by origin package, only matches the packages whose name is already the origin: busybox and musl. Pointing Grype at the distro by hand (--distro alpine:3.18.0) recovers exactly those six and nothing else.

For a registry of stored SBOMs this is the operational rule: generate with Syft if Grype will re-scan, with Trivy if Trivy will, and keep the image digest in the document so a scan of the image itself can settle any doubt. The SARIF shapes differ in the same spirit; a code-scanning dashboard receives one rule per CVE from Trivy and one per match from Grype, so the same forty-nine rows count differently on the two sides of a migration.

Choosing, and what this run does not settle

What one image on one day cannot tell you is which scanner is more complete, more accurate or faster in general. Both used the same Alpine feed and agreed on it; the fourteen extra rows and the seven severity splits are policy differences, not a defect on either side, and they will look different on an image whose vendor publishes its own ratings, which Trivy prefers over NVD (the Red Hat example in its documentation). Speed was not measured here, because cache state, database downloads and the host dominate a single run. Running both and reviewing the union is a legitimate choice for a strict environment, as long as the team agrees in advance whose severity decides the gate.

When the scanner is the problem: recovery in order of preference

The pipeline side of either choice is the same shape: a report pass that never blocks and a gate pass that blocks on a short list, which the Trivy in GitLab CI note builds step by step. If Syft SBOMs are going to be the artifact your registry keeps, the SBOM with Syft and Grype note covers the formats and the day a CVE lands.

Related posts

Quick reference