在持续集成中生成依赖清单并跟踪安全更新

持续集成里的依赖安全，最好拆成两份可以归档的结果：一份回答“这次构建实际用了哪些 Go 模块、当前有没有可用更新”，另一份回答“已知漏洞是否沿着调用关系真正影响了代码”。前者可以用 go list -m -u -json all 生成，后者用 govulncheck -json ./... 生成。这样既能追踪依赖变化，也不会把一条没有实际调用路径的提示直接当成线上漏洞。

官方地址：https://go.dev/doc/security/vuln/

把模块清单、更新信息和漏洞结果分成独立产物

go.mod 描述模块要求，go.sum 主要记录校验和，它们都不是一次构建的完整安全结论。CI 可以把模块、当前版本和可用更新导出为一个 JSON 流，再把漏洞扫描结果单独保存：

# 建立可下载的构建产物目录
mkdir -p artifacts

# 记录当前模块及 Go 工具能发现的可用更新
go list -m -u -json all > artifacts/go-modules.json

# 记录按源码调用关系计算的漏洞结果；扫描失败码由后续脚本处理
govulncheck -json ./... > artifacts/govulncheck.json

这两个文件用途不同：模块清单适合和上一次构建做版本差异，漏洞 JSON 适合按漏洞 ID、受影响模块、调用栈和修复版本建立处理记录。不要把命令输出包装成“已经修复”的证明，它只说明本次扫描得到的判断。

在 CI 阶段固定生成命令并保留失败产物

安全扫描最容易被忽略的细节，是漏洞命中后任务很快退出，导致结果文件还没有上传。可以先保存命令的退出码，完成产物上传后再把原退出码交给 CI：

# 让扫描结果在任务失败时仍然能被上传
set +e
govulncheck -json ./... > artifacts/govulncheck.json
scan_status=$?
set -e

# 这里放 CI 自己的 artifact 上传动作
echo "扫描退出码：$scan_status"
exit "$scan_status"

安装工具时可以使用 Go 官方教程中的模块路径；生产流水线应把工具版本纳入团队的构建策略，避免同一个提交在不同时间拿到完全不同的工具链。构建产物至少保留模块清单、扫描 JSON、Go 版本和提交标识，清理规则则按组织的审计周期配置。

按实际调用关系判断是否升级依赖

Go 官方把 govulncheck 定位为低噪声检查：它会结合漏洞数据库和代码中的调用关系，优先展示真正到达易受影响函数或方法的结果。输出里的“受影响模块”只是起点，处理时还要看漏洞 ID、当前版本、Fixed in 版本以及调用栈。

如果结果只有“导入了包含漏洞符号的包”，但没有通向该符号的调用栈，应先按官方说明评估是否适用；如果调用栈接收外部输入并指向易受影响函数，则优先升级到报告给出的修复版本，再运行单元测试、集成测试和同一套扫描。不要为了让任务变绿而删除依赖、屏蔽扫描或随意改写版本范围。

用周期任务持续跟踪依赖变化

提交触发的扫描能挡住新增风险，但依赖没有变化时，漏洞数据库仍可能新增报告。因此可以把同一脚本接到每日或每周的定时 CI，并把结果与提交号、Go 版本和扫描时间一起归档。出现更新时，再建立升级分支，执行 go get 模块@修复版本、go mod tidy 和完整回归。

复查时特别注意多模块仓库的 go.work、replace、exclude 设置，以及私有模块访问权限。清单应代表 CI 实际构建的工作区，而不是开发机上另一套模块解析结果。对比两次产物时，至少确认新增模块、版本变化、被移除模块和扫描结果变化四项。

相关问题

go.sum 能不能直接当依赖清单？

不能。它更适合做模块内容校验，不能直观表达本次构建解析出的模块集合、可用更新或漏洞调用路径。用 go list -m -u -json all 生成独立清单更清楚。

扫描发现漏洞后是否必须立刻升级所有相关模块？

不必一刀切。先读漏洞说明和调用栈，确认输入边界与实际使用方式；能升级时优先采用报告中的修复版本，并用测试和再次扫描确认升级没有引入新的问题。