govulncheck -test 必须运行，否则会漏掉测试链路中的高危间接依赖；需配合-tags参数启用测试构建约束，不可盲目删除//indirect行，应通过go mod graph和go list验证真实引用关系，并在CI中强制go mod verify与GOSUMDB校验。
govulncheck -test 必须跑，否则漏掉测试链路里的高危间接包
很多团队只跑 govulncheck ./，结果报告“no vulnerabilities found”，但线上构建时却因测试依赖触发漏洞。原因在于：govulncheck 默认不分析 *_test.go 文件中的 import 路径，而大量高危包（如 golang.org/x/crypto、github.com/gorilla/mux）只在集成测试里用，生产代码根本不 import。
正确做法是补上 -test 参数：
-
govulncheck ./→ 扫主模块业务路径 -
govulncheck -test ./→ 扫测试文件构成的调用链，常暴露被忽略的 transitive 依赖
注意：如果测试用了 //go:build integration 这类 tag，需确保当前环境启用对应 tag（如加 -tags=integration），否则仍会跳过。
别直接删 go.mod 里的 // indirect 行，先验证谁真在用它
看到 golang.org/x/net v0.25.0 // indirect 这类行就手痒删？危险。间接依赖被删后，go build 可能突然失败——不是因为 import 缺失，而是某个库通过反射、plugin 或生成代码（如 go:generate）暗中依赖它。
安全验证步骤：
- 查谁引入：
go mod graph | grep golang.org/x/net - 看是否真用：
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./ | grep golang.org/x/net - 临时注释该行，再跑
go build ./和go test ./—— 任一失败，说明不能删
特别注意 golang.org/x/sys 和 golang.org/x/text：它们被标准库周边包高频间接引用，即使没显式 import，也不建议手动清理。
go list -m all + 关键词过滤，人工盯住高频风险包
govulncheck 会跳过 test-only 依赖，且对某些子包（如 golang.org/x/net/http2）的分析覆盖不全。必须辅以人工筛查：
执行：go list -m all | grep -E "(golang\.org/x|github\.com/.*\.(sql|http|crypto))"
对每个命中包，做两件事：
- 查它的
go.mod是否带// indirect标注 - 用
go mod graph | grep 包名确认引入路径，判断是否可被更安全的替代品替换（例如用net/http原生 client 替代某些第三方 http 客户端）
重点盯 golang.org/x/net 和 golang.org/x/text：它们被上百个生态包依赖，但 vuln.go.dev 对其子功能的覆盖存在盲区。
go mod verify 必须进 CI，且不能只信本地 go.sum
你以为删了漏洞包就安全了？错。如果之前 go mod download 时拉下来的是被污染的版本，go.sum 里存的哈希就是恶意的。本地 go mod tidy 再干净，也救不回已被污染的校验和。
CI 中必须强制：
- 第一行跑
go mod verify，失败即中断 - 设环境变量
GOSUMDB=sum.golang.org，启用远程校验（旧版 Go 默认可能关掉） -
go.sum必须提交 Git，每次go mod tidy后人工确认新增条目来源——比如突然多出github.com/xxx/yyy@v0.0.1，得查清是不是内部库
真正容易被忽略的点是：go.sum 的校验对象是“你上次构建用的版本”，不是“这个版本本身是否干净”。第一次引入时就被污染，后续所有 tidy 都只是在加固一个错误基础。
