Replies: 1 comment 1 reply
|
The scan is actionable, and the locations show that these are not all the same dependency problem. The golang.org/x/net and golang.org/x/text findings are inside the bundled kubectl.exe, while the oras-go finding is inside the bundled helm.exe. Updating the application package's own Go dependencies will not change those embedded tools; the tools need to be rebuilt or replaced with upstream versions that contain the fixed modules. After rebuilding, verify the binary module metadata and scan the actual packaged executable again. The fast-uri, ip-address, and yaml findings are in the packaged Node dependency tree, so those should be handled through the lockfile and the application build. The important verification target is the final win-unpacked/resources tree, not only the source workspace. I would track the remediation as separate artifacts:
For each advisory, record whether the vulnerable code is reachable in the shipped feature and whether an upstream fixed version is available, but do not suppress a high finding just because it is in a helper binary. The scan is valuable precisely because bundled tools become part of the user's attack surface. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Grype runtime vulnerability scan for
4878c7c879c5, updated 2026-09-05 22:20 UTC by this run.All reactions