npm lockfile: CDN-resolved SheetJS releases are reported against npm-registry ranges

[j-del-fel]

Problem

OSV-Scanner reports GHSA-4r6h-8v6p-xvw6 and GHSA-5pgg-2g8v-p4x9 for SheetJS CE 0.20.3 when an npm lockfile resolves the package directly from the official SheetJS CDN rather than the npm registry:

{
  "node_modules/xlsx": {
    "version": "0.20.3",
    "resolved": "https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz",
    "integrity": "sha512-oLDq3jw7AcLqKWH2AhCpVTZl8mf6X2YReP+Neh0SJUzV/BdZYjth94tG5toiMB1PPrYtxOCfaoUCkvtuH+3AJA=="
  }
}

The emitted OSV ranges contain only introduced: 0, so 0.20.3 is reported as affected. The source GHSA records carry database_specific.last_known_affected_version_range values of < 0.19.3 and < 0.20.2, respectively.

Primary evidence

• SheetJS advisory CVE-2023-30533 says all versions through 0.19.2 are affected and to upgrade to 0.19.3 or later: https://cdn.sheetjs.com/advisories/CVE-2023-30533
• SheetJS advisory CVE-2024-22363 says all versions through 0.20.1 are affected and to upgrade to 0.20.2 or later: https://cdn.sheetjs.com/advisories/CVE-2024-22363
• Official 0.20.3 artifact: https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz
• Independently calculated SHA-512 of that official tarball, expressed as SRI, is sha512-oLDq3jw7AcLqKWH2AhCpVTZl8mf6X2YReP+Neh0SJUzV/BdZYjth94tG5toiMB1PPrYtxOCfaoUCkvtuH+3AJA==.

This exact upstream-data problem was raised in google/osv.dev#4313. An OSV maintainer explained that the records are for the npm registry and that scanners “shouldn't be querying the npm ecosystem for non-npm-registry packages”: google/osv.dev#4313 (comment). A proposed GHSA fixed event was rejected because 0.20.2 was not published to npm: github/advisory-database#6477 (comment).

Requested behavior

When parsing npm/yarn lockfiles, please distinguish a package resolved from a non-registry tarball URL from the npm-registry package before querying the npm ecosystem, or otherwise avoid classifying versions outside the source advisory's last-known-affected range as vulnerable. This is similar in principle to the source-aware work discussed in #2850, but this case uses an HTTPS tarball rather than a git commit.

I am not requesting suppression or a change to raw result counts. I am asking for source-aware matching so the scanner does not apply npm-registry-only range semantics to verified vendor-CDN bytes.

Please let me know if a smaller lockfile reproducer or scanner version/output is needed.

[haxonittech]

Hey, can I pick this up? I traced it into osv-scalibr, where the tarball URL gets dropped before matching. I would start by keeping that source info through to the matcher.

I will also check that registry packages still get matched normally and external packages stay visible when we can’t assess them. Does that scope sound right?

[G-Rath]

I think this will probably require some further discussion as there's a lot of valid resolved values for NPM packages that is not the npm registry.

For example, Yarn defaults to its own registry mirror of the NPM registry (https://registry.yarnpkg.com), and companies often use their own proxies for the registry.

I'm not sure if there is a way we can reliably infer from the lockfile alone that a particular package does not belong to the NPM ecosystem

[haxonittech]

Yeah, fair point, A different host could just be a registry proxy, so resolved alone wouldn’t be enough. I will compare the SheetJS case with some npm/Yarn mirror examples and check whether the dependency specs give us anything reliable to go on. I will bring those examples back here before proposing a matching change.