False positive in Go module on a dependency that is overridden with a safe version at compile time.

[jeffwidman]

I compile/install grpcurl v1.8.5 into an image by having a dummy main.go file:

package main

import (
	"fmt"

	_ "github.com/fullstorydev/grpcurl"
)

func main() {
	fmt.Println(`
This is a dummy application used to pull in a go.mod dependency with grpcurl
which allows us to trigger a dependabot upgrade automatically of the grpcurl
tool.`)
}

I tried running Trivy against the resulting image and got the following warning:

991usr/local/bin/grpcurl (gobinary)
992================================
993Total: 1 (HIGH: 1, CRITICAL: 0)
994
995+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
996|      LIBRARY      | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |                 TITLE                 |
997+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
998| golang.org/x/text | CVE-2020-14040   | HIGH     | v0.3.2            | 0.3.3         | golang.org/x/text: possibility        |
999|                   |                  |          |                   |               | to trigger an infinite loop in        |
1000|                   |                  |          |                   |               | encoding/unicode could lead to...     |
1001|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-14040 |
1002+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+

golang.org/x/text is an indirect dependency. So I bumped the version number in the go.mod file using the following pin:

module github.com/<redacted>

go 1.16

require (
	github.com/fullstorydev/grpcurl v1.8.5
	golang.org/x/text v0.3.3 // indirect; required to fix CVE-2020-14040
)

This will cause the compiled version to only include v0.3.3 which fixes the CVE.

Unfortunately, Trivy continues to give the same warning.

Some less sophisticated scanners will throw false positives like this because the go.sum file still lists the old vulnerable version, even though it's not actually used in the binary (due to the pin in the go.mod file).

So I next tried using a replace directive as this will completely remove the vulnerable version from the go.sum file:

module github.com/<redacted>

go 1.16

require github.com/fullstorydev/grpcurl v1.8.5

replace golang.org/x/text v0.3.2 => golang.org/x/text v0.3.3 // required to fix CVE-2020-14040

Unfortunately the exact same warning continues to be thrown by Trivy.

I double-checked, and there's no mention of golang.org/text/ v0.3.2 anywhere in the go.sum file or the go.mod file.

1. Where is Trivy getting mention of this? Is it because you have a public DB of grpcurl deps and so as soon as it's pulled in you throw a warning even though we're completely overriding it in our source before it gets compiled?
2. Can you fix Trivy to support when //indirect pins in go.mod override?
3. Can you fix Trivy to support when replace directives in go.mod override?

[jeffwidman]

I also verified the vulnerable version isn't included in the compiled binary... both the indirect and replace solutions list this:

$ go list -m all | grep golang.org/x/text
golang.org/x/text v0.3.3

Similarly running against the compiled version:

$ go version -m <compiled binary> | grep golang.org/x/text
	dep	golang.org/x/text	v0.3.3	h1:cokOdA+Jmi5PJGXLlLllQSgYigAEfHXJAERHVMaCc2k=

So why does Trivy continue to emit a warning about v0.3.2 being present?

[DmitriyLewen]

Hello @jeffwidman
Thanks for your report!
After using replace golang.org/x/text v0.3.2 => golang.org/x/text v0.3.3 have you cleared the trivy cache?
You can use trivy --clear-cache for this.

Regards, Dmitriy

[jeffwidman]

Ah, that's it! I had no idea trivy had a built-in cache.

So looks like the bug here is the cache wasn't properly cleared for dep bumps implemented via indirect / replace pins...

[knqyf263]

It's weird. The cache should not be used after the binary update. How did you scan it?

[github-actions]

This issue is stale because it has been labeled with inactivity.

[knqyf263]

We hope it was fixed in v0.26.0.