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.
| Property | Value |
|---|---|
| Matcher name | grype |
In the default --enrich set | Yes |
| Requires enrichment | Yes |
| Uses network | No |
| Cache behavior | Relies on Grype's own local vulnerability database. |
| Output fields | vulnerability ID, severity, CVSS, fixed version, fix state, EPSS, CWE, known exploitation, risk score, references |
| Ecosystems | npm, 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.
| Mode | Database sync source | Database location |
|---|---|---|
Full bomly binary | Anchore's database service | Managed by the built-in Grype; default ~/.cache/grype/db/ |
bomly-lite | The external grype command | Wherever 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:
| Key | Default | Meaning |
|---|---|---|
matchers.grype.db_auto_update | true | Check for and download a newer database. false uses the local copy as it is, and fails when there is none. |
matchers.grype.db_max_age | 120h | Age past which the run warns that the database is stale. |
matchers.grype.db_update_check_interval | 2h | Minimum 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 bucketcvss: CVSS scores when availablefixed_in: the best single upgrade target;fixed_versionscarries every fixed version Grype reportedfix_stateandfix_available: Grype's fix status and dated fix-availability records when availableepss,cwes,known_exploited, andrisk_score: exploitation and weakness triage signals from the Grype databasedata_source,namespace, andcpes: source and matcher context for debugging or downstream correlationreferences: 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-liteneeds a compatiblegrypeonPATH. 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.