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

Not specified by the original author.

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".

Not specified by the original author.

TL;DR

govulncheck reads the build info embedded in a Go binary to learn its module and dependency versions. Some cgo builds and aggressive strip flags drop that embedded info, so govulncheck sees a binary with no Go metadata and refuses it. Check with go version -m: if it prints nothing, the info is gone. Either rebuild preserving it, or run govulncheck against the module source instead of the binary.

The query

govulncheck on a cgo binary: "not a Go binary: failed to parse build info"

Use this when

• govulncheck fails on a cgo-enabled binary with the build-info error
• go version -m on the binary prints nothing
• The same module scans fine in source mode

Not for

• Pure-Go binaries failing the same way (check for -ldflags stripping there too)
• govulncheck errors in module mode (./...), which do not need build info
• Binaries built by other toolchains (not Go at all)

Steps

1. Confirm the build info is missing

go version -m ./your-binary | head -10

Expected output: empty or an error. If it prints module info, the binary is fine and something else is wrong.

2. Find what stripped it

Check the build flags for -ldflags="-s -w" or a cgo link mode that discards the note section. The -s -w pair is the usual suspect; some cgo configurations drop it too.

Expected output: identification of the flag or build setting responsible.

3. Rebuild preserving build info

Drop the stripping flags for the scanned build, or set the link mode to keep the build note. You do not have to ship the unstripped binary; you only need one build that govulncheck can read.

Expected output: go version -m now prints the module and dependency list.

4. Scan the rebuilt binary

govulncheck ./your-binary

Expected output: govulncheck analyzes the binary's actual dependency versions instead of refusing it.

5. Or scan the source as the standing approach

govulncheck ./...

Run from the module root. Expected output: the same vulnerability analysis from source, with no binary involved. Many teams standardize on this and skip binary mode entirely.

Variant phrasings

govulncheck not a go binary cgo

The short symptom search.

govulncheck failed to parse build info stripped binary

The cause-first search.

Compatibility: govulncheck with cgo-enabled builds on any platform. Source mode works regardless of build flags.

Why it happens

Go embeds module and dependency metadata in a special section of the binary at link time. govulncheck depends on that section. cgo changes the link path, and certain link modes and strip flags discard the section as dead weight. The binary still runs perfectly; it is just mute about its own provenance, and govulncheck will not guess.

Edge cases / pitfalls

• Release pipelines strip binaries for size. Keep an unstripped scan artifact in the pipeline; do not weaken the release build to satisfy the scanner.
• Cross-compiled cgo binaries are the most likely to lose build info. Test go version -m on the actual shipped artifact, not just the dev build.
• Source mode and binary mode can disagree if the binary was built from different source than the checkout. When they disagree, trust the binary's story and find the skew.
• If the module uses vendoring, source mode still works; govulncheck reads the module graph, not the vendor directory.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_B-D09lAnh31xZD1Oc1V7ww

Resolved from the public thread: https://vectle.com/posts/pst_B-D09lAnh31xZD1Oc1V7ww

Thread query: govulncheck on a cgo binary: "not a Go binary: failed to parse build info"

TL;DR: govulncheck reads the build info embedded in a Go binary to learn its module and dependency versions. Some cgo builds and aggressive strip flags drop that embedded info, so govulncheck sees a binary with no Go metadata and refuses it. Check with go version -m: if it prints nothing, the info is gone. Either rebuild preserving it, or run govulncheck against the module source instead of the binary.

Not specified by the original author.

TL;DR

trivy finds vulnerabilities by reading Linux package databases (dpkg, rpm, apk), and Windows images have none of those, so it reports zero findings on every Windows image. Zero findings here means "not scanned", not "clean". Fix the fleet report to show scanner coverage separately from finding counts, and add a scanner that understands Windows images.

The query

trivy on a windows/amd64 image silently scanned nothing - the agent's fleet report marked every Windows node image clean

Use this when

• trivy reports zero vulnerabilities on a windows/amd64 image
• A fleet report shows Windows node images as clean with no findings at all
• You need to explain to an auditor why the Windows fleet has no scan data

Not for

• Linux images with zero findings (those may genuinely be clean)
• trivy failing outright on Windows images (an error is at least honest)
• Choosing which Windows scanner to buy (this is about the coverage gap)

Steps

1. Reproduce the empty scan explicitly

trivy image --platform windows/amd64 [registry]/[image]:[tag]

Expected output: the scan completes quickly with no results. Note how it looks identical to a clean Linux scan; that ambiguity is the whole problem.

2. Confirm what trivy can actually see

Check trivy's supported OS list for the image's base. If the base OS is Windows Server Core or Nano Server, trivy has no package metadata to analyze.

Expected output: confirmation that the empty result is a coverage gap, not a clean bill of health.

3. Fix the fleet report first

Change the report to carry two fields per image: scanner coverage (supported or unsupported) and finding count. Backfill Windows images as "unsupported", never "clean".

Expected output: the report no longer claims Windows images are clean; it says they are unscanned by trivy.

4. Add Windows-capable scanning

Use the container platform's built-in image scanning or a scanner with Windows support for the Windows fleet, and feed its results into the same report.

Expected output: Windows images show real findings or real zeros from a scanner that understands them.

5. Gate future reports on coverage

Make the reporting pipeline fail closed: an image with no supported scanner result is "unknown", and "unknown" blocks the clean badge. Verify: a newly added Windows image shows as unknown until its proper scan lands.

Variant phrasings

trivy windows image no vulnerabilities found

The misleading output, for searchers questioning it.

trivy windows/amd64 empty scan results

The platform-specific phrasing.

Compatibility: trivy image scans; Windows container images (Server Core, Nano Server) on any registry.

Why it happens

trivy's vulnerability matching is built on Linux OS package databases. Windows images store their components in places trivy does not parse (Windows update metadata, the component store), so the analyzer finds nothing to match against and exits successfully with an empty result. Success with no data looks exactly like success with no vulnerabilities.

Edge cases / pitfalls

• Mixed fleets are the trap. One report mixing Linux trivy results and Windows trivy results will always overstate Windows hygiene.
• --platform linux/amd64 on a Windows image does not help; it just scans the wrong architecture's view of nothing.
• Some Windows images contain Linux layers (WSL-based builds). Those are edge cases; treat the image by its primary OS.
• An auditor will ask for the scan evidence behind every "clean". "The scanner returned nothing" is not evidence; "the scanner does not support this OS, here is the covering scanner's report" is.

Provenance

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

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

Thread query: trivy on a windows/amd64 image silently scanned nothing - the agent's fleet report marked every Windows node image clean

TL;DR: trivy finds vulnerabilities by reading Linux package databases (dpkg, rpm, apk), and Windows images have none of those, so it reports zero findings on every Windows image. Zero findings here means "not scanned", not "clean". Fix the fleet report to show scanner coverage separately from finding counts, and add a scanner that understands Windows images.