Replies: 2 comments
-
This patch in diff --git a/pkg/nodejs/npm/parse.go b/pkg/nodejs/npm/parse.go
--- a/pkg/nodejs/npm/parse.go
+++ b/pkg/nodejs/npm/parse.go
@@ -116,6 +117,7 @@
// There are cases when similar libraries use same dependencies
// we need to add location for each these dependencies
if savedLib, ok := libs[pkgID]; ok {
+ savedLib.Dev = savedLib.Dev && pkg.Dev
savedLib.Locations = append(savedLib.Locations, location)
sort.Sort(savedLib.Locations)
libs[pkgID] = savedLib I'm not sure what other implications that has or whether the same issue exists in parsers for other package managers. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Track #5139 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Description
Trivy is giving inconsistent results between successive vulnerability scans with the same database version. A sample
package-lock.json
that induces the behavior is included (collapsed) below. I believe the issue is triggered by the same package ID (name@version
) having multiple entries in the lockfile, where one has"dev": true
and another doesn't. In this sample,[email protected]
meets that condition.Sample package-lock.json
Related: aquasecurity/go-dep-parser#149
Desired Behavior
I expect the scan results to be determinate and include all affected non-dev packages. With the sample lockfile, the expected output is:
Actual Behavior
With the sample lockfile, the output excludes
[email protected]
in roughly 50% of scans:Reproduction Steps
Target
Filesystem
Scanner
Vulnerability
Output Format
Table
Mode
Standalone
Debug Output
Operating System
macOS Ventura 13.5.1
Version
Checklist
trivy image --reset
Beta Was this translation helpful? Give feedback.
All reactions