## 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

```text
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

```bash
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

```bash
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

```bash
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