govulncheck 默认只扫描显式依赖，必须加 -test 才能覆盖测试代码和间接依赖；需配合 go list -m all 人工筛查、go mod verify + GOSUMDB 校验完整性，并结合 go vet/golangci-lint 和代码审计识别真实调用风险。
Go 项目里依赖包有漏洞，govulncheck 跑出来没报，不等于安全——它默认只扫显式依赖，而真实风险常藏在 golang.org/x/net、github.com/gorilla/mux 这类间接拉进来的包里。
govulncheck 必须加 -test 才能扫到深层依赖
govulncheck 默认行为是静态分析你 go.mod 里 require 的直接依赖，但很多高危包（比如 golang.org/x/crypto）只被测试代码引用，或由某个日志库悄悄引入。不加 -test，这部分根本不会进 callgraph 分析范围。
- 必须跑两遍：
govulncheck ./（业务路径） +govulncheck -test ./（含测试文件的完整调用链） - 输出里的
GO-XXXX-XXX是 Go 官方编号，查vuln.go.dev，别拿它去搜 NVD - 如果结果是
no vulnerabilities found，只代表当前路径没触发已知漏洞模式，不代表依赖干净
go list -m all 是人工盯包的底线操作
govulncheck 会跳过 test-only 依赖，而 CI 构建时这些包照样会被下载。靠工具漏掉的，得靠人补。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 执行
go list -m all | grep -E "(golang\.org/x|github\.com/.*\.(sql|http|crypto))"，筛出高频风险模块 - 对每个可疑包，查它的
go.mod是否标了// indirect；再用go mod graph | grep 包名看谁引入了它 - 特别盯紧
golang.org/x/net和golang.org/x/text：它们被标准库周边大量依赖，但govulncheck不保证覆盖所有子功能路径
go mod verify 不是摆设，但得配 GOSUMDB
go.sum 只校验“和上次构建用的依赖一模一样”，不保第一次引入的就是干净的。私有 proxy 或 GOPROXY=fallback 下，中间人可能替换模块内容。
立即学习“go语言免费学习笔记（深入）”；
- CI 第一行必须跑
go mod verify，失败直接中断 - 设环境变量
GOSUMDB=sum.golang.org强制启用远程哈希比对，旧版 Go 默认可能关了这个 -
go.sum必须提交 Git，每次go mod tidy后人工确认新增条目：比如突然多了个github.com/xxx/yyy@v0.0.1，得查它是不是你团队维护的内部库
别把依赖扫描当唯一防线
依赖漏洞只是显性风险。硬编码密钥、http.Redirect 没校验用户输入、exec.Command("sh", "-c", userInput) 这类写法，比一个 GO-2024-1234 更容易在线上炸开。
-
go vet和golangci-lint的安全检查项（比如SA1019、gas规则）要集成进 CI，它们能抓到参数拼接、不安全反射等 runtime 风险 - 真正危险的不是“哪个包有 CVE”，而是“你调用了它的哪段代码”——
govulncheck的 callgraph 分析有盲区，得结合代码审计看实际使用路径
