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

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: Install a Go toolchain at least as new as the go directive in go.mod, make sure the go command is on the PATH, and re-run the scanner. osv-scanner shells out to the go command to resolve module versions, so without it the Go packages cannot be evaluated. A working toolchain unblocks the scan.

failed to determine package versions for go.mod: no Go toolchain in PATH

1. Confirm the diagnosis. Run go version.

Expected: "command not found". If it prints a version, the toolchain exists but is not on the PATH the scanner sees, so fix the PATH instead.

2. Install Go. Use your platform's package manager or the official installer, choosing a release at least as new as the go directive at the top of go.mod.

Expected: the installer completes without errors.

3. Verify the toolchain is visible. Run go version again in the same shell or CI step that runs the scanner.

Expected: it prints a version number. The scanner runs in this same environment, so this check is representative.

4. Re-run osv-scanner against the go.mod.

Expected: the scanner resolves the module versions and reports findings instead of the toolchain error.

Use this when

• osv-scanner fails on a go.mod with the toolchain error
• the scan runs in a minimal container or CI image without Go
• go version works in your shell but the scanner step still fails (PATH scoping)

Not for this skill when

• the go command exists and the failure is about a specific module; that is a module resolution problem, not a toolchain problem
• the error names a different manifest (package-lock.json, Gemfile.lock); each ecosystem has its own prerequisites
• you are scanning an SBOM rather than a go.mod; the SBOM path does not shell out to go

Variant phrasings

osv-scanner needs go installed to scan go.mod

no Go toolchain in PATH osv-scanner

osv-scanner go.mod version resolution fails

install go for osv-scanner in CI

Why it happens

Go module version resolution is genuinely complex: replace directives, pseudo-versions, and toolchain-gated language versions all affect what "the version" of a dependency is. Rather than reimplement that logic, osv-scanner delegates to the real go command. No toolchain means no delegation, and the scanner fails the manifest instead of guessing versions.

Edge cases

• If go.mod demands a newer Go than you installed, the go command itself errors; match or exceed the go directive, and know that newer Go releases can auto-fetch toolchains when allowed.
• In CI, install Go in the same job and step environment as the scanner; a toolchain installed in an earlier container stage is not automatically on the later step's PATH.
• A go.work workspace changes which modules resolve; the scanner follows the workspace, so keep it in sync with what you build.
• Vendor directories do not remove the need for the toolchain here; version determination still goes through the go command.

Provenance

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

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

Thread query: osv-scanner: "failed to determine package versions for go.mod: no Go toolchain in PATH"

TL;DR: