Vulnerability reported on @group/name dependency when actual vulnerability exists on name dependency

[lmco-seth]

What happened:

Grype reports a Vulnerability for colors when the package in the SBOM is @colors/colors. The SBOM is a demo sbom from the cyclonedx-node-npm project. juice-shop example.

This appears to be caused by Grype ignoring the group entry in the SBOM as the NPM scope is stored in group parameter.

Running grype --output table <demo-bom.json> produces --

 ✔ Vulnerability DB                [no update available]  
 ✔ Scanned for vulnerabilities     [52 vulnerability matches]  
   ├── by severity: 12 critical, 13 high, 26 medium, 1 low, 0 negligible
   └── by status:   44 fixed, 8 not-fixed, 0 ignored 
[0001]  WARN merging packages have with different pURLs: "bb5ff84367124522"="pkg:npm/%40types/cookie@0.4.1#types/cookie" vs "bb5ff84367124522"="pkg:npm/cookie@0.4.1"
[0001]  WARN merging packages have with different pURLs: "235cdbe593f0b054"="pkg:npm/%40types/strip-bom@3.0.0" vs "235cdbe593f0b054"="pkg:npm/strip-bom@3.0.0"
[0001]  WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none
NAME                  INSTALLED  FIXED-IN  TYPE  VULNERABILITY        SEVERITY 
base64url             0.0.6      3.0.0     npm   GHSA-rvg8-pwq2-xj7q  Medium    
colors                1.5.0                npm   GHSA-gh88-3pxp-6fm8  High           
...(excluded for readability)

GHSA-gh88-3pxp-6fm8 is for colors not @colors/colors

What you expected to happen:

I would expect Grype to identify the package as @colors/colors and provide vulnerabilities for this package. If I manually prepend the group field to the name Grype no longer reports GHSA-gh88-3pxp-6fm8.

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

1. Download the demo sbom
2. Run grype --output table <demo-bom.json>
3. See colors in the vulnerabilities
4. Change "name": "colors" to "name": "@colors/colors"
5. Re-run grype --output table <demo-bom.json>
6. See no vulnerabilities for colors

Anything else we need to know?:

This format from the cyclonedx demo appears to the be the intended format by the CycloneDX spec and is supported by the PURL spec.

Environment:

• Output of grype version:

  grype version
  Application:         grype
  Version:             0.73.3
  BuildDate:           2023-11-18T13:05:51Z
  GitCommit:           dbe2a9515a99ef1c78e22ead0cbf17b29fb1b674
  GitDescription:      v0.73.3
  Platform:            linux/amd64
  GoVersion:           go1.21.4
  Compiler:            gc
  Syft Version:        v0.97.1
  Supported DB Schema: 5

• OS (e.g: cat /etc/os-release or similar):

cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

[tgerla]

Hi @lmco-seth, thanks for the report! It looks like we probably need to improve the CycloneDX importer to handle this case. We will put this in our backlog for a fix.

[lmco-seth]

Thank you! Just wanted to make sure it was known.

[james-tran-3005]

I have the same issue when it report lodash@4.14.202 vulnerability instead of @types/lodash@4.14.202 on NPM

[VeselyT]

We are experiencing the same issue with @sentry/electron@4.24.0 being reported as electron@4.24.0.