trivy
trivy copied to clipboard
aquasecurity
false positive for CVE-2019-3826
Description
Prometheus publishes v2 as v0.x due to Go dependency versioning for using Prometheus as a library https://github.com/prometheus/prometheus#prometheus-code-base
Trivy finds vulnerabilities in go.mod dependencies for v0.35. However, this corresponds to Prometheus v2.35 which does not have this vulnerability https://github.com/open-policy-agent/gatekeeper/blob/master/go.mod#L99
What did you expect to happen?
No vulnerabilities reported
What happened instead?
Report for
│ github.com/prometheus/prometheus │ CVE-2019-3826 │ MEDIUM │ 0.35.0 │ v2.7.1 │ prometheus: Stored DOM cross-site scripting (XSS) attack via │
│ │ │ │ │ │ crafted URL │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2019-3826 │
example CI run: https://github.com/open-policy-agent/gatekeeper/actions/runs/3178090518/jobs/5179239860
Output of run with -debug:
(paste your output here)
Output of trivy -v:
v0.32.1
Additional details (base image name, container registry info...):
Hello @sozercan Thanks for your report.
It looks like Prometheus should add the /v2 suffix to the go.mod file.(as in postee or jwt)
Without this, we have no way to correctly determine the version of Prometheus.
If you have idea how to detect correct version - let us know and we will try to do it.
Until that you can add CVE-2019-3826 to .trivyignore file to skip this CVE.
Regards Dmitriy
@DmitriyLewen thanks for reply!
Prometheus has over 2k+ dependants, it will be a breaking change for anyone using it as a library. Adding to .trivyignore will work for our CI but not every user will have .trivyignore file and will find this false positive report.
Is there anything on trivy side that can fix this issue?
Hello @sozercan
Unfortunately, there is no information in the go.mod file about the relationship between the go module version and the tag number.
Without it we can't fix this issue.
This issue is stale because it has been labeled with inactivity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@DmitriyLewen Use github.com/prometheus/prometheus v2.41.0 to scan and you can see that there is no error, and use v0.41.0 to display an error
When using github.com/prometheus/prometheus v2.41.0 to execute the mod, the v2 version cannot be found @DmitriyLewen If you fix this problem
Use github.com/prometheus/prometheus v2.41.0 to scan and you can see that there is no error
Trivy checks version from go.mod file, after your changes Trivy finds v2.41.0 and finds no vulnerabilities for this version.
When using github.com/prometheus/prometheus v2.41.0 to execute the mod, the v2 version cannot be found
As i wrote here this is problem of prometheus.
They should add version suffix to correct work Go dependency versioning.
The prometheus root directory has a version of course @DmitriyLewen
But go.mod file doesn't use this file.
Trivy only finds dependencies in go.mod or go.sum files.
This is an isolated case and i am not sure that we need to handle this. This is repository issue in first place.
I am not sure, but looks like you can use modules to parse this case. There is example where vulnerabilities changes by jdk version
If you use this skip operation, once a critical vulnerability occurs, it will seriously affect the business
We don't skip vulnerabilities, we use versions from go.mod file.
If your go.mod files contains wrong versions - we don't have way to understand this.
Oh... you meant this module.
no one module doesn't enabled by default for Trivy.
Also, if i remember correctly, not all jdk contain this CVE. That is why this module is needed.
Is it unreasonable to directly read the version of go.mod for such a directory with a version number, or the version of the v0.0.0 branch?
If you have an idea how to do it - we are always glad to new contributors!
what do you mean? I am not sure that understand you correctly.
Can you create some example?
There is no information in The Go Vulnerability Database about the relationship between aws-sdk-go version and Go version.
It looks like the description is referring to the https://github.com/aws/aws-sdk-go-v2 repository.
as I wrote earlier, you can create new module for this. And use this module in your scans.
UPD. You can also bypass this vulnerability using trivyignore file.
This issue is stale because it has been labeled with inactivity.
You have to know that there are two versions of prometheus. The version of the libraries - 0.x and the version of the software - 2.x.
Hello @roidelapluie thanks for the clarification! Perhaps is there file with information about matching versions of library and software ( i mean lib v0.1.1 == software v2.2.2 ( it is example versions))? Then it will be possible to create Trivy module to remove false positives.
Because looks like all vulnerability databases only use software versions in advisories.