Trivy vs Grype: choosing a container image scanner

Both are free, fast, and catch real CVEs. The real differences are scope, databases, and workflow — a practical comparison with commands to try each.

Every CI pipeline that builds container images eventually asks the same question: which scanner do we gate on? For open-source tooling the shortlist is almost always two names — trivy from Aqua Security and grype from Anchore. Both are free, fast, single-binary Go tools that catch real CVEs and can fail a build. This post compares them the way you would actually evaluate them: scope, databases, and workflow, with the exact commands to try both on your own image.

Two scanners, one job

Both tools solve the same core problem: look inside a container image, inventory what is installed — OS packages and application dependencies (JARs, node_modules, Python package metadata, and friends) — and match that inventory against known-vulnerability data. Both are Apache-2.0 licensed, run anywhere CI runs, and return a non-zero exit code you can gate a pipeline on. The differences are everything around that core.

Trivy in one command

That one command pulls the image, walks its layers, inventories OS packages and language dependencies, and matches them against Trivy's vulnerability database — aggregated from OS vendor security feeds (Alpine, Debian, Ubuntu, RHEL, and friends), the GitHub Advisory Database, and NVD, and refreshed several times a day. Add --ignore-unfixed to hide findings that have no released fix yet, and record accepted risks in a .trivyignore file so every suppression has a paper trail.

The same binary also scans Terraform and Kubernetes manifests for misconfigurations (trivy config .), detects hardcoded secrets, and can audit a live cluster (trivy k8s, still marked experimental). If you want one tool to cover several pipeline gates, that breadth is the selling point.

Grype and the SBOM-first workflow

Grype's signature move is on line three: it scans an SBOM file instead of the image. Generate the SBOM once with Syft when you build, attach it to the release as an artifact, and from then on you can re-scan that document in seconds — nightly if you like — as vulnerability data updates, without ever pulling the image again. New CVEs surface against yesterday's build without re-running the pipeline. Grype's database is rebuilt daily from the same families of sources: distro security feeds, GitHub advisories, and NVD.

Ignore rules live in .grype.yaml, and Grype understands VEX documents — a standardized way to record “this CVE does not affect us because…” so accepted findings stay suppressed with the reason attached.

Where they actually differ

Scope. Trivy is a multi-scanner — vulnerabilities are one of several things it checks. Grype does one thing and composes with Syft and the wider Anchore toolchain. Ecosystem. Trivy feeds Aqua's commercial platform and has a Kubernetes operator for continuous in-cluster scanning; Grype and Syft anchor SBOM-first supply chains and Anchore's enterprise products. Output. Both print human tables, emit JSON and SARIF for code-scanning dashboards, and slot into any CI system the same way: scan, threshold, exit code.

Which one should you pick?

Default to Trivy when you want maximum coverage from a single binary: image vulnerabilities, IaC misconfigurations, and secret detection in one CI job with two flags. Choose Grype + Syft when you are building an SBOM-centric supply chain — SBOMs stored as build artifacts, nightly re-scans, VEX-documented exceptions — or you already live in the Anchore ecosystem. And because both are free and take minutes to wire up, running both and alerting on the union of findings is a perfectly legitimate strategy in stricter environments.

Related posts