Grype: scanning container images and filesystems for known vulnerabilities

What Grype is for, and who actually needs it

Grype answers a narrow question: which known vulnerabilities are present in the packages inside this image, directory or SBOM? The README describes it as "a vulnerability scanner for container images and filesystems", and the feature list covers container images, filesystems and SBOMs as scan targets, plus OS package ecosystems (Alpine, Debian, Ubuntu, RHEL, Oracle Linux, Amazon Linux and others) and language-specific packages (Ruby, Java, JavaScript, Python, .NET, Go, PHP, Rust and others).

The audience is therefore platform and security engineers who already build images and want a check they can run from a shell, a CI job or a container. It is not an agent that watches a running cluster, and it is not a static analysis tool for your own source code. If your question is "is this CVE reachable from my code path", Grype does not answer it. It answers "is the version of this package that I shipped listed as affected".

That distinction matters more than the feature list suggests. A scan result is an inventory match. Deciding what to do about it is a separate step, and the project provides material for that step through EPSS, KEV and risk scoring, which the README groups under "Threat & risk prioritization".

How a Grype scan actually flows

The repository layout shows the shape of the tool. The Go module is github.com/anchore/grype, the CLI lives under cmd/ and grype/, and the dependencies include github.com/anchore/stereoscope for reading image content and github.com/anchore/packageurl-go for package identity. Stereoscope is the piece that pulls apart a container image, so the same scanning path can be fed an image reference, a directory or an SBOM.

A scan has three stages. First, the target is resolved into a package inventory: image layers are unpacked, or a directory is walked, or an SBOM is parsed. Second, each package is matched against vulnerability data keyed by package name, version and ecosystem. Third, results are rendered, and optionally filtered or augmented with OpenVEX statements.

The database is the part teams underestimate. Grype does not ship a frozen list of CVEs; it consumes vulnerability data, and the quality of a report depends on that data being current. The README does not describe the update mechanism in detail, so the practical point is that any deployment needs a plan for refreshing the database, and an offline or air-gapped environment needs a different plan than a laptop.

The Dockerfile explains one operational constraint. The runtime image is built FROM scratch, copying only the binary and /etc/ssl/certs/ca-certificates.crt, with the comment "needed for version check HTTPS request". A WORKDIR /tmp is created because, per the file's own comment, it is "needed for image content cache". A scratch image has no shell, so you cannot exec into the container to debug a failed scan.

Installing Grype and running a first scan

The README calls the install script "the quickest way to get up and going". It downloads and installs the binary into /usr/local/bin.

curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin

After that, grype should be on your PATH. The README points to the installation docs for other channels, including Homebrew, Docker, Chocolatey and MacPorts, so Windows and macOS users are not limited to the shell script.

The first real use is scanning an image you already run. The README gives this example:

grype alpine:latest

You should see a table of matched vulnerabilities with the package, the installed version, the fixed version where one exists, and a severity. Scanning a directory works the same way:

grype ./my-project

If you already produce a Syft SBOM, scanning it is faster than re-reading the image, and the README shows both a file form and a pipe:

grype sbom:./sbom.json

cat ./sbom.json | grype

The pipe form matters for CI, because it lets one job generate the SBOM and another match it against vulnerability data without transferring the image.

Where Grype gives you less than you might expect

A match is not a verdict. Grype tells you that a package version is listed as affected; it does not tell you whether the vulnerable function is called, whether the service is exposed, or whether the configuration makes exploitation possible. Teams that pipe raw Grype output into a ticket queue quickly produce a backlog nobody reads, and the tool gets blamed for the noise it was asked to emit.

The EPSS, KEV and risk scoring features are the project's answer to prioritisation, and OpenVEX support lets you filter and augment results, which is the right mechanism for marking findings you have investigated and decided are not applicable. Using them requires someone to write and maintain those VEX statements. That is real work, and the README does not pretend otherwise.

There is also a scope limit. Grype scans OS packages and language packages. If your risk lives in application logic, in infrastructure configuration, or in a dependency that is vendored in a way the scanner does not recognise, the report will be quiet for reasons that have nothing to do with safety. The README lists supported ecosystems and links to fuller lists; checking those lists against your own stack before trusting a clean scan is the responsible move.

Finally, the scratch container image is a deliberate trade-off. Small attack surface, no shell, no package manager, no debugging tools inside. When a scan fails in that container, you diagnose from logs and flags, not from a prompt.

Grype compared with Trivy

The most common comparison is with Trivy, and the difference is mostly about packaging philosophy rather than detection. Trivy is a broad multi-purpose scanner: vulnerabilities, plus misconfiguration, secrets and other checks in one binary. Grype is narrower by design. It scans images, filesystems and SBOMs for known vulnerabilities, and it is built to sit in the Anchore ecosystem alongside Syft, which produces the SBOMs that Grype consumes.

That split has a practical consequence. With Grype, the SBOM is a first-class artifact: you can generate it once with Syft, store it, and re-scan it later without the image, which is exactly what the sbom: target and the pipe form are for. A team that wants one tool to do vulnerability scanning plus configuration and secret checks is better served by a broader scanner; a team that wants a small, scriptable matcher over an SBOM it already keeps will find Grype's shape more natural.

Both are Apache-2.0 and both are Go binaries, so the decision rarely comes down to licensing or runtime. It comes down to whether you want one tool with many jobs or two tools with one job each.

Maintenance, releases and licence terms

Grype is not archived, and the last push to the default branch was on 2026-09-18, three days before this writing. Recent releases are v0.119.0 on 2026-09-17, v0.118.0 on 2026-08-27 and v0.117.0 on 2026-08-10. That cadence, roughly every two to three weeks across the visible window, is the upgrade cost you are signing up for: the version numbers are still below 1.0, so minor releases can carry behaviour changes, and pinning is the sane default for CI.

Development is sponsored by Anchore, and the README points to commercial support options separately from the open source project. For teams that need a support contract, that path exists; for teams that do not, the community channels are a Discourse forum, a Mastodon account and regular community meetings with a public calendar and agenda.

On licensing: Grype is released under Apache-2.0, and the container image labels declare the same. Apache-2.0 is permissive and includes a patent grant, which is usually what enterprises want to see before shipping a tool internally. The Grype logo is handled separately under CC BY 4.0, so if you plan to reuse the mark in your own materials, that is a different licence from the code. This is a description of what the repository states, not legal advice; your counsel should review anything you redistribute.

Editorial conclusion

Adopt Grype if you want a single Go binary that scans images, directories and SBOMs and can filter findings with OpenVEX, and if you are willing to treat its output as match data rather than a risk decision. Do not adopt it if you need a scanner that reasons about reachability or exploitability, or if you cannot keep its vulnerability database current, since stale feeds make the report misleading. Before rolling it out, run it against one image you already know well, check that the package types you care about appear in the output, and confirm how your environment refreshes the database.

Frequently asked questions

Official sources

1. anchore/grype on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases