Trivy misdetecting ehcache 2.10.9.2 as being jackson and other Java libraries #4857
Closed
chadlwilson
started this conversation in
False Detection
Replies: 1 comment
-
OK, after looking a bit further inside the jar, I discovered that So this probably isn't a trivy problem. Hmm. Will close for now. |
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
-
IDs
CVE-2020-36518 + others
Description
The problem here is not the underlying vulnerabilities, the problem seems to be the misclassification of ehcache
2.10.9.2
as being all these different unrelated libraries and versions:2.11.1
9.4.39.v20210325
9.4.39.v20210325
9.4.39.v20210325
9.4.39.v20210325
2.31
This ehcache jar is not an uber-jar and does not contain any of these above libraries so it's not obvious what is causing this: https://repo1.maven.org/maven2/net/sf/ehcache/ehcache/2.10.9.2/
Any idea how to debug this further and how to tell if this is a trivy problem, or to do with data/heuristics it uses to match jars to libraries? I don't see this misdetection with other tools, so it seems something specific to the way trivy works, which is leading to quite some noise for our Helm chart on https://artifacthub.io/packages/helm/gocd/gocd?modal=security-report
Example of one of the false positives, note that there are multiple layers of nesting here :-)
Reproduction Steps
Target
Container Image
Scanner
Vulnerability
Target OS
Alpine 3.18.2
Debug Output
Version
Checklist
-f json
that shows data sources and confirmed that the security advisory in data sources was correctBeta Was this translation helpful? Give feedback.
All reactions