Closed jeffwidman closed 2 years ago
Oof, we added an //indirect
pin internally to bump golang.org/x/text
past this, but the scanner is still complaining... https://github.com/aquasecurity/trivy/issues/1559.
I suspect it's somehow scanning the go.sum
file so that even if the compiled code doesn't actually include the vulnerable code, it'll still be reported as a false positive. 🤦♂️
even if the compiled code doesn't actually include the vulnerable code, it'll still be reported as a false positive
I've definitely had this issue before. Sometimes go mod tidy
will help, to clean up old records from go.sum
. But go.sum
, even tidied, can have multiple versions of the same module, even though only one is actually compiled and linked in (it checksums every referenced dependency in the graph, including indirectly referenced versions that will actually be unused in the build).
Yeah, go mod tidy -compat=1.17
helps, we dropped thousands of lines from some of our go.sum
files. 😀
But still be nice to pin to newer version here in grpcurl
.
We install
grpcurl
as a binary in some tooling.However, our security team just added some CVE scanners that fail the build if known CVE's are found.
grpcurl
is throwing the following:My hunch is that this is likely due to some outdated deps, and pulling in #267 could quickly fix. I haven't walked the full dep tree though, so perhaps even then this wouldn't be fully fixed and would require adding an
//indirect
pin that bumps past this broken one.There's actually another CVE in
golang.org/x/text@0.3.6
, so might be best to just pin tov0.3.7
to avoid this recurring in the future.