Go govulncheck 结果怎么看不误判：source 模式与 binary 模式各自能证明什么

同一个 Go 项目用 govulncheck 扫源码和扫二进制，结果不完全一致并不等于工具误报。默认的 source 模式回答“当前源码入口能否沿调用图到达漏洞符号”，binary 模式回答“这个构建产物里是否能提取到相关模块和符号”。前者证据更细，后者更贴近实际交付物，但无法还原完整调用链。

先把两种模式的证据层级拆开

govulncheck 会把 Go 漏洞数据库中的模块、包和符号信息与待分析对象对应起来。source 模式加载指定源码包，结合包导入图与静态调用图缩小范围；binary 模式读取 Go 二进制中的构建信息和符号信息。两种扫描使用的构建条件也不同：源码扫描取当前 PATH 中 go 命令对应的版本，二进制扫描依据产物自身的构建配置。

因此，source 没报不代表所有产物都安全：反射调用对静态分析不可见，unsafe 也可能造成遗漏；函数指针和接口调用则可能被保守分析。binary 报告同样不能直接等同于可利用，因为二进制缺少详细调用信息，工具可能看到一个被链接进产物但实际不可达的符号。

用 source 模式确认源码调用链

在模块目录先安装当前版本，再扫描准备构建的包集合：

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...
govulncheck -show traces ./...

默认摘要会给出从项目入口到漏洞函数的简短调用栈，-show traces 可以展开完整链路。项目依赖构建标签时加入 -tags；风险可能只从测试代码进入时加入 -test。要把命令、扫描时间、go version 和入口包一并写入修复记录，否则下次结果变化时无法判断究竟是依赖升级，还是扫描范围变了。

用 binary 模式核对真实交付物

对流水线最终生成、尚未发布的 Go 二进制运行：

govulncheck -mode binary ./dist/service

binary 模式能发现主模块和传递依赖中的漏洞符号，但通常不展示调用栈。它的价值是覆盖源码仓库与实际产物不一致的场景，例如 CI 使用了不同 Go 版本、GOOS/GOARCH、构建标签或替换依赖。若符号信息无法提取，报告范围还可能扩大到二进制依赖的全部模块，所以不能仅凭“出现漏洞编号”就宣布已证实可达。

把两份结果变成可复核的处置清单

处理顺序可以按证据强度划分：source 给出到漏洞符号的调用栈，直接安排升级并补回归测试；binary 命中而 source 不命中，先核对扫描的是不是同一提交和同一构建条件，再检查符号是否只被链接但不可达；只有模块或包信息时，记录为待复核，不要与已确认调用混在同一严重级别。

相关问题

source 模式没有调用栈就一定不用升级吗？

不一定。先看是否只是导入层面的信息，并考虑反射、unsafe、构建标签和未纳入扫描的入口；无法排除时仍应结合修复版本和暴露面评估。

为什么同一提交在开发机和 CI 结果不同？

优先比较 Go 版本、GOOS/GOARCH、构建标签、是否包含测试文件、入口包和漏洞数据库更新时间。把这些条件固定后再比较结果才有意义。