Grype: Vulnerability Scanning for Images and Filesystems
Grype scans container images and filesystems for known vulnerabilities. It is deliberately narrower than Trivy, doing one job and pairing with Syft for the inventory side.
Using it
# An image
grype nginx:latest
# A directory
grype dir:/path/to/project
# Only actionable findings
grype nginx:latest --only-fixed
# From an SBOM Syft produced
syft nginx:latest -o json | grype
That last form is the one that explains the design. Syft catalogues what is present and produces an SBOM; Grype matches that inventory against vulnerability data. Separating the two means the inventory can be generated once, stored, and rescanned later as new vulnerabilities are published, without rebuilding or re-pulling the image.
Why that separation is useful
A vulnerability that becomes public tomorrow affects an image you built last month. You do not need the image to find out; you need its SBOM.
For anything you ship or keep long term, storing SBOMs and rescanning them periodically is a better model than scanning images on demand and hoping you remember to.
Output and automation
grype nginx:latest -o json > results.json
grype nginx:latest --fail-on high # non-zero exit for CI
The --fail-on flag makes it a gate in a pipeline rather than a report nobody reads.
Reading results properly
The same caveat as any scanner. Findings are known vulnerabilities in packages present, not proof of exploitability. Many will be in code your application never invokes, and some have no fix available.
--only-fixed is the flag that turns a long list into a short one you can act on.
Grype or Trivy
Grype if you value the SBOM-first workflow and are already using Syft, or prefer smaller tools that compose.
Trivy if you want one tool covering vulnerabilities, misconfiguration, secrets, and Kubernetes.
Both are good. Running both occasionally is not unreasonable, since their vulnerability matching differs slightly.
License
Grype is released under the Apache License 2.0.