Go 如何应答供应链攻打

Go 官网博客引见了他们应答供应链攻打的缓解措施。据称，Go 的工具链和设计在各个阶段均蕴含降落攻打危险的思索。

一切构建都被“锁定 (locked)”

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

与其余大少数软件包治理器所经常使用的性能文件不同，Go modules 没有独自的解放列表和用于锁定特定版本的 lock 文件。介入 Go构建的每个依赖项的版本齐全由主模块的go.mod文件选择。

从 Go 1.16 开局，上述操作自动口头，假设go.mod不完整，构建命令将失败。惟一会扭转go.mod的命令是 go get和 go modtidy。这些命令通常不会智能运转或在 CI 中运转，因此这种对依赖相关树的扭转通常都是刻意为之，可在代码审查阶段被发现。

这关于安保性十分关键，假设一个模块被入侵并颁布了一个新的恶意版本，那么在明白降级该依赖项之前，任何人都不会遭到影响，从而为生态提供了审查更改和检测事情的时期。

版本内容永不扭转

确保第三方不会影响构建的另一个关键属性是，module版本的内容无法扭转。由于假设破坏依赖项的攻打者可以从新上行现有版本，他们就可以智能破坏一切依赖该依赖项的名目。

这正是go.sum文件的用途。它蕴含有助于构建的每个依赖项的加密哈希列表。雷同，不完整的go.sum会造成失误，并且只能经常使用go get和go modtidy对它启动修正。因此，对它的任何修正都会随同着客观的依赖相关扭转。

大少数名目在开发环节中都会经常使用版本控制系统 (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 littledependency”(复制胜于依赖)。

Go module 对自己的“零依赖”标签十分自豪。假设开发者须要经常使用一个库，他会发现这个库不会让他依赖其余作者和一切者的几十个 module。

这象征着只要大批依赖项就可以构建丰盛、复杂的运行程序。毕竟无论工具多好，它都无法消弭重用代码所触及的危险，因此最强的缓解措施一直是只要一个小的依赖树。

本文题目：Go 如何应答供应链攻打?