Go 怎样下降供应链攻击？
发布时间：2022-04-29 10:46:20 所属栏目：安全 来源：互联网
导读：无论采用何种过程或技术手段，每个依赖性都必然存在着相互信任的关系。但是，Go 的工具和设计帮助降低了所有阶段的风险。 所有构建都已锁定 外部世界的变化，例如发布依赖性的新版本，并不会影响 Go 的构建。 与大多数软件包管理器文件不同，Go 模块没有单独
|
无论采用何种过程或技术手段，每个依赖性都必然存在着相互信任的关系。但是，Go 的工具和设计帮助降低了所有阶段的风险。 所有构建都已“锁定” 外部世界的变化，例如发布依赖性的新版本，并不会影响 Go 的构建。 与大多数软件包管理器文件不同，Go 模块没有单独的约束列表和锁文件，但是它锁定了某个特定的版本。任何 Go 构建的每个依赖性的版本完全取决于主模块的 go.mod 文件。 从 Go 1.16 开始，这种决定论就会强制执行，并且在 go.mod 不完整的情况下，构建命令(gobuild、gotest、goinstall、gorun……)将会失败。唯一会改变 go.mod(因此也会改变构建)的命令是 goget 和 gomodtidy。这些命令不会被自动或在 CI 中运行，所以对依赖树的改变必须是故意的，并且有机会通过代码审查。 这对安全非常重要，因为当 CI 系统或新机器运行时，签入 (checked-in) 的源码是最终的和完整的，代码将说明什么会被构建，第三方没有办法影响它。 此外，当用 goget 添加依赖性时，由于最小版本的选择，它的交叉依赖会按照依赖的 go.mod 文件中指定的版本添加，而不是按照最新版本。同样的情况也发生在调用 goinstallexample.com/cmd/devtoolx@latest 的情况下，在某些生态系统中，它的等价物会绕过 pinning。在 Go 中，example.com/cmd/devtoolx 的最新版本将被获取，但所有的依赖性将由其 go.mod 文件设置。 如果一个模块被破坏，新的恶意版本被发布，在它们明确更新该依赖性之前，不会受到任何影响，这就提供了审查更改的机会，并让生态系统有了足够的时间来检测事件。 VCS 是真理的源泉 大多数项目是通过某种版本控制系统(VCS)开发的，然后在其他生态系统中，上传到包存储库。这意味着有两个账户可能被入侵，即 VCS 主机和包存储库，后者使用得更少，更容易被忽视。这也意味着在上传到存储库的版本中更容易隐藏恶意代码，尤其是在上传过程中经常修改源代码的情况下，比如说将其最小化。 在 Go 中，不存在包存储库账户这样的东西。包的导入路径嵌入了 gomoddownload 所需要的信息，以便直接从 VCS 中获取其模块，其中标签定义了版本。 我们确实有 Go Module Mirror，但那只是一个代理。模块作者不需要注册账户，也不需要向代理上传版本。代理使用与 go 工具相同的逻辑(事实上，代理运行 gomoddownload)来获取和缓存版本。由于校验数据库保证给定的模块版本只能有一个源树，每个使用代理的人都会看到与绕过代理直接从 VCS 获取的结果相同。(如果该版本在 VCS 中不再可用，或者其内容发生了变化，直接获取将导致错误，而从代理获取可能仍然有效，提高了可用性并保护生态系统免受 “左键”问题的影响)。 在客户端运行 VCS 工具会暴露出一个相当大的攻击面。这也是 Go Module Mirror 的另一个作用：代理上的 Go 工具在一个强大的沙盒内运行，并被配置为支持所有的 VCS 工具，而默认的是只支持两个主要的 VCS 系统(git 和 Mercurial)。任何使用代理的人仍然可以获取使用非默认的 VCS 系统发布的代码，但攻击者在大多数安装中无法接触到这些代码。 “一点复制比一点依赖要好” 在 Go 生态系统中，最后一个也许也是最重要的软件供应链风险缓解措施是最没有技术含量的一个：Go 有一种拒绝大型依赖树的文化，宁愿复制一下也不愿意添加新的依赖。这可以追溯到 Go 的一个谚语：“一点复制比一点依赖要好”。高质量的可重用 Go 模块自豪地戴上了 “零依赖” 的标签。如果你发现自己需要一个库，你很可能会发现它不会导致你依赖其他作者和所有者的几十个模块。 丰富的标准库和其他模块(golang.org/x/……的模块)也支持这一点，这些模块提供了常用的高级构建模块，如 HTTP 栈、TLS 库、JSON 编码等。 所有这些意味着只需少量的依赖性就可以建立丰富、复杂的应用程序。无论工具有多好，它都不能消除重复使用代码的风险，所以最有力的缓解措施永远是一个小的依赖树。 （编辑：江门站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐