如何保护你的开源项目免遭供应链攻击

作者 | Anne Bertucio

译者 | 平川

策划 | 钰莹

过去一年可谓是供应链安全年。如果你是一个开源维护者，当你了解了项目的攻击面以及项目整个供应链的威胁载体，你可能会感到不知所措，甚至觉得无法克服。好消息是，2021 年也是供应链安全解决方案年。虽然还有很多工作要做，现有的解决方案也有很大的改进空间，但已经可以对项目进行预防性控制，以强化供应链，免受安全威胁。

本文最初发表于谷歌开源博客，由 InfoQ 中文站翻译并分享。

在 2021 年 All Things Open 大会上，观众通过一个问答游戏了解了供应链安全的最佳实践。本文介绍了相关问题、答案和预防选项，如果你想保护自己的开源项目免受供应链攻击，那么这是一份不错的初级指南。这些建议遵循 SLSA 框架 和 OpenSSF 评分标准，其中许多都可以通过 Allstar 项目 自动实现。

• 一个典型的软件供应链的例子，以及链中每个环节上可能发生的攻击的例子 *

问题 1：如何防止你的开发者账号被接管？

1. 答：使用多因素身份验证（可能的话，使用安全密钥）

2. 核心维护人员共享一个账号

3. 所有密码务必采用 rot13 加密

4. 使用 IP 白名单

原因和方法：一个能够访问开发者账户的恶意行为者可以伪装成一个已知的贡献者并提交坏代码。鼓励贡献者使用多因素认证（MFA），不仅是在他们发送提交的平台上，也包括与贡献相关的账户，如电子邮件。在可能的情况下，安全密钥是推荐的 MFA 形式。

问题 2：如何避免合并恶意提交？

1. 答：要求所有的提交都要由提交者之外的人审核

2. 在所有提交上自动运行测试

3. 在所有提交中扫描“bitcoin”一词

4. 只接受账号年龄超过 1 年的贡献者的提交

原因和方法：自合并（也称为单边修改）会带来两种风险：（1）窃取了贡献者账号的攻击者可以直接向项目注入恶意代码；（2）心怀善意的人也可能在合并提交时意外引入安全风险。审核有助于避免恶意提交和意外风险。如果可能的话，将其设置为必然要求（比如使用 GitHub 的分支保护 设置）；Allstar 等工具可以帮助执行这一要求。这对应 SLSA 4 级。

问题 3：如何保护 CI/CD 管道使用的秘密？

1. 答：使用一个秘密管理工具

2. 指派一名维护人员控制对秘密的访问

3. 将秘密保存为环境变量

4. 将秘密保存到单独的存储库

原因和方法：安全概念“深度防御 ”是指应用多个不同的防御层来保护系统和敏感数据，如秘密。秘密管理器工具（如 GCP 用户秘密管理器、HashiCorp Vault、CyberArk Conjur 或 Keywhiz）可以避免在源代码中对秘密进行硬编码，提供了集中化和审计能力，并引入了授权层以防止秘密泄露。

当在 CI 系统中存储敏感数据时，要确保它真的是用于 CI/CD，而不是更适合于密码或身份管理器的数据。

问题 4：如何防止 CI/CD 系统被滥用？

1. 答：遵循最小特权原则使用访问控制

2. 在所有拉取请求 / 提交上运行集成测试

3. 通过 GitHub 角色将所有贡献者标记为“Collaborators”

4. 在本地运行 CI/CD 系统

原因和方法：将项目存储库默认成"最小必要访问"，可以保护你的 CI/CD 系统免于意外访问和滥用。虽然运行测试很重要，但在审核之前，在所有提交 / 拉取请求上默认运行测试，会导致对 CI/CD 系统计算资源的无意滥用或恶意滥用。

问题 5：如何避免构建过程中的破坏？

1. 答：将构建定义和配置定义为代码，如 build.yaml

2. 使构建过程尽快完成，让攻击者没有时间破坏你的代码

3. 在构建系统中只使用知名组件，而且不接受替换

4. 删除构建日志，以免给攻击者留下线索

原因和方法：使用构建脚本——定义构建及其步骤的文件，如 build.yaml——这样我们就不必再手动运行构建步骤，那可能会意外引入配置错误，也减少了恶意行为者篡改构建或插入未经审核的更改的机会。这对应 SLSA 1-4 级。

问题 6：在引入依赖项前如何对其进行评估？

1. 答：使用像Scorecards和deps.dev这样的工具来评估风险和传递性变更

2. 检查包 url 旁边的小“锁”图标

3. 仅使用 GitHub 星数超过 1000 的依赖项

4. 仅使用未更换过维护者的依赖项

原因和方法：没有一个明确的标准可以告诉你一个包是 "好 "还是 "坏"；每个项目都有不同的安全配置和风险容忍度。收集依赖项的信息，以及它可能引入的传递性变更，可以帮助你判断在项目中使用某个依赖项是否 "安全"。像 Open Source Insights （dols.dev）这样的工具可以提供完整的依赖关系图，而 Scorecards 可以对软件包的多个风险评估指标打分，包括安全策略的使用、MFA 和分支保护。

一旦你明确了自己所使用的依赖项，就可以定期运行一个漏洞扫描工具，如 Open Source Vulnerabilities，帮助你了解最新版本和补丁。许多漏洞扫描工具还可以应用自动升级。

问题 7：如何保证构建和你想的一样（即验证）？

1. 答：使用一个可以生成来源证明的构建服务

2. 检查最后一次提交，确保其来自可信任的提交者

3. 使用隐写术将项目标识嵌入构建中

4. 每次发布都运行一致性测试

原因和方法：显示构建的来源和工件（构建的出处），向用户表明该构建没有被篡改，是正确的构建。组件来源有许多；一种提供组件的方法是使用构建服务，生成和验证可以表明出处的数据。这对应 SLSA 2-4 级。

问题 8：从注册中心选择工件时应该注意什么？

1. 答：选择经过加密和签名验证的工件

2. 不要使用过于古老的组件

3. 时间戳：只使用最近创建的工件

4. 官方认可：寻找值得信赖的品牌或标准机构的标识

原因和方法：正如你应该为项目生成带有来源证明的签名构建（SLSA 2-4 级），你在使用别人的工件时也应该做同样的验证。标识和其他基于品牌的认可形式很容易被篡改，进而被网络蟑螂（typosquatters）用来伪造合法性；寻找像签名一样的防篡改验证。例如，Sigstore 帮助开源软件项目做构建签名，并验证其他人的构建。

提高项目安全性是一个持续的过程。这些建议中有一些可能并不适用于你当前的项目，但你每采取一个提高项目安全性的步骤都是朝着正确的方向迈进。

开源项目安全性的相关资源：

SLSA：一个供应链安全等级框架

Scorecards：安全最佳实践应用评价工具

Allstar：一个确保采用安全最佳实践的 GitHub 应用

Open Source Insights：开源项目依赖项的可搜索可视化

OSV：面向开源的漏洞数据库和自动化基础设施

原文链接：

https://opensource.googleblog.com/2021/10/protect-your-open-source-project-from-supply-chain-attacks.html

你也「在看」吗？👇