regression: Grype 0.54.0 does not find vulnerabilities in Nodejs runtime itself anymore

[sseide]

What happened:
After an update from 0.53.1 to 0.54 we realized that Grype scanner does not find any vulnerability in the nodejs runtime itself anymore. It happens for different Nodejs runtimes 12.x / 14.x / 16.x - all open vulnerabilities are not reported anymore.

What you expected to happen:
Old scanner versions (up to 0.53.1) reported the following vulnerabilities (only taken HIGH/CRITICAL into account, there are multpile MEDIUM as well):

Alpine 3.14:

• old versions reported:
  node 14.20.1 CVE-2022-35256 Critical
  node 14.20.1 CVE-2022-43548 High

• new version reports nothing

Alpine 3.16 with OS package "nodejs"

• old version reported:
  node 16.17.1 CVE-2022-43548 High

• new version reports nothing

How to reproduce it (as minimally and precisely as possible):

Our Dockerfile is quite simple in regard to this packages (alpine version does not matter really - it just installs different version of Nodejs, all with open issues at time):

FROM alpine:3.16
RUN apk update && apk upgrade && apk add nodejs npm    # ... and some more package

As can be seen in the Alpine security database these vulnerabilities are not fixed by now and no false positives:
e.g. https://secdb.alpinelinux.org/v3.16/main.json

Anything else we need to know?:

Environment:

• Output of grype version: 0.54.0
• OS (e.g: cat /etc/os-release or similar): Alpine (3.14 up to 3.17)

[wagoodman]

(context: adding filtering label since this may be related to the file-by-overlap filtering we are applying to results when there are binary types)

[spiffcs]

Running the latest version of syft when building the above alpine:3.16 image

node                                16.17.1                binary
node-gyp                            9.0.0                  npm
nodejs                              16.17.1-r0             apk

The latest version of grype filters out the binary result which causes matching to only happen against the nodejs 16.17.1-r0 apk entry.

The original match was using nvd against the binary result. If this result is filtered out then we only match against the alpine data:

Pulling the latest vulnerability db I only see entries for the following:

134874 | CVE-2022-43548 | node.js | nvd:cpe |   | >= 14.0.0, <= 14.14.0 \|\| >= 16.0.0, <= 16.12.0 \|\| = 19.0.0 \|\| >= 16.13.0, < 16.18.1 \|\| >= 14.15.0, < 14.21.1 \|\| >= 18.0.0, <= 18.11.0 \|\| = 18.12.0 | unknown | ["cpe:2.3:a:nodejs:node.js:*:*:*:*:-:*:*:*","cpe:2.3:a:nodejs:node.js:19.0.0:*:*:*:-:*:*:*","cpe:2.3:a:nodejs:node.js:*:*:*:*:lts:*:*:*","cpe:2.3:a:nodejs:node.js:18.12.0:*:*:*:lts:*:*:*"] |   |   | unknown |  
266444 | CVE-2022-43548 | nodejs | alpine:distro:alpine:3.17 |   | < 18.12.1-r0 | apk |   | [{"id":"CVE-2022-43548","namespace":"nvd:cpe"}] | ["18.12.1-r0"] | fixed |  
281643 | CVE-2022-43548 | nodejs | alpine:distro:alpine:edge |   | < 18.12.1-r0 | apk |   | [{"id":"CVE-2022-43548","namespace":"nvd:cpe"}] | ["18.12.1-r0"] | fixed |  

Does the CVE not existing in the alpine:distro:alpine:3.16 namespace limit the ability for this match to populate?

We probably should just be matching against NVD and only using the above database to turn things off.

[westonsteimel]

Hmm @spiffcs, but isn't that already how the APK matcher is supposed to be working? Remember that it works differently from the other matchers and gathers matches from NVD and then uses the alpine entries to deselect.

[westonsteimel]

Does this maybe indicate we just need more robust upstream matching for the APK matcher? This is only a guess as I haven't looked at the data, but is it possible the upstream from the APK metadata is nodejs and since the NVD data only has an entry for node.js it fails to find any NVD entries in that case?

[kzantow]

An update here:
Alpine 3.14 has node 14.20.1-r0, which has this vulnerability: GHSA-r934-m2c7-26gh however, GHSA-rc2m-q589-vpqx is a false positive and was fixed in 14.20.1-r0 according to the APK vulnerability database, the fix results in the former showing up for both of these cases but does not include the FP.