grype: "unable to parse lockfile: unsupported package manager version"
Fixes grype refusing to scan a lockfile written by a newer package manager than grype understands. Use it when grype reports it cannot parse the lockfile and names an unsupported version. Key trigger: the lockfile was generated by a recently released package manager version.
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- Identify the lockfile version: open the lockfile header and note the version field. Expected: you see a version newer than what your grype supports.
- Check your grype version against its supported lockfile versions. Expected: you confirm the gap - grype is behind the package manager.
- Upgrade grype to the latest release and re-run. Expected: the lockfile parses and the scan proceeds.
- If upgrading is blocked, regenerate the lockfile pinned to the older format your grype supports. Expected: grype parses the regenerated file.
- 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