软件供应链安全¶

简介¶

任何软件都不是在真空中开发的；无论用于开发它的技术如何，软件都嵌入在软件供应链（SSC）中。根据 NIST 的定义，一个实体的 SSC 可以是“创建、转换和评估软件制品质量和策略符合性的一系列步骤”。从开发人员的角度来看，这些步骤涵盖了整个 SDLC，并通过使用各种组件和工具来完成。从开发人员角度来看，特别相关的常见组件示例（绝非详尽无遗）包括

IDE 和代码编辑器
内部开发的源代码
第三方软件库
版本控制系统（VCS）
构建工具（Maven, Rake, make, Grunt 等）
CI/CD 软件（Jenkins, CircleCI, TeamCity 等）
配置管理工具（Ansible, Puppet, Chef 等）
包管理软件和生态系统（pip, npm, Composer 等）

这些组件中的每一个都必须得到保护；单个组件中的缺陷，例如易受攻击的第三方依赖项或配置错误的 VCS，都可能使整个 SSC 处于危险之中。因此，为了加强软件供应链安全（SCSS），开发人员应该对 SSC 是什么、针对它的常见威胁以及可用于降低 SSC 风险的实践和技术有一个总体了解。

威胁格局概述¶

鉴于 SSC 的广度和复杂性，SSC 的威胁格局同样广泛也就不足为奇了。威胁包括依赖混淆、上游提供商基础设施的泄露、代码签名证书的盗窃以及 CI/CD 系统漏洞利用。更广泛地说，威胁可以根据它们试图破坏的供应链组件分为四类 [4,5]

源代码威胁。这类威胁主要针对破坏源代码的完整性，这些源代码随后被构建和部署，或可能被其他软件项目使用。此类别中的威胁包括 VCS 漏洞利用、将恶意或易受攻击的代码引入代码库，或从未经授权的分支构建代码。
构建环境威胁。这些威胁修改软件制品，但不更改底层源代码或利用构建过程本身。示例包括构建缓存投毒、损害构建工具使用的特权帐户，或发布从不可信来源构建的软件。
依赖项相关威胁。这些威胁源于直接和间接软件依赖项的使用。最常见的威胁是使用易受攻击或被入侵的依赖项。
部署和运行时威胁。这些威胁利用部署过程或运行时环境。常见示例包括破坏特权 CI/CD 帐户、软件配置错误以及部署受损的二进制文件。

寻求利用 SSC 的威胁行为者的特征也同样多样。尽管 SSC 入侵通常与高度复杂的威胁行为者相关联，但这种复杂性对于攻击 SSC 并非固有必要，特别是如果攻击侧重于入侵安全实践薄弱的实体的 SSC。威胁行为者的动机也差异很大。SSC 漏洞利用可能导致任何组织资产的机密性、完整性、和/或可用性丧失，从而实现广泛的攻击者目标，例如间谍活动或经济利益。

最后，必须认识到许多 SSC 威胁具有跨多个实体传播的能力。这是由于消费者-供应商关系是 SSC 不可或缺的一部分。例如，如果一个大型软件供应商（无论是专有软件还是开源软件）被入侵，许多下游的使用实体也可能因此受到影响。2020 年 SolarWinds 和 2021 年 Codecov 事件是这方面的优秀现实世界案例。

缓解措施和安全最佳实践¶

缓解与 SSC 相关的风险可能看起来令人生畏，但并非必须如此。即使对于可能侧重于入侵上游供应商的复杂攻击，单个组织也可以采取合理措施来保护自己的资产并降低风险，即使其供应商受到损害。尽管 SSCS 的某些部分可能仍超出开发团队的直接控制范围，但这些团队仍必须尽其所能改进其组织中的 SSCS；以下指南旨在作为开发人员实现这一目标的起点。

通用¶

以下描述的实践是可用于缓解与各种威胁类型相关的风险的通用技术。

实施强大的访问控制¶

受损的账户，尤其是特权账户，对 SSC 构成重大威胁。账户劫持可能允许攻击者执行各种恶意行为，包括将代码注入合法依赖项、操纵 CI/CD 流水线执行，以及用恶意制品替换良性制品。因此，对构建、开发、版本控制和类似环境实施强大的访问控制至关重要。最佳实践包括遵守最小权限和职责分离的基本安全原则、强制 MFA、轮换凭据，并确保凭据从不以明文存储或传输，或提交到源代码控制中。

日志记录和监控¶

在考虑 SSCS 时，不应忽视检测控制的重要性；这些控制对于检测攻击和实现及时响应至关重要。在 SSCS 的背景下，日志记录至关重要。所有涉及 SSC 的系统，包括 VCS、构建工具、交付机制、制品库以及负责运行应用程序的系统，都应配置为记录身份验证尝试、配置更改以及其他有助于识别异常行为或对事件响应工作至关重要的事件。整个 SSC 中的日志必须在深度和广度上都足够，以支持检测和响应。

然而，仅仅记录事件是不够的。这些日志必须被监控，并在必要时采取行动。考虑到 SSCs 的复杂性，最好使用集中式 SIEM、日志聚合器或类似工具。无论使用何种技术，基本目标保持不变：日志数据应该是可操作的。

利用安全自动化¶

对于复杂的 SSCs，安全任务的自动化，例如扫描、监控和测试至关重要。这种自动化虽然不能替代熟练专业人员进行的手动审查和其他操作，但它能够以手动干预难以实现的规模和一致性来检测，并在某些情况下响应漏洞和潜在攻击。支持自动化的工具类型包括 SAST、DAST、SCA、容器镜像扫描器等。能够为组织带来最大价值的具体工具将根据组织的特点而有很大差异。然而，无论使用何种类型的工具和供应商，都必须承认这些工具本身必须得到维护、保护和正确配置。如果未能做到这一点，实际上可能会增加组织的 SSC 风险，或者至少未能为组织带来有意义的益处。最后，必须清楚地理解，这些工具只是整个 SSCS 计划的一个组成部分；它们不能被视为全面的解决方案，也不能仅依靠它们来识别所有漏洞。

缓解源代码威胁¶

以下描述的实践有助于降低与源代码和开发相关的 SSC 风险。

同行评审¶

手动代码评审是降低 SSC 风险的一种重要且成本相对较低的技术；这些评审既可以作为检测控制，也可以作为威慑。评审应由具备所用技术和安全编码流程经验的同行执行，并应在代码合并到源代码控制系统之前进行 [3]。评审应查找无意的安全缺陷以及可能用于恶意目的的有意代码。评审结果应记录下来，以便将来需要时进行查阅。

版本控制系统的安全配置¶

源代码控制系统的泄露或滥用一直被认为是重大的 SSC 风险 [4,5]。强大的访问控制和日志记录与监控这些通用的安全最佳实践是帮助保护 VCS 的两种方法。VCS 系统特有的安全功能，例如 Git 中的受保护分支和合并策略，也应加以利用。您可以在此文档中找到各种推荐策略。有一些工具可以帮助管理 SCM 系统的配置，例如 Legitify，这是由 Legit security 开发的一个开源工具。Legitify 旨在检测 GitHub 和 GitLab 中的错误配置，并协助实施最佳实践。无论 VCS 添加了任何安全控制，都必须记住绝不能将秘密提交到这些系统中。

安全开发平台¶

IDE、开发插件和类似工具可以帮助辅助开发过程。然而，像所有软件一样，这些组件可能存在漏洞并成为攻击向量。因此，采取措施不仅要确保这些工具的安全使用，还要保护底层系统至关重要。开发系统应安装端点安全软件，并对其进行威胁评估 [2]。在开发过程中只能使用受信任的、经过充分审查的软件；这不仅包括 IDE 等“核心”开发工具，还包括任何插件或扩展。此外，这些工具应作为组织系统资产的一部分进行盘点。

缓解依赖项威胁¶

以下描述了与安全使用依赖项相关的最佳实践和技术。

评估供应商¶

在将第三方服务、产品或软件组件纳入 SSC 之前，应彻底评估供应商及其具体产品或服务的安全性。这适用于开源和专有产品。分析的形式和范围将根据所考虑组件的关键性和性质而有很大差异。组件成熟度、安全历史以及供应商对过去漏洞的响应在几乎所有情况下都是有用的信息。对于大型供应商或服务产品，确定解决方案是否已根据第三方评估和认证（例如针对 FedRAMP、CSA 或各种 ISO 标准（ISO/IEC 27001、ISO/IEC 15408、ISO/IEC 27034）进行的评估和认证）进行评估，可以是一个有用的数据点，但不能完全依赖。

由于其透明的特性，开源项目提供了额外的评估机会。需要考虑的问题包括 [6]

项目是否积极维护？
项目在相关社区中是否足够受欢迎和知名？
项目是否足够成熟？
正在评估的产品或版本是否为“发布”版本，例如，不是 alpha、beta 或可比较的版本？
考虑到项目的复杂性，项目是否有足够的维护者和贡献者？
项目是否保持其依赖项更新？
项目是否有足够的测试覆盖率，并且测试是否包含安全相关的规则？
项目是否有完善的文档，并且文档是否包含如何安全使用组件的指导？
项目是否拥有既定且有文档记录的漏洞报告流程，并且这些漏洞是否及时得到处理？
项目的预期用途是否与其许可证一致？

理解并监控软件依赖项¶

虽然第三方软件依赖项可以大大加速开发过程，但它们也是与现代应用程序相关的主要风险之一。依赖项不仅在将其纳入应用程序之前必须仔细选择，而且在整个 SDLC 过程中也必须仔细监控和维护。为了实现这一点，了解软件所消耗的各种依赖项是关键的第一步。为了促进这一点，可以使用 SBOM。这些 SBOM 的生成和消费都应该自动化，最好作为组织 CI/CD 过程的一部分。

一旦组织清点了依赖项，它还必须监控它们是否存在已知漏洞。这也应尽可能自动化；OWASP Dependency Check 或 retire.js 等工具可以协助此过程。此外，还可以监控 NVD、OSVDB 或 CISA KEV 目录等来源，以查找与组织 SSC 中使用的依赖项相关的已知漏洞。

SAST¶

尽管使用 SAST 检测定制开发代码中的潜在安全问题是一种广泛使用的安全技术，但它也可以用于 SSC 中的开源组件 [2]。就像在内部开发代码上使用 SAST 一样，必须认识到这些工具会产生误报和漏报。因此，未经手动验证，SAST 结果不能被接受，也不应被解释为提供了项目安全的全面视图。然而，只要了解其局限性，SAST 扫描在分析内部开发或开源代码时可以证明是有用的。

锁定文件/版本锁定¶

为了降低受损或易受攻击的版本在不知不觉中被引入应用程序的可能性，应将应用程序的依赖项限制在先前已验证为合法和安全的特定版本。这通常通过使用锁定文件来实现，例如 npm 使用的 package-lock.json 文件。

构建威胁¶

以下部分描述了与保护构建相关威胁特别相关的技术。

盘点构建工具¶

了解 SSC 中使用的组件对于 SSC 的安全至关重要。这一概念也适用于构建工具。所有构建工具的清单，包括版本和任何插件，都应自动收集和维护。还必须监控漏洞数据库、供应商安全公告和其他来源，以查找与已识别构建工具相关的任何漏洞。

强化构建工具¶

受损的构建工具可能导致广泛的漏洞利用，因此成为攻击者的诱人目标。因此，构建过程中使用的所有基础设施和工具都必须强化以降低风险。强化构建环境的技术包括 [2]

确保构建工具位于适当隔离的网络中。
使用 DLP 和其他工具和技术来检测和防止数据外泄。
禁用/移除任何未使用的服务。
使用版本控制系统管理和存储流水线配置。

强制代码签名¶

从软件消费者的角度来看，在利用软件之前，只接受经过数字签名并验证签名的组件是确保组件真实性且未被篡改的重要一步。对于执行代码签名的人员，代码签名基础设施必须彻底强化。否则可能导致代码签名系统受损，并引发进一步的漏洞利用，包括那些针对软件消费者的攻击。

使用私有制品库¶

使用私有制品库增加了组织对 SSC 中使用的各种制品的控制。制品在被允许进入私有制品库之前应进行审查，并且组织必须确保这些制品库的使用无法被绕过。尽管使用私有制品库可能会增加额外维护或降低敏捷性，但它们也可以成为 SSCS 的重要组成部分，特别是对于敏感或关键应用程序。

对构建脚本和配置使用源代码控制¶

VCS 的好处不仅限于源代码控制，对于与 CI/CD 流水线相关的配置和脚本尤其如此。对这些文件强制执行版本控制，可以在配置更新过程中纳入评审、合并规则和类似控制。使用 VCS 还可以增加可见性，方便地查看引入的任何更改，无论是恶意还是良性的 [2]。

验证溯源性/确保生成足够的元数据¶

确保 SSC 组件来自受信任的来源且未被篡改是 SSCS 的重要组成部分。SLSA 1.0 中定义的溯源性（“关于软件制品的可验证信息，描述了其生产地点、时间和方式”）的生成和消费是其中的重要部分。溯源性应由构建平台（而非本地开发系统）生成，攻击者难以伪造，并包含将结果准确关联回构建者所需的所有详细信息 [7]。符合 SLSA 1.0 的溯源性可以使用 FRSCA 或 Github Actions 等构建器生成，并使用 SLSA Verifier 进行验证。

短暂、隔离的构建¶

构建环境的复用和共享可能允许攻击者进行缓存投毒或更容易注入恶意代码。构建应在隔离的、临时的（“短暂的”）环境中执行。这可以通过使用虚拟机或容器进行构建并在之后立即销毁环境来实现。

限制参数使用¶

尽管将用户可控参数传递给构建过程可以增加灵活性，但也会增加风险。如果用户可以修改参数以改变构建执行方式，那么具有足够权限的攻击者也将能够修改参数并可能破坏构建过程 [8]。因此，应努力最小化或消除任何用户可控的构建参数。

部署和运行时威胁¶

以下部分概述了一些可用于在部署和运行时阶段保护软件的技术。

扫描最终构建二进制文件¶

构建过程完成后，不应简单地假定最终结果是安全的。二进制组成分析有助于检测暴露的秘密、检测未经授权的组件或内容，并验证完整性 [2]。此任务应由供应商和消费者双方执行。

监控已部署软件的漏洞¶

SSCS 并非随着软件的部署而结束；已部署的软件必须进行监控和维护以降低风险。新的漏洞，无论是由于更新引入的还是仅仅是新发现（或公开的），在软件系统中都是一个持续的关注点 [4]。执行此监控时，必须采用整体方法；代码依赖项、容器镜像、Web 服务器和操作系统组件只是需要考虑的项目的一个示例。为了支持此监控，准确和最新的系统组件清单至关重要。此外，必须监控不安全的配置更改并采取行动。