Source analysis sees your intent and full structure, while binary analysis sees what was actually built. Source results can include code that never compiles into the product. Binary results can lose names and structure. Use source for fast developer feedback and the built artifact for the statement you make about what ships.
What each approach sees
The Go vulnerability tool documents both modes. It can analyse source code from the module directory, and it can analyse a compiled binary by pointing it at the file. For source, results depend on the configuration used to analyse, such as the language version. For a binary, the configuration is the one used to build it. That is a good example of why the two can differ.
| Aspect | Source analysis | Built artifact analysis |
|---|---|---|
| Structure | Full, with names and types | Reduced, depends on symbols kept |
| Build configuration | Analysis time setting | Fixed at build time |
| Dead code | May include code removed in the build | Reflects what was kept |
| Speed | Fast, runs on every commit | Needs a build first |
| Best for | Developer feedback | Release statements |
Where they disagree
- A file excluded by a platform setting appears in source analysis but not in the binary.
- A dependency optimised away by the linker is in the source graph but absent from the artifact.
- A stripped binary may hide symbol names, so a tool may need symbol data to map findings.
A sensible workflow
- On pull requests, run source analysis. It is quick and points at the exact line.
- In the release pipeline, analyse the built artifact, whether a binary, a container image or a bundle.
- Compare the two occasionally. A finding reachable in source but absent in the artifact is a candidate for a build-level explanation.
- Keep the artifact result with the release record, since it matches what customers run.
Containers and bundles
The same logic extends beyond single binaries. A container image holds operating system packages and application files. A web bundle holds the code the browser receives. In each case, the artifact is the truth about what shipped, and source is the truth about what you wrote.
What to say externally
If you tell a customer "the vulnerable function is not present in this release", back it with an artifact check. If you say "not reachable from our entry points", back it with the call path and the configuration. These are different statements, so name which one you are making.
Safeguard includes reachability analysis alongside SBOM and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan to see the output on your own repository.
Quick check
Is binary analysis more accurate?
It reflects what shipped, but it can lose detail. Neither is strictly better, so match the method to the claim.
Do I need both?
Many teams use source on commits and the artifact at release.
Sources
- govulncheck command documentation, pkg.go.dev
- Tutorial: Find and fix vulnerable dependencies with govulncheck, go.dev
Last reviewed: 19 October 2026.
