govulncheck 默认只扫描直接依赖，必须加 -test 参数才能覆盖测试代码路径发现间接依赖漏洞；需结合 go list -m all 人工筛查高危包、go mod verify 校验完整性，并跳转 vuln.go.dev 确认实际影响范围。
govulncheck 默认只扫直接依赖，必须加 -test 才能发现间接依赖里的漏洞
你跑 govulncheck ./ 看到 “no vulnerabilities found”，不代表项目安全——它默认只分析 go.mod 里显式 require 的模块，而真实风险常藏在 golang.org/x/net、github.com/gorilla/mux 这类被二级依赖悄悄拉进来的包里。
真正要覆盖调用链，得补上测试代码路径：
-
govulncheck ./：扫业务代码 + 直接依赖 -
govulncheck -test ./：额外扫描所有_test.go文件中 import 的包，常暴露被忽略的 transitive 依赖
注意：-test 不是“只扫测试代码”，而是扩展 callgraph 分析范围，让工具看到测试里触发但主逻辑没走的函数路径。很多高危漏洞（比如某个 http.Transport 配置缺陷）只在测试用例里实例化过，不加这个参数就漏掉。
别信 no vulnerabilities found，先查 GO-XXXX-XXX 编号对应的真实影响范围
govulncheck 报的不是 CVE，是 Go 官方编号（如 GO-2024-2561），它只代表“该模块某版本存在已知问题”，但是否影响你的实际调用，取决于你有没有走到那个函数分支。
常见误判场景：
- 你用了
net/http，但没调用带漏洞的http.Transport.CloseIdleConnections→ 报告里有GO-2024-XXXX，实际无风险 - 你项目设了
GOOS=windows，但漏洞仅存在于linux实现 →govulncheck默认按当前环境过滤，不会报 - 用了
unsafe或反射调用 → 静态分析不可见，漏洞不报告，但运行时可能触发
查详情必须点开报告里的链接跳转到 vuln.go.dev，看 “Affected functions” 和 “Fixed in” 版本，再比对你代码里实际调用的路径。
go list -m all 是人工盯包的底线操作，尤其要筛 golang.org/x/ 和 crypto 类包
govulncheck 会跳过 test-only 依赖，而有些高危模块（如 golang.org/x/crypto、github.com/gorilla/mux）只在测试里用，线上不用，但 CI 构建时仍下载——这类包不会出现在漏洞报告里，却可能被污染或含已知问题。
执行这行命令快速捞出高频风险包：
go list -m all | grep -E "(golang\.org/x|github\.com/.*\.(sql|http|crypto))"
对每个结果，再做两件事：
- 查它的
go.mod是否标了// indirect→ 确认是不是传递引入 - 用
go mod graph | grep 包名看谁拖进来的 → 判断能否通过replace或升级上游来规避
特别注意 golang.org/x/net 和 golang.org/x/text：它们被标准库周边包大量依赖，但 govulncheck 的 callgraph 分析不一定覆盖全部子功能（比如某个 idna 解析逻辑）。
go mod verify 必须进 CI，且不能只靠本地 go.sum
go.sum 只保证“和上次构建用的依赖一模一样”，不保证第一次引入的就是干净的。如果你用过 GOPROXY=fallback 或私有 proxy，中间人可能替换过模块内容。
CI 流水线第一行就得加：
go mod verify
它会比对本地 go.sum 和 sum.golang.org 公共日志里的哈希，防篡改。关键设置：
- 强制启用远程校验：
GOSUMDB=sum.golang.org（别信旧版 Go 默认值，某些版本默认关） -
go.sum必须提交 Git，每次go mod tidy后人工确认新增条目来源 —— 比如突然多了个github.com/xxx/yyy@v0.0.1，得查它是不是你团队内部库
真正容易被忽略的是：go mod verify 成功 ≠ 模块安全，它只防下载污染，不防代码层漏洞。必须和 govulncheck、gosec 配合，才构成基础防线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
