go.sum是Go模块系统的信任锚点，通过校验模块ZIP和go.mod文件的SHA-256哈希值确保依赖完整性；缺失、手动编辑或未启用模块模式（GO111MODULE=off）将导致依赖链失去可信基础。
直接看 go.sum 和 go.mod 是否被篡改
模块是否可信，第一道门槛是校验完整性。go.sum 不是可选附件，而是 Go 模块系统的信任锚点。如果它缺失、被手动编辑、或 go build 时没触发校验（比如 GO111MODULE=off），整个依赖链就失去可信基础。
- 执行
go mod verify—— 它会重新计算所有模块的 checksum 并比对go.sum，失败即说明有包被替换或损坏 - 检查
go.sum文件末尾是否有大量// indirect行混在主依赖里：这常是开发者为绕过校验手动添加的“假哈希”，属于高风险信号 - 禁止出现
replace指向本地路径或非官方 fork（如replace github.com/some/lib => ./local-patch），除非你明确知道 patch 内容且已审计
用 govulncheck 扫描实际调用路径上的 CVE
只查 go list -m all 显示的版本号没用——很多漏洞只在特定函数调用链中触发。govulncheck 的价值在于它做的是“上下文感知扫描”，不是简单匹配版本号。
- 运行
govulncheck ./（Go 1.21+ 内置），注意输出里的Call stack字段：它告诉你漏洞代码是否真被你的项目调用到 - 若报告中出现
no vulnerable packages found但你用了旧版 crypto/tls 或 encoding/xml，别轻信——检查是否漏掉子命令参数，比如govulncheck -mode=deep ./可覆盖更多路径 - 对
indirect依赖的漏洞更要警惕：它们不会出现在go.mod里，但govulncheck仍会报出，且修复往往需要升级某个顶层依赖来间接更新
查依赖树里有没有“幽灵维护者”
一个包没有 CVE 不代表安全。长期不更新、作者失联、issue 堆积如山，比已知漏洞更危险——因为下一个漏洞大概率没人修。
- 运行
go list -m -u all，重点看那些标着[newest]却远高于当前版本的包，再访问其pkg.go.dev页面确认 “Last updated” 是否超过 12 个月 - 用
go mod graph | grep 'unmaintained|fork'快速定位可疑引入源，比如github.com/xxx/yyy被github.com/abc/def引入，而后者 star 数为 0、最近 commit 是 2022 年 - 特别留意
encoding/json、net/http、crypto/*这类标准库周边包——它们常被第三方封装，但底层逻辑一旦有缺陷，影响面极大
跑 gosec + golangci-lint 看代码级风险
依赖没问题，不代表你用得对。gosec 能发现硬编码密钥、不安全的 exec.Command 调用、弱随机数生成；golangci-lint（配好 staticcheck）能揪出 goroutine 泄漏、time.After 在循环里滥用、结构体字段未导出却暴露指针等隐性问题。
立即学习“go语言免费学习笔记（深入）”；
- 必须启用
staticcheck：在.golangci.yml中显式写enable: ["staticcheck"]，否则默认不跑——很多竞态和内存误用只靠它能捕获 - gosec 默认不扫测试文件，加
-exclude="*_test.go"反而可能漏掉 mock 里写的危险逻辑，建议保留扫描但人工跳过已知安全的测试辅助代码 - CI 中必须让这两个工具返回非零退出码：
gosec ./ || exit 1和golangci-lint run --issues-exit-code=1，否则警告等于没告警
go mod tidy 后都多看一眼 go list -m -u all 的输出，和 govulncheck 报告里那个不起眼的 indirect 标记。 
