trivy: PNPM scanning is broken, does not find any vulnerabilities

Description

Trivy does not find any vulnerabilities in pnpm-lock.yaml files at all. The pnpm audit command correctly identifies the vulnerabilites.

What did you expect to happen?

Trivy should find at least some vulnerabilities.

What happened instead?

Trivy finds none.

Output of run with -debug:

$>trivy fs --debug pnpm-lock.yaml
2023-03-08T14:56:42.404+0100	DEBUG	Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2023-03-08T14:56:42.432+0100	DEBUG	cache dir:  /Users/<redacted>/Library/Caches/trivy
2023-03-08T14:56:42.433+0100	DEBUG	DB update was skipped because the local DB was downloaded during the last hour
2023-03-08T14:56:42.433+0100	DEBUG	DB Schema: 2, UpdatedAt: 2023-03-08 06:07:29.13580037 +0000 UTC, NextUpdate: 2023-03-08 12:07:29.13579997 +0000 UTC, DownloadedAt: 2023-03-08 13:53:18.989547 +0000 UTC
2023-03-08T14:56:42.434+0100	INFO	Vulnerability scanning is enabled
2023-03-08T14:56:42.434+0100	DEBUG	Vulnerability type:  [os library]
2023-03-08T14:56:42.434+0100	INFO	Secret scanning is enabled
2023-03-08T14:56:42.434+0100	INFO	If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2023-03-08T14:56:42.434+0100	INFO	Please see also https://aquasecurity.github.io/trivy/v0.38/docs/secret/scanning/#recommendation for faster secret detection
2023-03-08T14:56:42.434+0100	DEBUG	No secret config detected: trivy-secret.yaml
2023-03-08T14:56:42.434+0100	DEBUG	Walk the file tree rooted at 'pnpm-lock.yaml' in parallel
2023-03-08T14:56:42.445+0100	DEBUG	OS is not detected.
2023-03-08T14:56:42.446+0100	DEBUG	Detected OS: unknown
2023-03-08T14:56:42.446+0100	INFO	Number of language-specific files: 1
2023-03-08T14:56:42.446+0100	INFO	Detecting pnpm vulnerabilities...
2023-03-08T14:56:42.446+0100	DEBUG	Detecting library vulnerabilities, type: pnpm, path: pnpm-lock.yaml

Output of trivy -v:

Version: 0.38.2
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-03-08 06:07:29.13580037 +0000 UTC
  NextUpdate: 2023-03-08 12:07:29.13579997 +0000 UTC
  DownloadedAt: 2023-03-08 13:53:18.989547 +0000 UTC
Policy Bundle:
  Digest: sha256:19a017cdc798631ad42f6f4dce823d77b2989128f0e1a7f9bc83ae3c59024edd
  DownloadedAt: 2023-03-08 12:21:24.762287 +0000 UTC

Additional details (base image name, container registry info…):

PNPM Version used: 7.18.2

Create a package.json with a vulnerable dependency:

{
  "name": "pnpm",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
     "lodash": "4.17.10"
   }
}

Then run pnpm install, then run trivy fs --debug pnpm-lock.yaml

Here’s the output of pnpm audit which detects the vulnerabilities:

6 vulnerabilities found
Severity: 2 moderate | 3 high | 1 critical

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 22

Most upvoted comments

any update on this?

Hello everyone!

I created #220 to fix this problem.

If you have time - can you check these testcases - https://github.com/aquasecurity/go-dep-parser/pull/220/files#diff-828b2b43cb2b887728250ad289067f4874a1e6d0a52fb6d339f1020c0f4c28ecR83 and tell me if i missed some cases.

This is an issue in https://github.com/aquasecurity/go-dep-parser/ because it doesn’t take into account absolute paths here https://github.com/aquasecurity/go-dep-parser/blob/main/pkg/nodejs/pnpm/parse.go#L103

Absolute paths are mentioned in the PNPM specification here: https://github.com/pnpm/spec/blob/master/lockfile/5.2.md#packages

I’ll prepare a PR for the go-dep-parser package

almost there, (un?)fortunately pnpm v8 got released which has inline specifiers by default, will add support for it as well.

https://github.com/pnpm/pnpm/releases/tag/v8.0.0

https://github.com/pnpm/pnpm/pull/5810 is adopted. This new format improves the readability of the lockfile by removing hashes from package IDs. It also has some rearrangement of fields in the importers section. The new pnpm-lock.yaml file is more resistant to git merge conflicts!

The registry field is removed from the resolution object in pnpm-lock.yaml.

I’m on it, will take some more times because peer dependencies are more complicated to handle.

@knqyf263 @DmitriyLewen Opened a new bug: https://github.com/aquasecurity/trivy/discussions/4551 with reproduction steps and example repo

When using the TRIVY_DEBUG=true parameter to invoke trivy on a project with a v6 lockfile the output contains various parsing errors. Fewer than before I think but still enough to fail.

Just tried with trivy 0.42.0 and got zero vulnerabilities and zero components (pnpm lock v6) Anyone else has the same fate?

@DmitriyLewen Can you please take a look?