x/website, x/pkgsite, x/build/cmd/relui, vscode-go, x/telemetry: vulnerability GHSA-3xgq-45jj-v275/CVE-2024-21538 in cross-spawn dependency version 7.0.3

[pcreager23]

Go version

1.23.4

Output of go env in your module/workspace:

N/A - Container-based (docker image) scan.

What did you do?

Anchore scans run periodically.

What did you see happen?

Vulnerability scanners (such as Anchore) are detecting GHSA-3xgq-45jj-v275/CVE-2024-21538 in cross-spawn 7.0.3. That dependency needs to be upgraded to 7.0.5 or higher. Thank you.

Note: This was reported as Issue 71114, but that was closed with not planned. It is not a duplicate according to issue search, so asking for an explanation.

What did you expect to see?

Clean scan results.

[gabyhelp]

Related Issues

• cross-spawn: Update the version to 7.0.5 to fix vulnerability GHSA-3xgq-45jj-v275 #71114 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[dmitshur]

This is the issue tracker for the Go project. What is "cross-spawn" in your report? If it's referring to https://www.npmjs.com/package/cross-spawn, the issue tracker for that seems to be https://github.com/moxystudio/node-cross-spawn/issues. If there's an issue in Go itself, please add more information so we can understand the problem. Thanks.

[dmitshur]

I see it's a dependency in some of the golang.org/x repos:

https://cs.opensource.google/search?q=%22cross-spawn%22%20%227.0.3%22&ss=go

[seankhliao]

This is pulled in from eslint and npm-run-all, both of which are development only dependencies for js/ts (as in, the scan results are just noise).

I do think it's unfortunate that web code is vendored into the main go repo, perhaps all the telemetry.go.dev things and related tooling setup should move into the x/telemetry/godev directory, which is already its own module. currently there's js code in x/telemetry/internal/content which is part of the parent module.

cc @golang/telemetry

[findleyr]

CC @golang/tools-team (for pkgsite)

@seankhliao I agree that we should perhaps consider adding a submodule for x/telemetry/cmd/gotelemetry, so that the core telemetry library has no web dependencies.

EDIT: @rsc points out that we could achieve the same effect by simply moving the package.json into a subdirectory of the module root.

[pcreager23]

Is it possible to get an estimated fix date? Thanks.

[pcreager23]

Additional finding that just came to our attention:
GHSA-3xgq-45jj-v275/CVE-2024-21538

Same scenario as above - fixed in cross-spawn 7.0.5.

[findleyr]

Hi @pcreager23, where are these finding originating? What problems are they causing you?

It sounds like we can and should update our depenencies, and we will discuss timing for this in our regular triage meeting later today. However, I want to understand this problem better. What friction does a failed npm audit cause?

It seems like we need a (better) system in place to manage our development dependencies, but the design of that system depends on understanding the impact these dependencies have on the users of our libraries and applications.