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

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.

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

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

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

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