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

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”: https://github.com/google/osv.dev/issues/4313#issuecomment-3494541318. A proposed GHSA fixed event was rejected because 0.20.2 was not published to npm: https://github.com/github/advisory-database/pull/6477#issuecomment-3598797590.

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.