What we still need to verify : 1 point in this profile is not yet confirmed against vendor documentation.
- Current language ecosystem coverage, which expands over time: verify against project documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Grype does one thing and does it quickly: it takes an inventory of software and matches it against vulnerability data. The inventory comes either from cataloging a target directly, a container image in a registry or local daemon, an OCI archive, a filesystem path, a single archive file, or from an SBOM produced by Syft, its sibling project. Cataloging finds operating system packages from the distribution's package database and language ecosystem packages from lock files, installed metadata and archives embedded in the image.
Matching runs against a database the project assembles and publishes, combining the National Vulnerability Database with distribution security trackers for Alpine, Debian, Ubuntu, Red Hat, SUSE and Amazon Linux, plus the GitHub Advisory Database for language packages. Using distribution trackers rather than NVD alone is what stops Grype reporting every CVE against a Debian package Debian already backported a fix for, the largest source of noise in container scanning. The tool ships as a single binary, emits JSON, SARIF and CycloneDX, and exits non-zero at a severity threshold you set.
Where it fits
This is a build pipeline step and a laptop tool. Developers run it against an image they just built, and pipelines run it as a gate before pushing to a registry. Nothing has to be stood up: no server, no account, no agent. Pairing it with Syft lets you generate the SBOM once and scan it repeatedly, including rescanning historical builds without the image. It produces findings, not workflow, so anything beyond a pass or fail decision needs somewhere else to live.
Strengths
- Fast enough to run on every build without anyone complaining.
- Distribution-aware matching cuts the backported-fix false positives that make naive NVD matching unusable for containers.
- Scanning an SBOM rather than an image lets you re-evaluate old builds against new advisories without pulling the artifact.
- Output formats and exit code control make CI integration a few lines rather than a project.
Limitations
- Pure version matching, with no reachability or runtime context, so findings still need triage.
- No state. No memory of previous scans, no surviving suppression workflow, no portfolio view, so you need a companion system for anything beyond gating.
- Language package coverage depends on recognizable metadata. Vendored code, statically linked binaries and stripped builds go unseen.
Who it suits
The sensible default for any team that builds containers and wants a scanning baseline today, and a good engine behind a larger internally built pipeline. It is not enough alone for a program needing triage history, exception management, portfolio reporting or auditor evidence, and those teams should plan what sits downstream of it from the start.
Used Anchore Grype? Recommend it under your own name and title.
Recommend this tool