META-INF pom is considered as a vulnerability #5811
Replies: 3 comments 6 replies
-
|
Hello @o-shevchenko You're almost right. But why you think we don't need to include these dependencies in result? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @DmitriyLewen , thanks for the response!
Because com.databricks:databricks-jdbc:2.6.36 doesn't bring any transitive dependencies (See But that's not the case here, even if you specify a newer version of the dependency and it will be present in classpath, Trivy still will be reporting vulnerability. Don't you agree? |
Beta Was this translation helpful? Give feedback.
-
|
It is more seems on problem in
|
Beta Was this translation helpful? Give feedback.
-
|
I think Databricks jar should be fixed as well. I've opened discussion, that's strange that 2.6.35 is missed and 2.5.36 includes such changes. Probably, something wrong with build process. But it's a wild guess since I don't see source code. But anyway, I'm not sure that Trivy handles such a case correctly. That's why I opened this ticket. |
Beta Was this translation helpful? Give feedback.
-
|
I think Trivy works correctly. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure about implementation here, I think you are more familiar with the codebase and logic to find out how to improve detection. Maybe we should just check jars in classpath, maybe we should be able to disable pom.properties check. But I found a case where we have a false-positive result, so that's the chance to improve Trivy. |
Beta Was this translation helpful? Give feedback.
-
|
Let's wait Databricks |
Beta Was this translation helpful? Give feedback.
-
|
We faced this issue again. Trivy reports |
Beta Was this translation helpful? Give feedback.
-
|
Hello @o-shevchenko If you sure that |
Beta Was this translation helpful? Give feedback.
-
Description
Trivy reports vulnerabilities but such jars are not present in our Docker image. Gradle
dependenciestree doesn't show it.Debugparameter for Trivy also doesn't show such libs.After digging into it, we discovered that Trivy probably detects
META-INF/pom.xmlas a vulnerability.Particularly, it found
META-INF/pom.xmlintroduced in the lastdatabricks-jdbcjarProbably, Databricks should fix build for com.databricks:databricks-jdbc:2.6.36 as well, since
com.databricks:databricks-jdbc:2.6.34doesn't include problematic dependencies inMETA-INF/pom.xmlbut detection still should be fixed in Trivy for such cases.Desired Behavior
Trivy doesn't report vulnerability if the actual jar is not present.
Actual Behavior
Trivy reports vulnerability if the actual jar is not present but there is pom.xml with a problematic version
Reproduction Steps
Target
Container Image
Scanner
Vulnerability
Output Format
None
Mode
Standalone
Debug Output
Operating System
Linux
Version
TRIVY_IMAGE='aquasec/trivy:0.48.1'Checklist
trivy image --resetBeta Was this translation helpful? Give feedback.
All reactions