vendor文件夹本身不提供安全审计能力，它只是依赖的本地副本，既不自动检测漏洞也不验证签名或校验和；真正起作用的是使用govulncheck等工具在正确时机对go list -m -json all输出的准确依赖树进行扫描，并配合go mod verify确保vendor与go.sum一致。

vendor 文件夹本身不提供安全审计能力

Go 的 vendor 文件夹只是依赖的本地副本，它既不自动检测漏洞，也不验证签名或校验和。把依赖“复制进来”不等于“更安全”，反而可能掩盖过期、带已知 CVE 的旧版本。真正起作用的是你用什么工具、在什么时机、对哪些内容做检查。

go list -m -json all 是获取当前依赖树的可靠起点

静态扫描工具（如 govulncheck、trivy）都需要知道项目实际解析出的模块版本，而 go.mod + vendor/ 组合下，go list -m -json all 会准确反映 vendor 中锁定的版本（前提是 go mod vendor 已执行且未手动删改）。别直接读 vendor/modules.txt —— 它格式松散，缺少 version、replace、indirect 等关键信息。

• 必须在项目根目录运行，且 GO111MODULE=on（默认已启用）
• 如果输出里出现 "Indirect": true，说明该模块是传递依赖，仍需审计 —— 很多 CVE 就藏在这里
• 注意 Replace 字段：若指向本地路径或 fork 仓库，标准漏洞数据库可能无法匹配，得人工确认补丁状态

govulncheck 会忽略 vendor 目录里的未引用代码

govulncheck 默认只分析 go list -deps 能到达的包，也就是说，哪怕 vendor/ 里有 50 个模块，只要没被 import 过，它就不会查。这看起来省时间，但容易漏掉两类风险：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 你暂时注释掉、但未来可能启用的模块（比如实验性功能）
• 被其他依赖间接引入、但未显式 import 的子模块（例如 github.com/some/pkg/v2/internal/xxx）
• 解决办法：加 -tests 参数，并确保测试文件里 import 了相关路径；或者用 go list -m all 配合 trivy fs 扫整个 vendor/ 目录（代价高，CI 中慎用）

vendor 后的 go.sum 不再自动更新，校验失效风险真实存在

执行 go mod vendor 时，go.sum 会被重写为仅包含 vendor 中实际存在的模块条目。但如果你后续手动修改 vendor/（比如删掉某个子目录、替换某个 .go 文件），go.sum 不会感知 —— 下次 go build 仍会通过，但二进制已偏离原始可验证状态。

立即学习“go语言免费学习笔记（深入）”；

• CI 中务必在 go mod vendor 后立刻跑 go mod verify，它会报错指出 go.sum 和 vendor 内容不一致
• 禁止将 vendor/ 提交后又单独修改其中文件；所有变更应走 go get 或 replace，再重新 vendor
• 如果用 git submodule 管理 vendor，记得 git commit 前检查 go.sum 是否同步更新

vendor 是锁版本的手段，不是安全层。最常被跳过的动作是：每次更新依赖后，忘记重新跑 govulncheck，也忘记核对 go.sum 是否干净 —— 这两步一断，vendor 就从保险柜变成盲区。