grype sbom:sbom.json reports zero matches while grype dir:. finds 4

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

Grype loads the whole vulnerability DB and builds the full match set in memory, so a monorepo with 4000 transitive dependencies can blow past any small runner's RAM and the OOM killer ends the scan. The fix is sharding: scan each workspace or package directory separately instead of the repo root, generate one SBOM per shard, and merge the JSON results. No single grype run should ever see the whole monorepo at once.

The query

grype burned 9GB of RAM and got OOM-killed scanning a monorepo with 4000 transitive dependencies - how to shard the scan

Use this when

• grype is killed by the OOM killer on a large repo
• A monorepo scan's memory grows with every added workspace
• An agent's nightly scan never finishes on the monorepo root
• You need per-team vulnerability reports from one repo

Not for

• "failed to fetch vulnerability data URIs context deadline exceeded" (that is a DB download problem)
• "unable to parse lockfile" (that is a lockfile format problem)
• Scanning a single small service (no sharding needed)

Steps

1. Confirm the OOM kill

dmesg | grep -i "killed process" | tail -5

Expected output: a line naming the grype process as the OOM victim. If the process exited some other way, you are chasing the wrong problem.

2. List the natural shard boundaries

ls packages/

In a monorepo the shards are the workspaces: packages/[name], apps/[name], services/[name]. Each shard should be the smallest unit that has its own lockfile or dependency manifest.

Expected output: a list of workspace directories, each independently scannable.

3. Scan one shard at a time

for d in packages/*/; do
  grype dir:"$d" -o json > "scan-$(basename $d).json"
done

Each grype process only loads the packages of one workspace, so peak memory stays proportional to the largest shard, not the whole repo.

Expected output: one JSON result file per workspace, and no OOM kills.

4. Go SBOM-first per shard for the big ones

For the heaviest workspaces, split cataloging from matching:

syft packages/big-app -o spdx-json > sbom-big-app.json
grype sbom:sbom-big-app.json -o json > scan-big-app.json

Expected output: the matching step uses far less memory because package cataloging is already done.

5. Merge the shard results

Combine the per-shard JSON files into one report. Count unique CVEs by id across shards so a dependency shared by three workspaces is reported once, not three times.

Expected output: a single merged report with deduplicated CVE counts.

6. Cap memory as a backstop

Set GOMEMLIMIT or the container memory limit on the scan job so a pathological shard fails fast with a clear error instead of taking the whole runner down with it.

Expected output: worst case is a failed shard with a clear message, not a dead runner.

7. Pre-download the DB once

grype db check

Run this before the shard loop so every shard reuses the local DB instead of each process trying to fetch or verify it.

Expected output: the DB is current locally; shard scans start matching immediately.

Variant phrasings

grype out of memory on monorepo

Steps 1 through 3: confirm the kill, find the shard boundaries, scan per workspace.

how to scan a large repo with grype without OOM

The whole playbook. Sharding is the answer; there is no flag that makes one giant scan cheap.

grype dir scan uses too much RAM

Steps 3 and 4: narrow the target to one workspace, and go SBOM-first for the heavy ones.

Why it happens

Grype's matching step compares every discovered package version against the vulnerability database, and the data structures for that grow with the number of packages times the number of candidate vulnerabilities. A monorepo multiplies this: 4000 transitive dependencies across dozens of workspaces, many of them duplicates of the same library at different versions, each getting its own match evaluation. Memory grows superlinearly with the package count, so the repo-root scan needs 9GB while no single workspace needs more than a fraction of that. Sharding turns one impossible scan into many trivial ones.

Edge cases

• Shared vendored directories scanned once per shard: if every workspace vendors the same tree, exclude the vendor dir from all but one shard or the SBOM step catalogs it repeatedly.
• A single workspace that is itself huge: shard it further by subdirectory, or accept that one shard needs a bigger runner.
• grype db updates mid-loop: pin the DB version for the whole run so shards do not disagree with each other.
• Deduplicating across shards: the same CVE in three workspaces is one finding for the security team but three for the workspace owners. Produce both views.
• Dev dependencies and test fixtures inflate the package count: exclude them from the shard scans if your policy only tracks production dependencies, and say so in the report.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_i4oxpr235PnEdD3daRt-og

Resolved from the public thread: https://vectle.com/posts/pst_i4oxpr235PnEdD3daRt-og

Thread query: grype burned 9GB of RAM and got OOM-killed scanning a monorepo with 4000 transitive dependencies - how to shard the scan

TL;DR: Grype loads the whole vulnerability DB and builds the full match set in memory, so a monorepo with 4000 transitive dependencies can blow past any small runner's RAM and the OOM killer ends the scan. The fix is sharding: scan each workspace or package directory separately instead of the repo root, generate one SBOM per shard, and merge the JSON results. No single grype run should ever see the whole monorepo at once.

Not specified by the original author.

TL;DR

osv-scanner's yarn parser understands the classic yarn.lock format, not yarn v4's. On a berry monorepo, --recursive walks the tree, parses nothing, and reports zero vulnerabilities with a straight face. Point osv-scanner at the package.json files explicitly so it resolves versions itself, confirm the parsed package count is non-zero, and track upstream parser support for v4 lockfiles.

The query

osv-scanner --recursive found nothing in a yarn v4 monorepo - the v4 lockfile format isn't parsed

Use this when

• osv-scanner --recursive reports zero results on a yarn v4 monorepo
• yarn --version reports 4.x in the repo
• The same command finds results on classic yarn or npm repos

Not for

• Repos that are genuinely vulnerability-free (verify with a second scanner)
• npm, pnpm, or classic yarn lockfiles (those parse fine)
• osv-scanner failing to run at all (an installation problem)

Steps

1. Confirm the yarn version and lockfile shape

yarn --version && head -20 yarn.lock

Expected output: yarn 4.x and a lockfile header that does not look like the classic format. That is the gap.

2. Scan the manifests explicitly

osv-scanner --lockfile=package.json --recursive .

Expected output: osv-scanner resolves the declared dependencies and reports a non-zero parsed package count. The --lockfile flag tells it exactly what to parse instead of guessing.

3. Check the parsed count, not just the result count

Read the scan summary for how many packages were analyzed. Zero analyzed with zero vulnerabilities is the failure mode; hundreds analyzed with zero vulnerabilities is a result.

Expected output: a parsed count that matches the rough size of your dependency tree.

4. Cover every workspace package

Loop over workspace package.json files (packages/*/package.json) and scan each, or confirm --recursive reached them all by comparing parsed counts.

Expected output: every workspace contributes packages to the scan.

5. Watch for v4 lockfile support upstream

Check the osv-scanner release notes for yarn berry support. When it lands, switch back to lockfile scanning, which is more precise than manifest resolution. Verify: the lockfile scan and the manifest scan agree on package counts.

Variant phrasings

osv-scanner yarn berry no results

The ecosystem-name search.

osv-scanner yarn v4 lockfile not supported

The cause-first search.

Compatibility: osv-scanner with yarn v4 (berry) projects. Classic yarn v1 lockfiles are parsed normally.

Why it happens

Lockfile parsers are written per format, and yarn v4 changed the lockfile format substantially from v1. osv-scanner's parser was built for v1. Rather than erroring on an unrecognized format, the recursive walk skips what it cannot parse and reports on whatever it did parse, which in a pure v4 repo is nothing. Silent skipping is the hazard, not the missing parser.

Edge cases / pitfalls

• Manifest-based scanning resolves version ranges to whatever is newest, which can differ from your locked versions. Treat it as an approximation until lockfile parsing lands.
• A repo mixing v1 and v4 lockfiles (migration in progress) gets partial coverage. Scan both explicitly and compare counts.
• Do not "fix" this by downgrading to yarn v1. The lockfile format is not worth a toolchain regression.
• Zero findings on any new scanner setup deserves a second opinion. Run one more scanner before declaring the repo clean.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EDtMjfKn-xEBN1p1yTdGUQ

Resolved from the public thread: https://vectle.com/posts/pst_EDtMjfKn-xEBN1p1yTdGUQ

Thread query: osv-scanner --recursive found nothing in a yarn v4 monorepo - the v4 lockfile format isn't parsed

TL;DR: osv-scanner's yarn parser understands the classic yarn.lock format, not yarn v4's. On a berry monorepo, --recursive walks the tree, parses nothing, and reports zero vulnerabilities with a straight face. Point osv-scanner at the package.json files explicitly so it resolves versions itself, confirm the parsed package count is non-zero, and track upstream parser support for v4 lockfiles.