Go 官方博客介绍了他们应对供应链攻击的缓解措施。据称，Go 的工具链和设计在各个阶段均包含降低攻击风险的考虑。

所有构建都被“锁定 (locked)”

外部变化(例如发布依赖项的新版本)不会影响 Go 构建。

与其他大多数软件包管理器所使用的配置文件不同，Go modules 没有单独的约束列表和用于锁定特定版本的 lock 文件。参与 Go 构建的每个依赖项的版本完全由主模块的go.mod文件决定。

从 Go 1.16 开始，上述操作默认执行，如果go.mod不完整，构建命令将失败。唯一会改变go.mod的命令是 go get和 go mod tidy。这些命令通常不会自动运行或在 CI 中运行，因此这种对依赖关系树的改变通常都是刻意为之，可在代码审查阶段被发现。

这对于安全性非常重要，如果一个模块被入侵并发布了一个新的恶意版本，那么在明确更新该依赖项之前，任何人都不会受到影响，从而为生态提供了审查更改和检测事件的时间。

版本内容永不改变

确保第三方不会影响构建的另一个关键属性是，module 版本的内容不可改变。因为如果破坏依赖项的攻击者可以重新上传现有版本，他们就可以自动破坏所有依赖该依赖项的项目。

这正是go.sum文件的用途。它包含有助于构建的每个依赖项的加密哈希列表。同样，不完整的go.sum会导致错误，并且只能使用go get和go mod tidy对它进行修改。因此，对它的任何修改都会伴随着主观的依赖关系改变。

VCS 是事实来源

大多数项目在开发过程中都会使用版本控制系统 (VCS)，在其他生态中，这些项目还需要上传到中心软件包仓库 (比如 npm)。这意味着有两个帐户可能会受到破坏，即 VCS 主机和中心软件包仓库。后者使用得更少，也更容易被忽视。这也意味着更容易在上传到仓库的版本中隐藏恶意代码，特别是如果源码作为上传的一部分被例行修改。

Go 没有诸如中心软件包仓库帐户这类东西。包的导入路径嵌入了直接从 VCSgo mod download 获取其模块所需的信息，其中 VSC 上的标签定义了 module 版本。

仅构建代码，但不执行

Go 工具链有一个明确的安全设计目标：无论是获取还是构建代码，都不会让该代码执行，无论代码是否不受信任或者恶意。

这是一种有意义的风险缓解措施，假如你正在执行一个二进制文件或测试一个只使用一个子集的包模块的依赖。例如，如果example.com/cmd/devtoolx在 macOS 上构建和执行，那么针对 Windows 的依赖或example.com/cmd/othertool的依赖就不可能危害到你的机器。

在 Go 中，不为特定构建提供代码的 module 对于构建没有安全影响。

“复制胜于依赖”

最后一项(也可能是最重要)供应链攻击风险缓解措施也是技术含量最低的：Go 有拒绝大型依赖树的文化，并且更喜欢复制而不是添加新的依赖。

这可以追溯到 Go 的一句谚语：“a little copying is better than a little dependency”(复制胜于依赖)。

Go module 对自己的“零依赖”标签非常自豪。如果开发者需要使用一个库，他会发现这个库不会让他依赖其他作者和所有者的几十个 module。

这意味着只需少量依赖项就可以构建丰富、复杂的应用程序。毕竟无论工具多好，它都无法消除重用代码所涉及的风险，因此最强的缓解措施始终是只有一个小的依赖树。

本文转自OSCHINA

本文标题：Go 如何应对供应链攻击?

本文地址：https://www.oschina.net/news/189878/golang-supply-chain