go mod tidy 不保障安全，仅补全和删除依赖；govulncheck 是唯一官方漏洞扫描工具，需搭配 -test 和平台环境运行；go.sum 仅校验一致性，须配合 go mod verify 和 GOSUMDB 强制校验。
go mod tidy 会自动更新依赖，但不等于安全
很多人以为执行 go mod tidy 就完成了依赖“清理”和“加固”，其实它只做两件事：补全缺失的 require、删掉未使用的依赖。它**不会检查漏洞、不校验版本是否过期、也不阻止恶意包注入**。
常见错误现象是：CI 流程里跑完 go mod tidy + go build 就认为构建干净了，结果上线后被爆出用了含 CVE 的 golang.org/x/crypto v0.12.0（该版本存在 TLS 密钥协商绕过缺陷）。
-
go mod tidy不读取go.sum中的校验和是否被篡改，仅验证格式合法性 - 如果本地 GOPROXY 配置为私有镜像源且未同步校验规则，可能拉到被污染的伪版本（如
v0.0.0-20240101000000-abc123） - 它对
replace指令完全信任，哪怕你 replace 到一个 fork 的、删掉了安全修复的分支
govulncheck 是唯一能对接 Go 官方漏洞数据库的审计工具
govulncheck 不是可选插件，而是 Go 生态中目前唯一由官方维护、直连 Go Vulnerability Database 的静态扫描器。它分析的是整个模块图（包括 transitive dependencies），不是单个 go.mod 文件。
使用场景很明确：CI 流水线卡点、PR 合并前门禁、定期巡检。别用 go list -m all + 手动查 CVE——效率低且漏报率高。
立即学习“go语言免费学习笔记（深入）”；
- 基础命令：
govulncheck ./...，输出人类可读报告；加-json供自动化解析 - 必须搭配
GOOS=linux GOARCH=amd64运行，否则可能漏掉平台相关漏洞（如net/http在 Windows 下无影响，但在 Linux 容器中触发） - 它不扫描你自己的代码逻辑漏洞（比如鉴权绕过），只识别已知 CVE 和官方标记的“high severity”问题
go.sum 不是防篡改保险，只是构建一致性快照
go.sum 记录的是每个模块的 checksum，但它**不签名、不加密、不校验上游变更**。只要有人在你之前 commit 过修改过的 go.sum，后续所有构建都会沿用那个“被认可”的哈希值。
容易踩的坑是：团队协作中把 go.sum 提交忽略（.gitignore 里写了），或 CI 环境没开启 GOSUMDB=off 却又没配可信 sumdb 地址，导致校验失败时静默 fallback 到不校验。
- 运行
go mod verify可手动触发校验，但默认不包含在go build中 - 若用私有 proxy（如 Athens），需确保其
sumdb配置与官方一致，否则go get时跳过校验 - 伪版本（
v0.0.0-yyyymmdd...）的 checksum 来自 commit hash，但 hash 本身不防重放——攻击者可 fork 后篡改再推同名 tag
自动化流程里必须分层拦截，不能只靠一个工具
真正有效的依赖安全审计不是“跑一个命令”，而是三道防线叠加：
- 第一层：CI 中强制
govulncheck -severity High,Critical ./...失败则中断构建 - 第二层：每日定时 job 运行
go list -m -u all+go list -m all | grep -E '\.v[0-9]'，识别可升级但未升级的间接依赖 - 第三层：人工 review
go mod graph输出中深度 >5 的依赖链，这类长链往往包含大量无人维护的废弃包（如github.com/alexcesaro/statsd已归档）
复杂点在于：有些漏洞只影响特定组合（比如 gin v1.9.1 + golang.org/x/net v0.17.0），单看单个模块版本无法判断。这需要工具链具备跨模块依赖图分析能力，而目前只有 govulncheck 做到了这点——其他所谓“SAST 工具”对 Go 模块图的支持仍停留在 import 路径匹配层面。
