保护软件供应链：开发人员实践指南（下）

‍‍‍‍‍2.3 验证第三方组件

开发人员通常使用应用程序编程接口(API)功能，将第三方商业软件组件作为他们现有的活动的一个方面。这些组件可以是自由开源代码软件(FOSS)或商业现成软件(COTS)。在引入这些组件时，开发人员通常会根据标准，包括组件实现的功能和组件持续工程支持模型来做出选择。在工程师将第三方组件集成之前，组织可能需要审批流程，如第2.2.4节“代码集成”所述。这过程可能包括对所考虑组件的漏洞数据库分析、安全成分分析、漏洞分析、风险评估和源代码评估，其结果表明所发现的特定组件是否被允许。一旦选定后，持续监控被发现的组件，如果可能的话，使用自动漏洞跟踪服务，对开源组件中发现的漏洞进行优先修复。安全应急响应（PSIRT）团队可能会发现新的漏洞，并提醒产品所有者进行修复。

2.3.1 第三方二进制文件

第三方软件，有时以二进制格式交付，对整合它的组织或工程师来说就像一个黑匣子。软件可能没有被主动维护，也许会有安全弱点或漏洞。

建议缓解措施

二进制扫描和软件成分分析工具经常可以检测到二进制包中含有的开源组件和未知文件，不需要源代码的情况下，发现与这些组件相关的安全弱点。工具可以对检测到的漏洞进行评估并打分。高度建议这些活动以验证第三方软件的完整性。输出可以和SBOM对比，或和第三方提供的源代码对比，验证SBOM。
开发团队扫描第三方软件二进制软件，识别潜在的威胁，包括未知组件、开源软件组件和漏洞。组织的决策应考虑成分分析的结果，选择和集成软件组件。请参第2.3.2节“选择和集成”，2.3.3节“从知名和信任的供应商获取组件”，寻找更多的信息。

2.3.2 选择和集成

集成第三方组件之前，必须评估每个组件潜在的安全风险。评估包括审查和测试软件。

建议缓解措施

确定风险是否可以接受之前，必须执行SAST/DAST和其他适当审查，如成分分析。一旦确定，源代码(不仅仅是二进制文件)应该集成到构建环境中，允许执行组织批准的构建环境安全扫描。只要可能，应该是从源代码构建镜像，而不是从网上下载，除非有可信提供源。

2.3.3 从知名和信任的供应商获取组件

在考虑选择第三方组件时，应该小心地同熟悉和信任的供应商建立关系，该供应商在安全编码实践方面以及组件的质量交付方面有良好的记录。

建议缓解措施

当组织对其产品作出选择、使用、改变或更新第三方或开源软件时，应进行风险评估，并确保剩余风险可以接受。组织应该核实第三方的所有权和控制状态，他们的数据通用编号系统(DUNS)，以及供应商及其上游供应商(如有此类信息) 过去的表现。根据需要，选择也要考虑到生产商的原产国，并遵守国防联邦采购条例补充(DFARS)。

供应商生产的制品，应该证明制品的开发过程、质量和安全方面的都被考虑，才能包含在组织的软件产品中。制品的可用性并不排除第2.3.2节“选择和集成”中列出的过程。此外，组织将编制已知的可信供应商名单及其已经集成到公司产品中的关联制品，以及审核第三方组件的存储库。构成产品的所有组件记录输出到SBOM中，以隐式地帮助产品的验证和审查。可信任供应商的衡量标准是：

第三方组件满足考虑采用的产品的所有要求。
软件采用组织根据检测结果验证第三方部件的质量。
所提供制品的质量，例如SBOM的验证，被验证为是正确的。
组件的所有者报告对第三方组件内已知漏洞及时响应的历史记录。
第三方漏洞上报机制使用方便。采用的组件所有可用更新易于很好地集成到开发环境中，第三方和开发小组之间，使用良好定义和容易理解的更新流程。

2.3.4 组件维护

一旦选择了第三方组件并将其集成到产品中，就必须格外小心监督供应商对组件的修改，特别是开发团队和该组件的客户社区已经报告的漏洞和已知的CVE。变更流程与在第2.3.2节“选择和集成”中说明的一致。

建议缓解措施

采用产品的组织应监测现有的CVE报告机制和第三方支持渠道确定在采用的第三方组件内发现的漏洞是否被认定可以影响产品，并采取适当的行动来解决或减轻脆弱性。与第三方的合同应解决未来的漏洞。第三方组件的所有者还必须通知产品组织存在漏洞、与之相关的风险以及解决漏洞的时间点也要都提供给产品组织。

2.3.5 软件物料清单(SBOM)

集成的第三方组件的详细信息应在产品的SBOM中说明，方便验证已批准的组件并出现问题时，识别有漏洞的组件。有几个规范定义了SBOM的格式：

Linux基金会项目的“软件包数据交换(SPDX)。”
OWASP “CycloneDX。”
NIST“软件识别(SWID)标签。”

建议缓解措施

由供应商或第三方组件所有者提供的SBOM应经过验证，根据需要更新。任何不符之处都应向供应商报告。为此，软件成分分析(SCA)工具应该应用于第三方交付的软件。第三方的SBOM可以与SCA工具生成的SBOM进行比较。如在2.5节“交付代码” 中说明的，二进制扫描SCA工具可以识别来自第三方软件最终交付的内容。

如果供应商无法提供SBOM，开发团队将获取所需的信息来描述SBOM中的第三方组件，例如，利用软件成分分析工具。当第三方源代码被开发人员修改时，初始SBOM，如果由供应商提供，以及更新后的SBOM，描述改进或解决初始源代码中缺陷，可以在SBOM的依赖关系元素项中定义。

请参考NTIA的《软件物料清单(SBOM)的最小元素》第5节(推荐数据字段)。

2.4 加固构建环境

本文档概述了两种类型的构建环境，单个开发人员环境以及生产构建环境。这两种环境的示例如图4所示。有关单个开发人员环境的更多信息，请参阅2.2.3节“安全开发实践”。

图4：安全构建环境

生产构建环境是构建可重复交付的环境。组成产品的组件被打包提供给最终用户，可能含有多个模块及加密签名。加密签名验证软件没有被篡改，由软件供应商授权。构建过程可能包括验证软件安全性的自动化任务。软件由客户安装，经过一些验证后，投入生产。构建环境可能产生软件，然后部署为软件即服务(SaaS)。这些应用程序通过网络提供了一些功能。产生的软件通常不会分发给客户进行安装。其他可考虑的常见构建环境包括：

持续集成/持续部署。在这种情况下，软件安装在云中，进行即时反馈和A/B测试，
构建软件作为快速迭代循环的一部分，例如使用敏捷开发方法。生成的软件可以分发给客户，也可以用于测试，并不分发，
构建软件为开源项目的一部分，其中可执行文件没有作为项目的一个输出来分发。在这种情况下，由构建产生的软件旨在作为测试的基线，并在开发周期的早期识别问题。

所有场景都常见的是与架构、实施和维护或者优化构建过程相关的任务。同样常见的还有提供和配置设备，如安装服务器或虚拟机、组网、配置用户权限等。

构建系统必须维持和源代码及最终产品本身相同级别的安全性、完整性和投入，如2.1节“建议缓解措施” 所述。

构建环境可以安装在本地系统中，也可以托管在云中。应该使用和加固本地构建环境同样严格的规则用于基于云构建环境。

注意：在云环境和本地环境中构建软件并比较结果非常有利。如果结果不一致，就可能存在供应链篡改的证据。

2.4.1 构建链漏洞

构建环境是供应链攻击的主要目标。在这种情况下，当威胁行为人有下列行为时，也许发生了入侵事件：

渗透开发网络。
执行扫描以定位代码库和构建系统，并识别漏洞。
设计一个漏洞来破坏构建系统或代码库(或两者都有)。
部署攻击。

在这种情况下，漏洞利用随后被包括在：

编译后的源代码，
包含库，
当库恢复到有漏洞的旧第三方库时重新引入，
常驻内存，它在编译时通过rootkit嵌入到源代码中-源代码在代码库中没有被修改，
网络中间人(MITM)攻击，它在被拉取时修改源代码来构建系统。

建议缓解措施

构建管道基础设施包括与开发和构建过程接触的所有系统，比如源代码库、工程工作站、构建系统、用于内部机器和托管在云签名服务器和部署服务器。每一个系统都应该是：

完全锁定，
免受外部和非局域网(LAN)活动的影响，
监控数据泄漏，特别是源代码库和工程工作站，
配置以防止渗透和泄露。

另外:

将构建脚本和配置文件置于相同的代码审查过程中，如第2.2.1节“内部人员修改或利用源代码”中所列，
对管道配置使用版本控制，
确保每个系统都要求多因素认证，
将工程网络与公司网络分离，
减少并定期审计服务账户，
记录所有对构建管道的访问，
保护与构建管道相关的任何机密凭证。

锁定系统

锁定系统时，应该只允许每个系统功能特定的操作。例如，构建系统应该只执行交付构建所需的操作。

保护系统不受外部和非局域网络活动的影响

保护系统免受进出网络潜在的有害网络活动的影响，除了允许的URL和必要的服务之外的连接应该被阻止。

为了确保工程机器上的所有资源和其他知识产权得到保护，在所有工程工作站上，每个系统都应该配置为防止渗透和泄露 (例如，配置入侵检测和防御、行为阻止、基于声誉的安全、基于机器学习的保护、应用隔离和控制及漏洞保护)。

管道配置使用版本控制

管道配置应该实现版本控制。管理员应该只更新配置代码，而不是实际的系统。

在持续交付(CD)管道环境中，CD编排器应该是管理所有环境的唯一实体，例如开发和生产环境。所有的配置和环境规则都应使用版本控制，由编排器管理。这将确保任何变化，无论是恶意的还是意外，只要是削弱系统安全态势，将立即可见。

管理员应该很少需要自己调整系统，因为配置设置保存在代码中，并由管道执行。一个例外是当管理员必须修复生产中平均故障时间。在这种情况下，机密凭证管理工具可以生成一个临时的SSH (Socket Shell)密钥，在有限的时间内允许管理员访问。一旦批准后，在管道配置中应该调整管理员变更，自动管理。

还要确保管理员工具不在公共环境中，例如Kubernetes集群。使用加固指南，如Kubernetes安全-操作Kubernetes集群和安全应用及Kubernetes加固指南

支持职责分离。例如，领导或业务所有者应该是构建密钥的所有者和管理员。root帐户不应该有访问密钥的权限。

多因素身份验证

每个系统都应该使用多因素身份验证(MFA)：在可能的情况下，要用MFA验证构建管道系统。使用最佳实践来限制对构建管道的访问，如基于角色的访问控制和最小权限。有关这方面的更多信息，请参考NISTSP 800-172第3.1节，基于角色的访问控制。具体解释了如何使用双重授权执行关键或敏感的系统和组织操作。

隔离工程网络

每个系统只能通过一个和组织的公司网络完全隔离的工程网络访问。如果可能，工程网络应无法直接接入互联网。

尽量减少并定期审计服务帐户‍

应尽量减少和仔细审计运行自动化流程的非人类特权帐户，每个服务帐户登录都应该被记录。这些日志应该包括日期和时间以及登录的来源。服务账户应该遵循“最小权限”的策略。所有的服务帐户都应该定期检查，以确保它们仍然是需要的，删除不必要的帐户。根据NIST SP 800-53指南，软件功能权限在需要执行某项功能时应将其提升，完成后应将其降低。

记录对构建管道的所有访问

所有对管道系统的访问都应记录在案。至少记录用户的MFA ID身份，验证访问以及日期和时间。

保护与构建管道相关的任何机密凭证

应该实施最佳实践来保护与构建管道相关的任何机密凭证。机密凭证可以是但不限于帐户密码、API密钥和私有证书。需要更改管道中的默认用户名和密码。组织中包含机密凭证的任何文档应该配置基于角色的访问控制。此外,避免在任何代码(例如，自动化代码)中以纯文本形式放置机密凭证，避免应用程序日志中记录登录敏感数据，并定期轮换机密凭证。请参考NIST SP 800-57 rev.5第1部分，参考更多细节。

建议的缓解措施(高级)

以下缓解措施描述了高级构建最佳实践，它们补充了之前在2.4.1节“构建链漏洞利用”中描述的缓解措施，并可能提供额外保护。

封闭构建

所有可传递的构建步骤、源代码和依赖项都应该预先完全声明不可变引用，构建步骤应该在没有网络访问的情况下运行。

开发人员定义的构建脚本必须声明所有依赖项，包括源代码和其他构建步骤，使用构建服务能够理解的不可变引用格式。

构建服务：

必须在可信的控制平面中获取所有制品，
不允许可变引用，
必须验证每个制品的完整性，
在运行构建步骤时必须阻止网络访问。

如果不可变引用包含加密哈希，则服务必须验证哈希，如果验证失败，则拒绝获取。否则，服务必须通过隧道获取制品以确保传输完整性，例如传输层安全(TLS)或代码签名。

当试图运行构建步骤时阻止网络访问，“尽力而为”就足够了。这应该会阻止一个合理的团队进行非封闭构建，但它不需要阻止一个确定对手。例如，使用容器来阻止网络访问就足够了。

可重复的构建

可重复的构建提供了额外的保护和验证，以防止试图入侵构建系统。它们确保每个构建系统的二进制产品是符合要求的：即，它们来自于同一个源代码，和变量元数据，如输入文件的顺序、时间戳、区域和路径无关。可重复的构建是指重新运行相同的构建步骤，输入同样制品，生成比特位相同的输出。不能满足此要求的构建必须提供说明为什么构建不能被重现。

建立和维护一个权威的数据源和代码库，对已批准和实施的系统组件，提供一个可信的源代码和问责制，参见NIST SP800-172第3.4节定义，
使用自动化机制来检测配置错误或未经授权的系统组件；检测后，采用打补丁、重新配置或移除已识别的组件等手段进行修复，‍
使用自动发现和管理工具来维护系统组件最新的、完整的、准确的、现成的目录，
在建立网络连接之前，使用基于密码学和防重放的双向认证。根据NIST SP800-172第3.5节[任务:组织已定义的系统和系统组件]的说明进行识别和认证，
采用自动化机制来生成、保护、轮换和管理不支持多因素认证和复杂帐户管理的系统和系统组件的密码，
使用自动或手动/程序机制来禁止系统组件连接到组织系统，除非组件是已知的、经过验证的、处于正确配置状态，或在可信的配置文件中，
使用一种方法来允许对比从两个或多个不同的、隔离的、受保护和安全的环境中构建出的二进制文件，

可以用新兴框架对这些缓解措施进行建模，包括软件制品供应链级别(SLSA)项目和软件组件验证标准(SCVS)的构建要求。SLSA提供了不同的安全级别，每个级别提供要求、过程和最佳实践以增加软件信任。SCVS由开源Web应用安全项目(OWASP)制定。该标准包括6类控制要求，包括用于验证软件供应链完整性的构建环境。

构建的制品至少应该包括源代码存储库和第三方依赖项、构建脚本和构建的输出。有些产品可能会给软件购买者提供这些制品，尽管在许多情况下，供应商可能需要一个特殊的许可证或协议来获得这些制品。对于可重复的构建，制品应该对应构建的脚本输出。产品的整个支持生命周期中，供应商应保留所有制品，直到它被标记为生命期结束。

建议缓解措施

高级技术包括：

SSDF PO.3(实施支持工具链)，特别是PO.3.2和PO.3.3，因为工具链在构建过程中使用。
SSDF PO.4(软件安全检查定义标准)，特别是PO.4.2，收集构建信息，支持安全标准。
SSDF PS.1(保护所有形式的代码免受未经授权的访问)，特别是PS.1.1，生成PS.2.1中的信息，并实施PS.3.1。
SSDF PW.6(配置编译和构建流程)。
SSDF PW.8(测试可执行代码)，如果测试被设计和作为构建过程一部分运行和验证。
SSDF PW.9(将软件配置为默认的安全设置)，特别是作为架构一部分、实现和维护构建过程。
SSDF RV.1(持续识别和确认漏洞)，特别是RV.1.2，自动代码扫描可能是构建过程的一部分。

2.4.2 攻击签名服务器

作为制品分发给客户的软件交付时应该具有唯一的加密签名，验证软件制品完整性。但是，如果签名设施本身已经被破坏，那么交付的制品可能也被破坏了，而签名验证的是被损坏的制品，而不是真正的制品。

注意：作为服务而不是二进制制品交付给客户的软件通常不会与加密签名一起交付。

威胁行为者可以通过破坏代码签名服务来欺骗目标，使用签名系统对受损坏的部件或产品进行签名。他们可以利用服务器上错误配置的帐户访问控制，或使用已知的或零日漏洞来实现这一目标。

威胁行为者还可以使用自签名证书，并将其注入构建或签名过程来欺骗用户。

建议缓解措施

代码签名通常是针对软件供应链漏洞的最后一道防线。供应商和开发人员一起工作以确保签名服务器的完整性，没有遭到入侵。本系统第二部分，第2.2.1节“保护所有形式的代码不受未授权访问”，测重于供应商，将讨论高级供应商的特定关注点。开发人员使用以下程序来确保代码签名的完整性：

实现强身份验证方法，如强壮密码、证书、双因素身份验证(MFA)，以及保护签名基础设施的物理访问控制。
控制用户对签名基础设施的访问，使用最小权限，用户离开或终止后撤销凭证，用于代码提交的MFA，以及使用行为分析的持续身份验证。
在物理上隔离的网段进行代码签名。
在代码签名环境中使用入侵检测和防御系统保护所使用的代码签名资源、机器和过程。
部署和使用安全信息和事件管理(SIEM)系统。
在传输和存储时使用密码。
加固签名环境系统，允许客户部署和安装经过签名和验证的发布包及产品。
使用集中的日志服务器(只能追加、加密等)
确保签名系统符合基本安全标准。
物理和远程访问需要多方批准，并记录所有访问。
只向少数签名系统管理员授予超级用户访问权限。
实施以下间接控制：

定期进行漏洞扫描(网络和web应用程序)，
定期进行渗透测试(网络、web、无线和红队)，
对文件进行适当分类(机密、绝密等)，‍
在文件上使用水印，‍
使用数据防泄密(DLP)工具，
通过销毁方法来适当地处理物理介质，‍
通过擦除的方式妥善处理数字媒体，‍
监控/执行可执行文件、库、配置文件等的完整性检查。

2.5 交付代码

软件供应商利用分发系统向客户交付软件包。包含元数据(例如版本号)和在客户信息系统及网络内安装或更新的软件。在将软件包交付给客户之前，开发人员应该执行二进制组成分析来验证包的内容。

分发系统由成品库(存储要交付的包)和客户信息系统中的包管理器组成。这两个实体在互联网上建立了一个安全连接，传输软件包。

2.5.1 成品包验证

交付给客户的成品软件包或更新可能存问题，暴露开发人员和客户网络安全和隐私风险。例如，它可能包含机密信息(例如，硬编码凭证、个人数据)、开源代码软件许可问题和包含在文件中的组件来源未知。此外，交付物可能有不正确编译器选项或构建设置。

建议缓解措施

二进制软件组成分析工具可以调查最终可交付成果到底包含了什么，并在成品包中识别上面描述的潜在的问题。开发人员应该运行二进制扫描或组成分析工具，并确保产品交付前的完整性。该工具可以检测潜在的漏洞和威胁—包括来源不明的软件(SOUP)和无意包括在最终包中的机密凭证，并为客户生成成品包的SBOM。
组织可以比较二进制分析输出和其他构建过程产生的制品，以确保成品包只包含预期的软件组件。收到后，在部署之前，客户可以运行二进制软件组成工具来评估风险，通过验证交付代码的内容。客户可以继续使用该工具对后期部署进行持续监控漏洞。
供应商和客户运行二进制扫描或成分分析工具来验证开发人员提供的最终软件包或更新的完整性。开发者可以将SBOM包含在最终的包中。这可能取决于在开发人员和客户之间合同或安排。SBOM应该包含最终产品所有主要的(顶层)的组件，列出了它们所有的传递依赖项。根据与客户、供应商或开发人员的合同提供了进一步的细节。

2.5.2 破坏软件包和更新的潜在手段

当通过分发系统从供应商到客户，软件可能会被破坏。对手可能尝试中间人攻击或破坏成品库。结果，恶意软件或漏洞可能被引入到包中，或包含可利用漏洞的旧版本包可能交付到客户。安装受影响的软件包将给客户组织和它的系统带来风险。

建议缓解措施

包含正确元数据的包应该由算法安全的签名算法签名，然后上传到成品库。或者，包可以包括密码哈希。包管理器应该验证签名或哈希和元数据，包括版本号。如果验证失败，包管理器不应该处理包。

注意：开发人员必须非常小心地保护其用于数字签名或哈希的私钥，因为如果私钥被盗，任何人都可以冒充开发人员。丢失的私钥可以阻止未来的更新或在分发新密钥时会遇到挑战。

产品级：

产品分发包哈希/数字签名，
产品更新的哈希/数字签名，
产品升级的哈希/数字签名。

2. 组件级:

分发包中产品组件的哈希/数字签名。

注意：需要进一步研究来定义应该对包中什么类型的组件或静态文件进行签名或哈希。静态文件可以包括SBOM、配置文件和文档。为正确验证此类组件，需要明确指南或标准创建签名和哈希。

2.5.3 入侵分发系统‍‍‍

对分发系统的攻击包括入侵成品库，对成品库中的包引入恶意软件。利用包管理器漏洞来将其定向到恶意站点，并在供应商、成品库和包管理器进行中间人攻击。结果，一个被破坏的软件包可能会被交付给客户。

建议缓解措施

如果开发商采取了2.5.2节“针对软件包和更新的潜在攻击”中描述的缓解措施，则下列活动可能是可选的。开发人员应该根据信息安全管理标准或指导方针保护存储库，以确保其完整性。例如，应用持续监测来预防、检测并修复对存储库的威胁。开发人员应该落实本文档第2.5节“交付代码”中描述的开发、测试、并提供安全的包管理器等建议。

此外，开发人员或供应商应该管理与包管理器相关的漏洞，并确保客户使用其最新版本。此外，开发人员是否应确保分发系统的传输层安全配置正确，确保所传输信息的保密性、完整性和真实性，例如： NIST SP 800-52 rev.2(选择、配置和使用传输层安全(TLS)实施指南)推荐的TLS协议版本、密钥交换算法、加密、消息验证和签名。