grype: unable to parse lockfile: unsupported package manager version

Not specified by the original author.

TL;DR: Upgrade grype to a release that supports the lockfile format - the parser lags behind package manager releases. If you cannot upgrade, regenerate the lockfile with an older lockfile version the installed grype understands, or convert it. Check grype's supported-ecosystem list before assuming the file is corrupt.

unable to parse lockfile: unsupported package manager version

1. Identify the lockfile version: open the lockfile header and note the version field. Expected: you see a version newer than what your grype supports.
2. Check your grype version against its supported lockfile versions. Expected: you confirm the gap - grype is behind the package manager.
3. Upgrade grype to the latest release and re-run. Expected: the lockfile parses and the scan proceeds.
4. If upgrading is blocked, regenerate the lockfile pinned to the older format your grype supports. Expected: grype parses the regenerated file.
5. As a stopgap, convert the lockfile to an SBOM with a compatible tool and scan the SBOM instead. Expected: coverage without waiting on the upgrade.

Use this when

• grype cannot parse a lockfile
• the package manager is newer than grype
• lockfile version errors appear right after a toolchain upgrade
• the lockfile itself opens fine in the package manager

Not for this skill when

• the lockfile is corrupt or truncated
• grype parses it but reports no packages
• the issue is a different parser error
• the package manager itself cannot read the file

Variant phrasings

• grype unsupported lockfile version
• grype unable to parse lockfile
• grype lockfile format not supported
• grype package manager version not supported

Why it happens

Package managers periodically bump their lockfile format. Grype's parsers are written per format version, so a lockfile from a newer release hits the "unsupported version" guard until grype ships an updated parser - the file is fine, the reader is just old.

Edge cases

• some package managers write a forward-compatible version marker but old content - the version field is what grype checks
• monorepos mixing lockfile versions need per-directory scans with the right grype
• upgrading grype can change the vulnerability database schema too - update both together
• lockfiles generated with experimental flags may carry a version grype will never support - regenerate without the flag

Provenance

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

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

Thread query: grype: "unable to parse lockfile: unsupported package manager version"

TL;DR:

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

Point syft at the lockfile, not the directory tree. Cataloging 90,000 files one by one is what eats the memory; the package-lock already lists every package and version, so scanning it directly gives the same SBOM at a fraction of the cost.

syft OOM'd generating an SBOM for a node_modules tree with 90,000 files - the agent's SBOM step kept dying

Steps

1. Confirm the OOM is file-count driven. Check how many files sit under node_modules versus how many packages the lockfile declares.

   • Run: count files under the dependency directory and compare with the package count in package-lock.json.
   • Expected: tens of thousands of files for a few thousand packages - the files are the problem.

2. Scan the lockfile directly instead of the directory. Point syft at package-lock.json (or the equivalent for your ecosystem) so it catalogs packages from the manifest.

   • Run: syft packages file:./package-lock.json -o cyclonedx-json, writing the SBOM to a file.
   • Expected: the SBOM completes in seconds with the same package list.

3. If you must scan the tree (lockfile missing or untrusted), exclude the heaviest directories with syft's exclude option and raise the container's memory limit for the SBOM step.

   • Run: syft dir:. --exclude './node_modules/.cache' -o cyclonedx-json, writing the SBOM to a file.
   • Expected: the scan finishes; excluded paths are documented in the run log.

4. Verify parity: diff the package list from the lockfile scan against a successful tree scan of a smaller project, or against the package manager's own listing.

   • Expected: same packages and versions in both.

5. Make the lockfile scan the agent's default for this repo and keep the tree scan as a fallback only when no lockfile exists.

   • Expected: the SBOM step stops OOMing on every run.

Use this when

• Syft gets OOM-killed on a large node_modules or vendor tree.
• The SBOM step is the flakiest part of the agent's pipeline.
• A lockfile exists but the agent scans the directory anyway.
• Memory limits cannot be raised (shared CI runners, small containers).

Not for this skill when

• The OOM happens on a container image scan; that is layer-handling memory, and the fix is scanning the image manifest or raising memory.
• The lockfile is out of sync with what is installed; fix the lockfile first, or the SBOM will be wrong.
• Syft crashes with a parse error rather than OOM; that is a cataloger bug, not a memory problem.

Variant phrasings

• syft out of memory scanning node_modules
• SBOM generation killed OOM on large repo
• syft scan too slow on huge dependency tree
• how to make syft use less memory

Why it happens

Syft's directory catalogers walk every file to detect packages, and a big node_modules tree means tens of thousands of file reads, hashes, and license detections held in memory. The lockfile already contains the exact package inventory the package manager resolved, so the file walk is pure overhead - the agent was paying the cost of discovery for information that was already written down.

Edge cases

• A lockfile scan misses packages installed outside the package manager (vendored tarballs, manual copies); spot-check for those.
• Workspaces and monorepos have multiple lockfiles; scan each one or the SBOM will be incomplete.
• If the lockfile is generated mid-run by the agent itself, validate it installed cleanly before trusting it as SBOM input.

Provenance

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

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

Thread query: syft OOM'd generating an SBOM for a node_modules tree with 90,000 files - the agent's SBOM step kept dying

TL;DR: Point syft at the lockfile, not the directory tree. Cataloging 90,000 files one by one is what eats the memory; the package-lock already lists every package and version, so scanning it directly gives the same SBOM at a fraction of the cost.