Parsing local yarn workspace dependencies

[spencerschrock]

osv-scanner version v2.0.2 (but applies to v1 as well)

Scanning this lockfile reports https://osv.dev/vulnerability/MAL-2024-7846

"dagster-docs@workspace:.":
  version: 0.0.0-use.local
  resolution: "dagster-docs@workspace:."

osv-scanner -L docs/yarn.lock
Scanned /tmp/dagster/docs/yarn.lock file and found 1812 packages
╭─────────────────────────────────────┬──────┬───────────┬──────────────┬─────────────────┬────────────────╮
│ OSV URL                             │ CVSS │ ECOSYSTEM │ PACKAGE      │ VERSION         │ SOURCE         │
├─────────────────────────────────────┼──────┼───────────┼──────────────┼─────────────────┼────────────────┤
│ https://osv.dev/MAL-2024-7846       │      │ npm       │ dagster-docs │ 0.0.0-use.local │ docs/yarn.lock │
│ https://osv.dev/GHSA-m5qc-5hw7-8vg7 │ 7.5  │ npm       │ image-size   │ 1.2.0           │ docs/yarn.lock │
│ https://osv.dev/GHSA-859w-5945-r5v3 │ 6.0  │ npm       │ vite         │ 6.3.3           │ docs/yarn.lock │
╰─────────────────────────────────────┴──────┴───────────┴──────────────┴─────────────────┴────────────────╯

Yet this is a local dependency, not the one from NPM. How should osv-scanner handle this scenario?

This was initially reported in Scorecard, but appears to be an issue here or osv-scalibr (feel free to move the issue if more applicable there).
ossf/scorecard#4604 (comment)

[cuixq]

I guess version 0.0.0-use.local indicates this is a local dependency - we can probably skip this version when matching against vulnerabilities.

I would prefer to have this workaround in OSV-Scanner and ask OSV-Scalibr to still return the inventory with this special version: OSV-Scalibr should return the inventories as they are in the manifests and OSV-Scanner to decide whether the version is vulnerable or not.

[spencerschrock]

0.0.0-use.local indicates this is a local dependency

I would have thought it was the @workspace:<some path> part, but I'm not a npm/yarn user.

[cuixq]

or both indicate that this is a local dependency :)

[oliverchang]

@michaelkedar knows the innards of npm manifest formats... thoughts?

[michaelkedar]

I think "pkg@workspace:." is actually referring to the root project itself (i.e. this is the yarn.lock for dagster-docs).

The yarn.lock extractor should be ignoring these, like the package-lock.json extractor ignores "" in packages.

That said, I don't know if actual workspaces use the same syntax in the yarn.lock file. We might also want to exclude those too (or at least mark them as different to an upstream package with the same name)

[rs-aewag]

IIUC the linkType could be of interest to differentiate between packages provided locally or by package managers.

(It might be feasible to purposefully elude the detection of vulnerabilities by using a linkType: "SOFT" and providing a local copy of a package. Nevertheless, IIUC, this is out-of-scope for osv-scanner.)

Example dagster

"dagster-docs@workspace:.":
  version: 0.0.0-use.local
  resolution: "dagster-docs@workspace:."
  dependencies:
    [..]
  languageName: unknown
  linkType: soft

Example jupyter-matlab-proxy

"jupyter_matlab_labextension@workspace:.":
  version: 0.0.0-use.local
  resolution: "jupyter_matlab_labextension@workspace:."
  dependencies:
    [..]
  languageName: unknown
  linkType: soft

EDIT:
It seems like at least file: protocol might be relevant as well

[aewag]

I guess version 0.0.0-use.local indicates this is a local dependency - we can probably skip this version when matching against vulnerabilities.

I would prefer to have this workaround in OSV-Scanner and ask OSV-Scalibr to still return the inventory with this special version: OSV-Scalibr should return the inventories as they are in the manifests and OSV-Scanner to decide whether the version is vulnerable or not.

I just experimented a bit and thought the function filterUnscannablePackages is a feasible location to filter local dependencies.

Easiest would be to check if the ecosystem matches NPM and if the version matches 0.0.0-use.local. This magic version string is for yarn a synonym for linkType: soft, i.e. IIUC a local dependency.

Unfortunately, this is not a viable option as the npm registry does allow to release packages with a 0.0.0-use.local version string.

So from my understanding, filtering needs to be performed earlier, for example yarn.lock parsing needs to be able to differentiate between local and remote dependencies. One viable option could be to set an empty version string if a local dependecy is detected.

[michaelkedar]

Okay, I see two things being talked about here

1. pkg@workspace:. in yarn.lock represents the root package (like "" in packages of package-lock.json) To be consistent, we should be ignoring this in extraction.
   I've opened fix: exclude root package in yarn.lock extraction osv-scalibr#807 to fix this.
2. Workspaces (and maybe other local dependencies) aren't properly considered in our yarn.lock extractor (and I don't think our package-lock.json extractor handles them especially well either). I think there needs to be some more thought into what the extractors should be extracting for these, and we need to make sure we're being consistent across the javascript extractors.
   I'll open an issue on osv-scalibr for this, since it's more relevant there. javascript extractors' handling of workspaces (and local dependencies?) osv-scalibr#808

[michaelkedar]

I believe the fix for the problem that was originally reported went out with the osv-scanner v2.0.3 release, so I'm closing this issue.
The workspace/local dependency problem is covered by the scalibr issue I opened.