go.sum不是白名单而是校验快照，因它只验证已引入模块的完整性，不阻止新模块通过go.mod require或间接引用进入构建；真正白名单须在解析阶段拦截，如用goprivate+vendor+精确module@version校验。
Go 模块依赖不能靠 go list -m all 手动扫一眼就完事，真正安全的白名单机制必须阻断非法模块在构建阶段进入依赖图，而不是等运行时或扫描时才发现问题。
为什么 go.sum 不是白名单，而只是校验快照
go.sum 文件记录的是每个模块版本的哈希值，作用是验证下载内容是否被篡改——但它不控制“哪些模块允许被引入”。只要 go.mod 里写了 require github.com/bad/pkg v1.2.3，哪怕该模块从未出现在你历史 go.sum 中，go build 仍会自动拉取并加入构建。攻击者只需诱使开发者执行一次 go get 或合并含恶意 require 的 PR，就能注入供应链风险。
- 现象：CI 流程通过了，
go.sum也无变更，但新 commit 引入了未审计的第三方模块 - 本质：go.sum 是“完整性证明”，不是“准入策略”
- 正确姿势：白名单必须作用于
go.mod解析阶段，而非事后校验
用 GOPRIVATE + vendor 实现模块来源硬隔离
Go 官方提供的 GOPRIVATE 环境变量可强制 Go 工具链跳过 proxy 和 checksum 验证，但它本身不阻止模块加载——真正起隔离作用的是配合 go mod vendor 后的离线构建流程。
- 设置
GOPRIVATE=*.internal,github.com/your-org/*，让私有模块不走 proxy - 执行
go mod vendor将所有依赖（含 transitive）拷贝到vendor/目录 - CI 中加
go build -mod=vendor，此时构建完全不联网，只从vendor/读取 - 关键点：把
vendor/提交进 Git，并对目录做定期 diff —— 新增或删减模块必须走 CODEOWNERS 审批
自动化校验依赖是否在预审白名单内
仅靠人工 review go.mod 易漏，需脚本在 PR CI 阶段强制比对。白名单不应是正则或模糊匹配，而应是精确的 module@version 元组列表。
- 白名单文件示例：
allowed-deps.txt，每行格式为github.com/sirupsen/logrus@v1.9.3 - 校验脚本核心逻辑：
go list -m all | cut -d' ' -f1,2输出所有模块+版本，逐行比对是否在白名单中 - 拒绝未列明的模块，包括 indirect 依赖 —— 即使没出现在
go.modrequire 块里，只要被实际 import 就算违规 - 注意：
golang.org/x/net@none这类伪版本必须显式列入白名单，否则校验失败
go.mod replace 不能绕过白名单校验
有人试图用 replace github.com/old => github.com/fork/new 替换模块来规避审查，但这只是重定向源码路径，不改变模块标识符。白名单校验必须基于 go list -m all 输出的原始 module path，而非本地 replace 后的路径。
- 错误做法：校验脚本只检查
vendor/下目录名，结果replace后的 fork 被当成合法模块放行 - 正确做法：在校验前先运行
go mod edit -dropreplace临时清除 replace，再执行go list -m all - 更稳妥：CI 中禁用 replace，所有 fork 必须以独立 module path 发布（如
github.com/your-org/logrus-fork），并单独审批
最易被忽略的一点：白名单必须覆盖所有间接依赖，且每次 go get 后都要重新生成和审批 —— 因为一个 go get 可能悄悄升级 transitive 依赖，而 go.mod 文件里未必显示出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
