govulncheck仅能扫描Go官方漏洞数据库（vuln.go.dev）中已收录且被代码实际调用路径覆盖的CVE，常漏报间接依赖未触发分支、私有/fork模块、pseudo-version版本匹配失败及数据库更新延迟等情况。
govulncheck 能扫出哪些漏洞，又为什么常扫不出来
govulncheck 是 Go 官方推荐的 CVE 扫描工具，但它不是万能的——它只报告已录入 Go Vulnerability Database 的漏洞，且仅覆盖你实际调用到的函数路径。常见漏报场景包括：
• 间接依赖里某个未被调用的 encoding/xml 解析逻辑存在 CVE，但主模块没触发该分支，govulncheck 就不会标红
• 漏洞补丁发布后，数据库更新有延迟（通常 1–3 天），期间 govulncheck ./ 仍显示“no vulnerabilities found”
• 使用了 fork 分支或私有模块，而 Go Vulnerability Database 不收录这些路径，govulncheck 直接跳过不查
• 依赖版本号写成 v0.0.0-20230101000000-abcdef123456 这类 pseudo-version，工具可能无法匹配 CVE 记录
go.sum 校验失效的三个典型表现
go.sum 文件本身不防恶意包，但它一旦失效，连“构建一致性”都保不住。最容易被忽略的失效信号是：
• go build 时没报错，但 go mod verify 返回 missing go.sum entry —— 这说明有人删过 go.sum 或手动改过 go.mod 却忘了更新校验和
• CI 日志里出现 verifying github.com/some/pkg@v1.2.3: checksum mismatch，但本地 go build 正常 —— 很可能是 GOPROXY 缓存了被篡改的 ZIP 包，而本地有旧缓存
• go list -m all 显示某模块版本为 v1.2.3，但 go.sum 里对应条目却是 h1:xxx 和 go.mod h1:yyy 两行都缺失 —— 表明该模块根本没走标准下载流程，极可能来自 replace 或本地路径，完全绕过校验
go list -m -u all 里哪些包该人工盯死
自动更新建议只是参考，真正要人工介入的是这几类：
• 标记为 indirect 且超过 6 个月没更新的包，比如 golang.org/x/net 在你项目里是间接引入，但最新版已修复 TLS 1.3 握手缺陷，而你锁在 v0.14.0（2023 年发布）
• 路径含 fork、patched、no-ssl 等关键词的模块，例如 github.com/xxx/stdlib-patched，这类包往往脱离上游维护，安全响应滞后
• go list -m -f '{{.Path}} {{.Version}}' all | grep -E "(yaml|xml|json|toml)" 输出中版本号带 -rc 或 -beta 的解析库 —— 生产环境不该用预发布版，尤其涉及反序列化逻辑
• pkg.go.dev 页面显示 “Last updated: 2022-05-17” 且 Open Issues > 200 的包，哪怕当前没 CVE，也意味着作者大概率已弃坑
CI 中加一道 go mod verify 为什么比只跑 govulncheck 更关键
很多团队只在 CI 加 govulncheck ./ || exit 1，这不够。因为：
• govulncheck 依赖网络拉取数据库，若 sum.golang.org 临时不可达，整个检查就跳过，CI 仍通过
• go mod verify 是离线操作，只读本地 go.sum 和缓存，能立刻发现 checksum 不一致或缺失条目，且失败即中断构建
• 它还能捕获 replace 指令带来的风险：比如 replace github.com/gorilla/mux => ./local-fork，go mod verify 会报 replaced module not verified，提醒你这个 fork 是否经过审计
• 建议组合使用：go mod verify && govulncheck -deps=1 ./，前者保底，后者查已知 CVE；两者都失败才阻断 PR
立即学习“go语言免费学习笔记（深入）”；
真正容易被忽略的点在于：所有扫描工具都只看“代码里写了什么”，没人替你判断“这段依赖是否真被用到”。一个github.com/evil/pkg 可能只是某测试工具链的传递依赖，从没进过生产构建，但它的 init() 函数仍会在 go test 时执行——而 govulncheck 默认不扫测试依赖。 
