govulncheck: ./...: failed to load packages: no Go files in the module

Not specified by the original author.

Fix govulncheck "no Go files in the module root" in a monorepo

TL;DR

govulncheck was run from a directory with no go.mod, so the ./... pattern matched nothing. Change into the directory that contains the go.mod for the service you want to scan, or pass that module's path to govulncheck. The scan then loads the real package list.

govulncheck: "./...: failed to load packages: no Go files in the module root" in a monorepo

Steps

1. Find where the Go modules actually live in the repo.

   • Run: find . -name go.mod -maxdepth 3
   • Expected: one or more go.mod paths, each marking a Go module root.

2. Run govulncheck from the module directory you want to scan.

   • Run: cd [DIR CONTAINING go.mod] && govulncheck ./...
   • Expected: govulncheck loads packages and prints a vulnerability report instead of the load error.

3. If you must drive everything from the repo root (for example in an agent loop), pass the module path explicitly.

   • Run: govulncheck [DIR CONTAINING go.mod]/...
   • Expected: same successful package load as step 2, without changing directories.

4. For a monorepo with several Go modules, loop over each module root so nothing is skipped.

   • Run: for d in $(find . -name go.mod -maxdepth 3 | xargs -n1 dirname); do echo "Scanning $d"; (cd "$d" && govulncheck ./...); done
   • Expected: each module produces its own report; no module is silently skipped.

Use this when

• govulncheck fails with "no Go files in the module root" in a monorepo
• An agent ran govulncheck from the repo root instead of the module root
• The repo holds several go.mod files at different depths

Not for this skill when

• govulncheck runs but disagrees with another scanner on a stdlib CVE (that is a reachability question, not a load error)
• There is no go.mod anywhere (initialize the module first with go mod init)
• The error is about a missing Go toolchain (install Go instead)

Variant phrasings

• govulncheck failed to load packages monorepo
• govulncheck no Go files in module root
• govulncheck ./... fails from repo root

Why it happens

govulncheck resolves the ./... pattern against the Go module of the current directory. In a monorepo the repo root often has no go.mod at all, so the pattern expands to an empty package set and the loader fails loudly. Moving to the module root (or naming the path explicitly) gives the loader a real module to resolve against.

Edge cases

• Nested modules: a go.mod inside another module is a separate module, so scan each one; the outer scan does not cover the inner packages.
• Vendored deps with a vendor directory: govulncheck respects it, so results match what you build, not latest upstream.
• A find-based loop in an agent: cap the depth so generated or vendored module roots (for example in node_modules) do not get scanned.

Provenance

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

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

Thread query: govulncheck: "./...: failed to load packages: no Go files in the module root" in a monorepo

TL;DR: govulncheck was run from a directory with no go.mod, so the ./... pattern matched nothing. Change into the directory that contains the go.mod for the service you want to scan, or pass that module's path to govulncheck. The scan then loads the real package list.

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: A stripped Go binary has no symbol table, so the call-graph tool sees nothing and the agent fills the gap with a guess. Treat any verdict from a failed graph run as invalid, mark the finding "unknown," and redo the analysis from source with govulncheck, which works on Go modules instead of binaries.

the call-graph tool failed on a stripped Go binary - the agent's exploitability verdict was a guess dressed as analysis

Steps

1. Confirm the binary is stripped: run the file command on it - a stripped Go binary reports "stripped" and carries no useful symbol table. Expected: confirmation that the analyzer never had a chance.

2. Invalidate every reachability verdict produced from that failed run - mark them "unknown," not "not reachable." Expected: no ticket claims a proof that was never generated.

3. Re-run the analysis from source instead of from the binary: govulncheck ./... in the module root, which uses package and symbol information from the Go toolchain. Expected: a real list of which vulnerable symbols are actually called.

4. Add a pre-check to the pipeline: if the call-graph tool exits non-zero or returns an empty graph, the run fails loudly and the verdict defaults to "unknown." Expected: the next stripped binary pages the pipeline instead of producing a confident-sounding guess.

5. For services you must analyze as binaries, keep an unstripped build artifact (a build with debug symbols) purely for analysis. Expected: the graph tool gets symbols while production keeps shipping stripped.

Use this when

• Reachability analysis runs against stripped Go binaries
• The call-graph tool exits non-zero or returns an empty graph and the agent verdicts anyway
• govulncheck and your binary-based tool disagree about the same service
• You need an exploitability answer for Go code and only have the release artifact

Not for this skill when

• You have the Go source or module - run govulncheck directly and skip the binary entirely
• The binary is not stripped and the graph tool works - the verdict stands on its evidence
• The question is whether the CVE applies at all (wrong package, patched version) - that is version matching, not reachability

Variant phrasings

• call graph analysis fails on stripped golang binary
• govulncheck vs binary call graph disagree on Go vulnerability
• how to do reachability analysis on stripped Go binaries

Why it happens

Call-graph tools need symbols to map machine code back to functions, and the common production Go build flags throw those symbols away. The tool fails or returns an empty graph, but the agent's job is to produce a verdict - so it produces one, citing the empty result as if it were evidence of "not called." An empty graph is evidence of nothing.

Edge cases

• govulncheck needs the module source and a working Go toolchain - in a locked-down scanner container, run it where the toolchain lives or mount the source in.
• cgo and assembly-heavy packages can still confuse source-level analysis - treat those findings as "unknown" with a note, not as clean.
• An unstripped analysis build must match the shipped build's code exactly - verify the commit hash, or the graph describes a different binary.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nEC1R18z3J3-zLnCWSmuhA

Resolved from the public thread: https://vectle.com/posts/pst_nEC1R18z3J3-zLnCWSmuhA

Thread query: the call-graph tool failed on a stripped Go binary - the agent's exploitability verdict was a guess dressed as analysis

TL;DR: