Skip to content

Search

Search the docs, blog, and marketplace.

Grype

Last updated October 25, 2026View source (v0.30.0)

Runs Grype vulnerability matching against the resolved dependency graph. The full Bomly binary has Grype built in; the lite binary runs an external grype from PATH.

PropertyValue
Matcher namegrype
In the default --enrich setYes
Requires enrichmentYes
Uses networkNo
Cache behaviorRelies on Grype's own local vulnerability database.
Output fieldsvulnerability ID, severity, CVSS, fixed version, fix state, EPSS, CWE, known exploitation, risk score, references
Ecosystemsnpm, maven, scala, go, python, dotnet, ruby, rust, dart, elixir, erlang, php, swift, haskell, r, lua, cpp, ocaml, prolog, conda, nix, terraform, wordpress, alpm, apk, dpkg, rpm, portage, homebrew, github-actions

What grype does

grype runs Anchore's Grype vulnerability matcher against the resolved dependency graph. Grype carries its own vulnerability database, so it complements osv rather than duplicating it. Grype is the right matcher when you need consistent results across runs and full offline operation after the first database download.

The full bomly binary has Grype built in and runs it in-process. The bomly-lite binary runs a grype command from PATH.

When it runs

grype requires --enrich. A plain scan never runs it. With --enrich and no --matchers selection, grype is the default vulnerability matcher. --matchers grype runs Grype and nothing else:

bomly scan --enrich --matchers grype     # Grype only
bomly scan --enrich --matchers grype,osv # Grype and OSV (recommended)

Run it next to osv for the widest coverage. The two databases overlap heavily, but each catches advisories the other lags on.

Network

Grype reads from a local vulnerability database. The full bomly binary downloads it on first use. On every later enriched run it asks Anchore's database service for a newer build at most once every two hours, and installs one when it exists. If that check fails, the run matches against the local copy and logs a warning. Once the local copy is older than five days, the run warns, even without -v, that advisories published since then are missing. With -v, every run shows the database build date.

ModeDatabase sync sourceDatabase location
Full bomly binaryAnchore's database serviceManaged by the built-in Grype; default ~/.cache/grype/db/
bomly-liteThe external grype commandWherever that grype stores it

The database sync is the only network call Grype makes. Once synced, matching is local. Bomly's own enrichment cache does not wrap Grype, because Grype manages its own.

Three settings control the refresh in the full binary. See the config reference for the full list:

KeyDefaultMeaning
matchers.grype.db_auto_updatetrueCheck for and download a newer database. false uses the local copy as it is, and fails when there is none.
matchers.grype.db_max_age120hAge past which the run warns that the database is stale.
matchers.grype.db_update_check_interval2hMinimum time between update checks.

OS packages (apk, dpkg, rpm)

Grype matches operating-system packages through per-distribution advisory feeds, so a package only matches when Bomly can tell Grype which distribution it came from. Bomly reads that from the distro= qualifier that Syft records on the package URL while it catalogs the image. It also passes the upstream= qualifier. That way an advisory filed against a source package, such as an Alpine origin package, a Debian source package, or a source RPM, matches the binary packages built from it.

bomly scan --image alpine:3.20 --enrich --matchers grype

That qualifier is present for container-image scans and for SBOMs generated from an image. A hand-written package URL without it (pkg:apk/openssl@3.0.8-r0) has no distribution to match against and reports nothing. There is no distribution-independent advisory feed for OS packages to fall back on.

Output fields

Each vulnerabilities[] entry on a package carries:

  • id: Grype's primary ID (CVE, GHSA, or vendor ID)
  • parsed_severity: Grype's severity bucket
  • cvss: CVSS scores when available
  • fixed_in: the best single upgrade target; fixed_versions carries every fixed version Grype reported
  • fix_state and fix_available: Grype's fix status and dated fix-availability records when available
  • epss, cwes, known_exploited, and risk_score: exploitation and weakness triage signals from the Grype database
  • data_source, namespace, and cpes: source and matcher context for debugging or downstream correlation
  • references: upstream advisory and patch links

Examples

Combine Grype with OSV for the widest coverage

grype is in the default matcher set, and --matchers +osv adds OSV. An advisory both find is merged on the package:

bomly scan --enrich --matchers +osv --audit --fail-on high

Keep a fixed Grype database

When reproducibility matters, for example in nightly compliance runs, turn updates off and keep the local database as it is:

GRYPE_DB_AUTO_UPDATE=false bomly-lite scan --enrich          # lite: the external grype's own switch
BOMLY_GRYPE_DB_AUTO_UPDATE=false bomly scan --enrich         # full: keep the local database as it is

With updates off, the full binary still warns once the database is older than matchers.grype.db_max_age. Delete ~/.cache/grype/db to download a current one.

Limitations

  • Grype's container-image strength does not transfer to source scans. Grype was designed for container images. On source trees, OSV-style matching is usually as good or better.
  • Linux distribution matching (Alpine apk, Debian dpkg, RHEL rpm) is Grype's strongest area and the main reason it stays in the default set for container scans. It needs the distribution the package came from; see OS packages for when that is available.
  • bomly-lite needs a compatible grype on PATH. The full binary pins a known-compatible version. The lite binary uses whatever is installed, which may behave differently.
  • Database freshness is your job in offline environments. A database that is days old misses new advisories.