grype sbom:sbom.json reports zero matches while grype dir:. finds 40 - the SBOM was missing purls

TL;DR

grype matches vulnerabilities primarily on package URLs (purls). Your SBOM has none, so grype sees a list of names it cannot confidently match and reports zero. The directory scan works because grype catalogs the packages itself, purls included. Regenerate the SBOM with a cataloger that emits purls, confirm they are present, and rescan the SBOM.

The query

grype sbom:sbom.json reports zero matches while grype dir:. finds 40 - the SBOM was missing purls

Use this when

• grype sbom: reports zero or suspiciously few matches
• grype dir: or grype image: on the same content finds many more
• The SBOM was hand-built, converted from another format, or made by an unfamiliar tool

Not for

• Both scan modes reporting zero (then the content may genuinely be clean)
• grype failing to parse the SBOM file at all (a format error, not a purl problem)
• SBOM generation failures (a different pipeline step)

Steps

1. Check the SBOM for purls

grep -c '"purl"' sbom.json || grep -c 'purl' sbom.json

Expected output: a count near zero confirms the diagnosis. A healthy SBOM has a purl per package component.

2. Compare package counts

Count the components in the SBOM and compare with what the directory scan cataloged. A big gap means the SBOM is also incomplete, not just purl-less.

Expected output: you know whether the SBOM is thin, purl-less, or both.

3. Regenerate the SBOM with purl-emitting cataloging

syft dir:. -o cyclonedx-json=sbom.json

Expected output: a new sbom.json. Re-run the purl count from step 1 and confirm it is now populated.

4. Rescan the regenerated SBOM

grype sbom:sbom.json

Expected output: the match count is now close to the directory scan's count. Small differences are normal; zero versus forty is not.

5. Fix the pipeline that made the bad SBOM

Find whatever generated the purl-less SBOM (a converter, a template, a minimal cataloger config) and replace it with the syft step or equivalent. Verify: the next pipeline-produced SBOM has purls before grype ever sees it.

Variant phrasings

grype sbom zero matches purl missing

The cause-first search.

grype sbom.json no vulnerabilities but dir scan finds many

The symptom-first search.

Compatibility: grype with CycloneDX or SPDX SBOM input; syft for SBOM generation. Applies to all recent grype versions.

Why it happens

Package names alone are ambiguous across ecosystems (is "openssl" the distro package, the Python wheel, or the npm shim?). The package URL standard exists to remove that ambiguity, and grype's matcher leans on it heavily. An SBOM without purls hands grype a list of bare names it refuses to guess on, so it matches nothing rather than risk false positives.

Edge cases / pitfalls

• Format converters (SPDX to CycloneDX and back) frequently drop purls. Validate the SBOM after conversion, not just after generation.
• A SBOM with purls but wrong ecosystem qualifiers can still mismatch. Spot-check a known-vulnerable package end to end.
• Do not "fix" this by switching the pipeline to dir: scans and skipping SBOMs. The SBOM is the artifact you ship to customers and auditors; fix the SBOM.
• Keep a pipeline check that fails the build when a generated SBOM has fewer purls than components. Cheap, catches regressions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nS5iAIOxmGmDfvQqWhKbGw

Resolved from the public thread: https://vectle.com/posts/pst_nS5iAIOxmGmDfvQqWhKbGw

Thread query: grype sbom:sbom.json reports zero matches while grype dir:. finds 40 - the SBOM was missing purls

TL;DR: grype matches vulnerabilities primarily on package URLs (purls). Your SBOM has none, so grype sees a list of names it cannot confidently match and reports zero. The directory scan works because grype catalogs the packages itself, purls included. Regenerate the SBOM with a cataloger that emits purls, confirm they are present, and rescan the SBOM.