Go 如何缓解来自软件依赖的恶意攻击？

最新推荐文章于 2024-04-30 16:28:10 发布

煎鱼（EDDYCJY）

最新推荐文章于 2024-04-30 16:28:10 发布

阅读量290

点赞数 3

文章标签： golang 开发语言后端

本文链接：https://blog.csdn.net/EDDYCJY/article/details/137817661

版权

大家好，我是煎鱼。

前段时间有一起比较严重的安全事故，引起了国内外的集中关注、讨论和走查。听说个别朋友在当时都加塞了新的活，得加班加点检查一下。

这一连串事件，不禁让我思考到 Go 是如何解决和防护攻击相关的问题。周末翻到了《How Go Mitigates Supply Chain Attacks^[1]》，内容物就是针对 Go 如何解决来自软件依赖的恶意攻击是相关的。基于此整理和调整后分享给大家。

安全事故：xz 核弹后门

这是今天内容的行业背景，如果没提前了解的同学可以看看。@ZainanZhou 大佬的对这件事的概述。

如下图：

什么是供应链攻击

现代软件工程是协作的，并且基于开源软件（例如：GitHub）。这种做法使得目标容易受到供应链攻击，即通过破坏软件项目的依赖关系来进行攻击。

通过软件依赖项进行攻击

尽管有任何流程或技术措施，每个依赖关系都不可避免地存在信任关系的疑虑。在这一块领域，Go 工具做了许多的设计，有助于在不同阶段降低攻击的风险。

Go 对攻击的防护措施

所有构建都是 “锁定的”

外部世界的变化（例如：依赖项的新版本发布），不会自动影响 Go 的构建过程。

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

自 Go 1.16 版起，这种确定性被默认执行，如果 go.mod 文件不完整，编译命令（go build、go test、go install、go run 等）将会失败。

唯一会改变 go.mod（进而改变编译）的命令是：go get 和 go mod tidy。这些命令不会自动运行，也不会在 CI 中运行，需要人为控制。因此对依赖关系树的修改必须经过深思熟虑，并有机会通过代码审查发现。

这一点对安全性非常重要，因为当 CI 系统或新机器运行 go build 时，已签入的源代码是最终和完整的真实来源（即什么将被构建）。第三方无法对此产生影响。

此外，当使用 go get 添加依赖关系时，其传递依赖关系会按照依赖关系的 go.mod 文件中指定的版本添加，而不是按照它们的最新版本添加，这要归功于 go mod 的最小版本选择设计。

即使调用 go install example.com/cmd/devtoolx@latest也需要符合上述条件。在某些生态系统中，其配置的等效项会绕过固定版本。

在 Go 中，example.com/cmd/devtoolx 的最新版本将被获取，但所有依赖关系将由其 go.mod 文件设置版本控制。

也就是说，如果某个模块被入侵，并发布了新的恶意版本，在明确更新该依赖关系之前，任何人都不会受到影响，这就为生态系统提供了审查变更的机会和检测事件的时间。

版本内容永不改变

确保第三方无法影响构建所需的另一个关键属性是模块版本的内容不可更改。如果攻击者破坏了某个依赖项，并重新上传了现有版本，那么他们就会自动破坏所有依赖于该依赖项的项目。

Kubernetes go.sum

这就是 go.sum 文件的作用。它包含了每个依赖项的加密哈希值列表，这些依赖项都对构建有贡献。并且 go.sum 文件不完整会导致运行错误。

现阶段 go.sum 文件只有 go get 和 go mod tidy 会修改它，因此对它的任何修改都会伴随着有意的依赖关系变更。其编译保证有完整的校验和。

有了 sumdb（Checksum Database，简称 sumdb），被破坏的依赖关系，甚至谷歌运营的 Go 基础架构都不可能用修改过（如被回溯过）的源代码来攻击特定的依赖关系。你所使用的代码与其他正在使用 example.com/modulex v1.9.2 并已审核的人所使用的代码完全相同。