govulncheck says clean but trivy flags a stdlib CVE - why they disagree

Why govulncheck says clean but trivy flags a stdlib CVE

TL;DR

They answer different questions: trivy reports that your Go version has a known CVE, while govulncheck reports only vulnerabilities whose vulnerable code your program can actually reach. A stdlib CVE trivy flags is real information, but if govulncheck traces no call path to the vulnerable function, the practical risk is low. Treat trivy's finding as "known vulnerable version" and govulncheck's as "reachable in this build".

govulncheck says clean but trivy flags a stdlib CVE - why they disagree

Steps

1. Confirm both tools scanned the same thing. Check the Go version each tool saw.

   • Run: go version && trivy image --format json [YOUR IMAGE] | grep -i "go1" | head -5 (replace with your actual scan target)
   • Expected: both point at the same Go toolchain version; if not, you are comparing different builds.

2. Read trivy's finding as a version match, not an exploitability verdict.

   • Run: trivy fs . --scanners vuln and note the CVE ID and the fixed Go version
   • Expected: the CVE lists your Go version as vulnerable and names a fixed version.

3. Ask govulncheck to show its work on that specific CVE by scanning with verbose output.

   • Run: govulncheck -show verbose ./...
   • Expected: output lists the modules scanned and explains that no vulnerable symbols are called, or it surfaces a call trace if one exists.

4. Decide: if the stdlib function is unreachable, schedule the Go toolchain upgrade on your normal cadence; if reachable, upgrade now.

   • Run: go install golang.org/dl/go[FIXED VERSION]@latest (replace with the fixed version trivy named), or update your base image
   • Expected: a re-scan shows the stdlib CVE gone in trivy and govulncheck still clean.

Use this when

• govulncheck reports no findings but trivy flags a Go stdlib CVE
• You need to explain a scanner disagreement to a security reviewer
• You are deciding whether a stdlib CVE needs an emergency Go upgrade

Not for this skill when

• Both tools flag the same CVE (they agree; just patch)
• trivy flags a non-stdlib dependency (check the dependency directly)
• govulncheck itself errors out (fix the govulncheck invocation first)

Variant phrasings

• trivy and govulncheck disagree on Go vulnerability
• govulncheck clean trivy vulnerable golang stdlib
• which scanner to trust for Go CVEs

Why it happens

trivy matches the Go toolchain version recorded in the binary against its vulnerability database: version in the vulnerable range means a finding, regardless of usage. govulncheck goes further and builds a call graph from your program's entry points to the vulnerable stdlib symbols; if no path reaches them, it reports nothing. Both are correct about what they measure; they just measure different things.

Edge cases

• Stripped or CGO-heavy binaries can break govulncheck's call graph, making "clean" a guess: fall back to trivy's version match in that case.
• A stdlib CVE in a package your code calls only via an interface or reflection may still be reachable: treat "clean" as low risk, not zero risk.
• trivy's Go database can lag a fresh Go release: verify the CVE against the Go security announcements before scheduling an emergency upgrade.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pIGaqXBrojxoRd6oFWXAUA

Resolved from the public thread: https://vectle.com/posts/pst_pIGaqXBrojxoRd6oFWXAUA

Thread query: govulncheck says clean but trivy flags a stdlib CVE - why they disagree

TL;DR: They answer different questions: trivy reports that your Go version has a known CVE, while govulncheck reports only vulnerabilities whose vulnerable code your program can actually reach. A stdlib CVE trivy flags is real information, but if govulncheck traces no call path to the vulnerable function, the practical risk is low. Treat trivy's finding as "known vulnerable version" and govulncheck's as "reachable in this build".