Scanning of pom files leads to wrong transitive dependencies #4458
Closed
yinonsh-orca
started this conversation in
Bugs
Replies: 2 comments 1 reply
-
|
Beta Was this translation helpful? Give feedback.
0 replies
-
There's an open PR that seems to solve the issue, and make transitive dependencies looks much more accurate: aquasecurity/go-dep-parser#205 |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Description
We use trivy to scan maven pom files using
trivy -d fs <Directory>
.For some of the transitive dependencies, it seems to resolve to a wrong version (which often doesnt exist/found), and doesnt scan our used versions. We also compared the trivy log with the one generated by
mvn dependency:tree
to confirm such differences.For the attached pom, here are a few examples of wrong transitive dependencies:
org.apache.logging.log4j:log4j-slf4j-impl
, we use version 2.17.1 but the scanned version is 23 (which is not found)org.apache.logging.log4j:log4j-core
andorg.apache.logging.log4j:log4j-jul
org.glassfish.jersey.containers:jersey-container-servlet-core
we use version 2.30 but the scanned version is 1.0.5 (which is not found)org.apache.parquet:parquet-jackson
we use version 1.8.3 and not version 16 (which is not found)org.apache.curator:curator-framework
we use version 2.6.0 and not version 14 (which is not found)Note also that:
Desired Behavior
The desired behavior is to scan the correct transitive dependencies, and not to scan wrong dependencies
Actual Behavior
The actual behavior is that expected transitive dependencies are not scanned, while wrong dependencies are scanned, which may lead to false/positive negatives, and also slows down the scan.
Reproduction Steps
Target
Filesystem
Scanner
Vulnerability
Output Format
None
Mode
None
Debug Output
Operating System
macOS Ventura 13.3.1
Version
Checklist
trivy --reset
Beta Was this translation helpful? Give feedback.
All reactions