govulncheck 为什么有的漏洞只出现在测试：按扫描范围拆分依赖风险

如果 govulncheck ./... 报出一长串依赖漏洞，不要先把所有模块都标成“线上已受影响”。它同时关心两件事：项目是否导入了含漏洞符号的包，以及从你的代码入口能不能沿调用关系走到那个符号。测试包、示例包和生产包的扫描范围不同，所以同一个依赖在不同命令下出现不同结果是正常的。

先按扫描范围拆开结果，再看有没有指向漏洞符号的调用路径；有调用路径的结果优先升级，没有调用路径的结果记录影响范围后再安排治理。

• 导入命中只能说明依赖进入了分析范围，不等于漏洞函数被使用。
• 调用栈能把项目入口、依赖 API 和漏洞符号连起来，是判断优先级的关键证据。
• 生产代码与测试代码要分开看，避免测试工具链把线上风险判断带偏。

先看扫描范围：导入命中不等于真实调用

Go 官方把漏洞信息维护在 Go Vulnerability Database，govulncheck 会结合模块、包和符号关系，尽量只报告真正影响代码的已知漏洞。最常用的入口是模块根目录下的：

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

./... 会把模块里的包纳入分析，测试相关代码也可能随包一起被看到。若你只想先看生产入口，可以从明确的命令包开始：

govulncheck ./cmd/server
# 再单独观察某个业务包及其测试
govulncheck ./internal/order

这里的“只看生产入口”不是给工具加一个万能的 production 开关，而是用更窄的包模式减少无关范围。导入分析发现的是“这个模块链条里存在漏洞包”；符号级结果出现调用栈时，才说明工具找到了从你的代码到漏洞函数的关系。

再沿调用路径确认：漏洞符号是否真的可达

看到报告中的漏洞 ID 后，先看它给出的 Found in、Fixed in 和调用栈。真正需要马上处理的通常是能看到类似“项目函数调用依赖函数，再到漏洞符号”的结果；如果只在提示性结果中看到漏洞包而没有调用栈，不要把它和前者混成同一优先级。

# 输出机器可读结果，便于留档和比较
govulncheck -json ./cmd/server > govulncheck-server.json

# 需要检查测试范围时，明确指定包模式
govulncheck -json ./internal/order

排查时可以按三列记录：第一列是你的入口函数，第二列是实际经过的依赖 API，第三列是报告标出的漏洞符号。三列能连上，说明升级后要补回归测试；只能定位到依赖模块、找不到指向符号的路径，则把它记为“当前分析范围内未发现调用”，同时保留升级计划，因为依赖未来的调用方式可能改变。

测试只出现结果并不表示测试风险不重要。它说明漏洞代码可能只被测试工具、fixture 或测试辅助包触达，生产二进制未必包含同一条路径。相反，若生产命令和测试命令都能给出调用栈，就应把它合并为同一个依赖升级问题处理。

最后按证据安排修复：先升级真实调用链

一个实用的处理顺序是：先升级存在生产调用栈且已有 Fixed in 版本的依赖；然后重新运行同一生产包模式；再执行测试范围扫描，确认测试工具链没有留下独立问题。升级不要只改一个间接版本号，先用模块工具查看实际选择结果：

go list -m all
go get example.com/dependency@v1.2.3
go mod tidy
govulncheck ./cmd/server

如果结果只有无调用路径提示，可以在安全记录中写清扫描命令、依赖版本、漏洞 ID 和“未发现从指定入口到漏洞符号的调用栈”。这比直接忽略报告更可靠，也方便下次依赖升级后重新判断。若漏洞出现在测试包，修复测试依赖后仍要单独跑测试；不要因为它不进入生产二进制就跳过 CI 的安全检查。

相关问题

为什么 go.mod 里有漏洞，govulncheck 却没有调用栈？
因为依赖可能被导入但漏洞符号不可达，或者当前指定包模式没有覆盖使用它的入口。

只扫描 ./cmd/server 会不会漏掉业务包？
如果命令包通过导入关系使用业务包，分析会沿依赖进入；仍建议在重要业务包上用同样版本的命令补一次定向扫描。

测试里的漏洞要不要升级？
要。优先级可以低于生产调用链，但测试工具和 fixture 也会进入 CI 或开发环境，应该记录并安排修复。

总结：govulncheck 报告里的“漏洞包存在”和“漏洞符号可达”是两层信息。先缩小到明确的生产或测试范围，再沿调用栈确认，最后依据 Fixed in 版本升级并复跑同一命令，结果才不会被一份混合扫描报告带偏。