软件供应链攻击呈三位数增长，但很少有企业机构采取措施对这些复杂攻击的风险进行评估。安全和风险管理领导者可参考本文，采用三种实践来检测和预防攻击，保护企业机构的安全。

主要发现

• 虽然软件供应链攻击频繁发生，但其安全评估尚未被纳入供应商风险管理或采购活动框架，导致企业机构易遭受攻击。

• 安全团队在应对漏洞时困难重重，尤其是在软件依赖项中包含漏洞的情况下。长期以来，软件组件并不对外披露，因此其内容往往并不透明。这使得安全团队难以确定软件是否已受到攻击的影响，需要投入大量的工作，才能识别受影响的软件并实施风险缓解措施。

• 客户很少对商业软件的潜在漏洞或恶意代码进行正式测试和评估，即使对于支持高价值或敏感流程的系统也是如此。这会留出横向移动路径，为恶意代码入侵提供了可乘之机，进而导致数据和知识产权失窃。

建议

安全和风险管理（SRM）领导者已获得了解决内部应用开发中供应链问题的专业知识，可以利用这些知识，帮助企业机构开展以下三个方面的工作：

• 将软件供应链风险纳入供应商风险管理工作，并向负责软件采购的同事阐述供应链漏洞攻击的风险。这一策略旨在消除或减少对那些应用安全实践不够完善的供应商的依赖。

• 要求供应商提供其应用安全实践情况，及其所提供软件的组成和内容信息。此举便于开展供应商风险评估，并简化漏洞响应和缓解措施。

• 对支持高价值或敏感系统的软件进行专门测试和安全评估。测试范围应覆盖传统的软件漏洞检查以及恶意代码识别。

战略规划假设

到2026年，至少60%的企业机构在采购任务关键型软件解决方案时，将要求在许可和支持协议中披露软件物料清单（SBOM），而2022年这一比例还不到5%。

导语

在截至2023年4月的12个月内，近三分之二（61%）的美国企业直接受到软件供应链攻击的影响。Gartner及其他机构的研究表明，软件供应链攻击是一个全球性的挑战，且愈发严峻。尽管如此，却少有企业机构主动识别、评估和缓解软件供应链风险。在Sonatype发布的第九份年度软件供应链状况报告中，只有7%的受访者表示已开展对供应链安全风险的审查工作。 

确保软件供应链的完整性也已成为一项监管与合规要求。2021年5月美国颁布的第14028号总统行政命令受到了极大关注。不过，这一关注盖过了其他重要行动的存在。例如，美国食品药品管理局（The United States Food and Drug Administration）发布规定，对医疗器械制造商提出了供应链相关要求。美国证券交易委员会（The United States Security and Exchange Commission）发布了一系列针对网络安全事件的规定，意在进一步提升供应链安全。

在全球层面，联合国各机构制定了网络安全要求，包括智能网联汽车的软件安全。一些国家的主管部门已经颁布或拟议了加强软件供应链安全的条例（见注1）。

全球软件供应链缺乏透明度和信任，已成为各类组织面临的一个关键问题。无论是为了防御攻击或是符合监管要求，抑或两者都考虑，SRM领导者都必须主动积极地采取行动，构建安全弹性并应对不断增长的威胁。

本文为SRM领导者提供了最佳实践指南，帮助其保护企业机构免受商业软件的供应链攻击。此类实践包括将软件供应链因素纳入供应商风险管理，要求商业软件内容透明化，以及在SBOM的基础上对软件产品进行主动评估。

分析

将软件供应链安全纳入供应商风险管理

典型的外部第三方风险管理（TPRM）评估——如SecurityScorecard、Bitsight和Black Kite——会提供一个供应商风险管理的总体框架。但是，这些评估通常不会深入审查供应商的应用或软件供应链安全措施，因此，无法对这些流程的安全或风险进行有事实根据的评估。TPRM供应商提供的信息可作为宏观洞察，为发现供应商供应链安全的根本问题提供线索。但是，这些信息不足以形成有关供应商潜在风险的完整意见。图1概述了供应商风险管理生命周期和通常考虑的因素。

管理风险的灵丹妙计是直接要求供应商提供相应安全软件开发实践的证明——或其他证据，并对证明文件进行评估。供应商越来越期待在采购过程中出现此类请求。Checkmarx的一项调研显示，42%的受访供应商对应用安全实践进行衡量并公开发布报告，而44%表示他们会应要求提供此类报告。提供相关报告应成为常规做法。

供应商无法或不愿满足有关安全软件开发实践证明或信息的请求，则是存在风险的负面信号，应会被视为资质不足。

图1：传统供应商风险管理生命周期框架

在询问供应商其安全实践时，企业机构需要借助详细列出最佳实践的新框架。最好的框架示例是美国国家标准与技术研究院（NIST）发布的Special Publication 800-218安全软件开发框架（SSDF）。SSDF是依据美国总统第14028号行政命令制定的。该框架旨在满足美国政府在采购高安全性软件方面的要求，但其列出的原则是基础性的，适用于各类组织。向美国联邦政府销售产品的供应商必须提供他们遵守SSDF的证明，相应地，其他类型的组织也可在自己的采购活动中了解这方面的信息。这种方法可以简化供应商提供证明的流程。

SSDF提供了四类强烈建议实施的安全实践（见图2）。供应商应能够并愿意证明他们遵循了相关实践，具体包括：

• 组织准备：确保人员、流程和技术已准备就绪，以安全的方式开发软件。具体工作包括定义安全要求、明确相应的角色和职责以及实施支持工具链等。

• 保护软件：供应链攻击一再表明，软件工件构成了攻击面，可能会被注入恶意代码。建议实践包括采取措施防止未经授权的访问和篡改，以及验证发布的完整性。

• 生产安全可靠的软件：这是所有应用安全计划的初衷，包括设计安全的软件、执行自动代码审查和手动代码审查、在可行的情况下重复使用现有安全性能良好的软件，以及遵循安全编码实践。

• 应对漏洞：漏洞的产生是不可避免的，因此，识别并确认漏洞、确定漏洞优先级并予以修复等实践至关重要。

图2：NIST安全软件开发框架

每个实践都有相应的具体任务指导，并提供了工具和流程等实施示例。

SSDF是一个健全的标准，软件购买者可以使用该标准评估供应商的实践，即使对于美国以外的非政府组织和实体也是如此。话虽如此，各组织仍应遵从当地或行业特定的要求（如果有的话）。

供应商无法提供遵循安全开发实践（如SSDF）的证明，是一个重要的风险指标（见注2）。但是，在某些情况下，供应商可能无法保证完全遵循NIST框架。尽管如此，取消供应商的资格是不切实际或不可能的。在这种情况下，买方可以考虑其他方法来评估供应商安全地创建和交付软件的能力，例如：

• 开发者软件验证最低标准指南（NIST内部报告8937号）：NIST在SSDF发布前发布了此指南，但其全面性要低很多。不过，这些标准对于风险较低的软件是可以接受的，抑或作为供应商在努力实现完整采用SSDF时的临时措施。

• 行业联盟和更广泛的安全界所制定的框架和准则：相关框架和准则很多，也呈现出不同的成熟度。三个知名框架都侧重于开发环境和工件的完整性和保护：

o    软件工件供应链等级（SLSA）：这是一个标准和控制清单，用于确保工件完整性和更具弹性的构建系统，重点是保护软件开发流程和相关工件（例如代码和配置文件）的安全。

o    软件供应链安全最佳实践报告：由云原生计算基金会（CNCF）发布，该报告提供了信息资料和最佳实践建议，以确保全面的软件供应链安全。

o    供应链完整性、透明度和信任倡议（SCITT）：由Internet工程任务组（IETF）牵头，基于微软早期关于供应链完整性模型的工作，SCITT侧重于软件环境中的供应链安全和信任，以及数字供应链。

与此相关的其他标准和认证包括：

• ISO 27034-1：这份国际标准为跨各种用例的应用安全指定、设计、选择和实施安全控制和流程提供了指导。例如内部开发、商业许可软件和外包开发。该标准已经存在了十多年，但尚未被广泛采用。其更多地适用于应用安全计划而不是供应链。然而，供应商持有相关认证可以有力证明对应用安全问题的关注。

• 外部审计和认证：这些框架特别适用于软件即服务（SaaS）产品，相关产品的开发框架标准和SBOM标准仍处于制定阶段。此类框架包括系统和组织控制（SOC）以及ISO 27001。

要求商业软件内容透明

众所周知，现代应用开发越来越依赖于开源库，有时还依赖于商业许可的第三方库。重复使用现有的开源库可显著提高生产效率，并提高功能应用开发的速度。不过，这么做必然会带来各种运营和供应链风险，必须加以管理。

因此，为了按照企业机构的供应链和运营风险标准正确评估和审查软件内容，商业软件内容透明化至关重要。由此获取的数据也有助于快速评估具有高影响力且普遍存在的漏洞对系统用户的影响。了解开源商业库和专有组件形式的软件内容对于实现以下评估是必要的：

• 代码中存在已知但未修复或未缓解的漏洞。

• 与应用的最终用户可能继承的依赖项相关的许可条款和条件过于严苛或不利，或带来潜在法律风险。

• 运营和供应链风险：通常包括许可软件中存在大量技术债务（例如，易受攻击的组件、过期或废弃代码）或软件缺少适当的安全控制和检查等因素。不完善的维护和安全卫生实践意味着，在未来某个时刻，漏洞利用、项目废弃等风险将会增加。

在许多企业机构中，由于软件内容不够透明，这些问题仍然不为人所知，因此没有施以管理。这种缺乏透明度的情况不可避免地会给安全团队带来困扰，他们需要投入巨额财务和运营成本，以明确新披露漏洞的潜在影响。最著名的例子是Apache Log4J日志记录库发现的漏洞。该实用程序广泛用于内部开发，并包含在多个商业软件包中。由于该软件所使用的组件缺乏透明度，事件响应团队需要花费大量时间与供应商合作，识别可能易受攻击的代码，并最终修复漏洞。

SBOM可提供必要的透明度，有效地应对和避免此类问题。像其他物料清单一样，最基本的SBOM列出了创建软件时使用的各个组件——开源组件、商业组件和（在某些情况下）专有组件。尽管SBOM被纳入开发工作已近十年时间，但直到美国总统第14028号行政命令发布，才首次受到广泛的关注。

供应商无法或不愿提供SBOM，应被视为重大风险，可能会被视为资质不足。

可以将SBOM视作一个容器，用于存储（第一方、第二方和第三方）应用内代码的信息和潜在元数据。以明确的方式创建SBOM，采用机器可读格式，便于各方之间的数据传输，并支持对各方内容的自动审查和分析。

创建SBOM有两种主要格式：软件包数据交换（SPDX）和开放式Web应用安全项目（OWASP）的CycloneDX：

• SPDX是由Linux基金会赞助的项目，并编入 ISO/IEC 5962国际标准。SPDX可以传递SBOM信息，包括溯源、许可证、安全及项目维护人员需要的其他相关信息。

• CycloneDX是OWASP基金会主持的一个项目，专注于安全方面的SBOM。

虽然这两种格式通常支持不同的用例，但两种格式之间存在重叠。SPDX负责传递组件信息和相关数据，而CycloneDX则专注于安全和漏洞任务。虽然用户可能会倾向于其中某一种格式，但软件供应链安全管理的流程和工具应该能够同时支持这两种标准。

与应用安全流程证明类似，供应商无法或不愿提供SBOM应被视为重大风险，可能会被视为资质不足。

SBOM获取流程会因供应商不同而存在很大差异。一些供应商认为SBOM中包含的信息属于专有知识产权，会对用户获取SBOM实施管控，仅分发给软件产品的许可用户。在这些情况下，工件本身也将受到供应商许可证条款的约束——例如，将SBOM内的信息作为专有信息和机密信息对待。与此相反，部分供应商可能会对这些文件采取比较随意的做法，对它们的使用很少或没有限制。

软件的格式会影响供应商提供SBOM的能力。为安装在本地或虚拟或云环境中的打包应用生成SBOM相对简单。用户应能够顺利接收SBOM。实施混合硬件物料清单（HBOM）和SBOM是一项成熟的实践，可能会将固件中的SBOM元素进行合并。鉴于SBOM覆盖范围仍存在诸多疑问，基于SaaS的应用的SBOM仍在不断演变。例如，CycloneDX支持创建 SaaSBOM，不过，买方应预料到SBOM所提供信息的详细程度可能会存在很大差异。

与获取一样，SBOM的传输是供应商处理方式存在巨大差异的另一领域，用户应对此有所预期。较为正式的做法是制定明确流程，涵盖SBOM获取请求、以及严格的身份验证和访问控制。明确来源的技术，如数字签名，也将成为SBOM分发的一个要素。这些举措旨在确认文档的现行性和完整性。但是，在某些情况下， SRM领导者应该能够简单地下载文件备份。在软件许可之前和之后，用户可能需要协商接收SBOM（及每次更新）的方法。

要充分发挥SBOM的内在价值，就需要关注支持流程，实现对内容的评价和评估。这是成熟度存在巨大差异的另一领域。某些行业领域已出现了SBOM使用和管理的成熟方法。采用此类方法的通常是监管规定推动SBOM采用的行业（如医疗器械或汽车制造）。

两个主要用例包括：

• 应对具有高影响力且普遍存在的已知漏洞。

• 主动评估各组件，以识别潜在的供应链风险。

应对具有高影响力且普遍存在的已知漏洞

这方面常举的例子是Apache Log4J事件（涉及多个代码版本中至少六个不同的常见漏洞和暴露[CVE]）。原因在于这些漏洞的严重性，以及为修复相关风险而花费的大量成本和精力。大多数企业机构的SRM领导者有理由认为企业的专有代码和其他软件存在缺陷。然而，他们无法迅速确定哪些特定软件可能包含违规代码，如果确实包含，却也无法确定其是否会被利用。于是，无数时间用于检查代码、与供应商沟通以及评估由此带来的风险。

在某些情况下，供应商本身无法确定其产品是否已受到影响。而随时可用的SBOM则可能节省不可估量的工时。添加漏洞可利用性交换（VEX）文件可进一步提升漏洞响应工作（见注3）。软件购买者可以根据需要不时查看现行SBOM，以识别新的漏洞。他们还可以借助工具，自动突出显示最新发现的漏洞。

主动评估各组件，以识别潜在的供应链风险

同样有前景但很少采取的实践，是在使用或部署前，主动检查和评估软件组件及其依赖项。此用例既涉及供应源开发、采购和供应商管理团队（针对商业软件），也涉及应用安全和软件开发团队。

使用SBOM主动评估商业软件

在应用安全和软件工程团队中，使用软件成分分析工具和SBOM已成为识别软件开发中所用依赖项相关风险的常见做法。Gartner的2022-2024年技术采用路线图表明，约一半的受访者已使用软件成分分析（SCA）工具，另有30%的受访者预计将在2023年采用这些工具。9 大多数情况下，工具启用在很大程度上是被动响应式的，也就是说，是在开发人员为应用程序添加了开源依赖项后才开始启用的。虽然这是开发团队公认的做法，但需要采取更积极主动的办法——开发和采购用例同样适用。SBOM的可用性为开发和安全团队提供了基础，可以在甄选阶段确定风险较大或不可接受的代码。

将SBOM用于评估商业软件风险远不如用于内部开发那样成熟。例如，采购和供应商风险管理团队可能尚未获得所购软件的SBOM，或尚不熟悉SBOM。其次，一个更为根本的问题是，虽然SBOM列明了各个组件，但是，由于缺乏必要的工具和信息，这些团队通常无法评估与单个组件相关的安全和运营风险。

简言之，难度在于读懂SBOM这份“成分”列表，即软件中包含的各种组件。买方在评估与这些组件相关的风险时，需要一些通常不包含在SBOM中的信息，因此需要外部的信息补充。SBOM缺少以下信息：

• 项目维护方的声誉

• 维护团队的规模

• 维护团队的安全实践

• 参与者的数量和身份

• 可帮助买方评估风险的其他信息

为了评估SBOM所显示的软件内容，需要有关单个项目的元数据。此类元数据有多个来源，包括专有数据库。这些数据库在为开发和安全团队设计的工具中最为常见，市面上也出现了一些支持采购流程的工具。

也有一些面向开源项目的工具，如OSSF计分卡（见图3）。该计分卡数据库有效展示了评估SBOM如何发现开源风险。该数据库包含关于开源项目的元数据，包括（截至2023年10月）大约19个不同属性，如维护人员数量、更新频率和对以前漏洞的响应，以及安全测试和审查实践。

企业机构应制定适用于潜在软件采购的策略，并从数据库（如计分卡）中提取信息，以确定给定组件是否可接受。例如，恶意行为者有时会试图控制被弃或暂停的项目，并将其用作向项目的下游用户分发恶意软件的途径。如果策略标记代码在较长时间内鲜有提交记录或未曾发布更新，则预示该软件包可能在不久的将来被弃用。用户可能希望选择更新跟踪记录良好的软件包。

图3：OSSF计分卡安全属性

采购团队倾向于采用截然不同的另一套工具以支持其角色，但SRM领导者可以帮助采购人员了解潜在风险以及如何最好地管理工具。在更强大的工具上市之前，SRM领导者还可以使用应用安全和开发团队可能已拥有的软件成分分析和软件供应链安全工具，通过提供风险评估的服务来支持采购团队。

谨慎实施商业软件的测试和安全评估

提高软件供应商安全实践的可见性和软件内容的透明度，将大大增强企业机构管理软件供应链风险的能力。但在某些情况下，这些活动可能不足以全面评估某一特定软件组件或供应商构成的风险。对于处理极其敏感的数据或支持关键功能的系统，鉴于其所暴露的攻击面可能导致其他类型的高风险，则应考虑进行更积极的安全评估。这同样适用于被认为构成高风险、但企业机构必须与其合作的供应商。

由于需要各种类型的专业知识，最好建立一支由利益相关者组成的跨职能团队——特别是此类评估预计将成为一项例行长期任务的情况下。此类团队的成员通常来自以下几个方向：

• 正式供应商或整体风险管理职能

• 法律顾问

• 采购

• 业务线经理（依其业务受相关软件的影响程度而定）

软件测试支持的特定用例包括：

• 创建或确认SBOM。

• 识别恶意软件或恶意代码。

创建或确认SBOM

在某些情况下，供应商可能不提供软件的SBOM。不能或不愿提供SBOM应视为明显的风险警告。但是，也会存在企业机构仍需要与此类供应商进行业务往来的情况。例如，软件已在使用中，而企业机构高度依赖此软件，或者只有少数或没有可替代的供应商。也可能是企业机构希望验证供应商提供的SBOM。在这些情况下，企业机构都可能需要自行创建SBOM。许多工具可以反编译和分析二进制可执行文件（甚至可支持源代码分析，如果可获得源代码的话），生成SBOM，进而分析安全和运营风险，或者核实供应商所提供的SBOM文件。

识别恶意软件或恶意代码

攻击者越来越多地利用软件（开源软件和商业软件）作为攻击向量。被弃或维护不善的开源项目可能会被接管，攻击者也可能获得对商业软件供应商构建和部署过程的控制权。攻击者通过上述访问嵌入恶意代码，这些代码随后被最终用户使用，并通过供应链蔓延开来（见注4）。由于许多更新过程是自动完成、受到的监督水平非常低，而且许多攻击者似乎技能水平很高，迄今为止，这些攻击取得了相当大的成功。少数供应商可以支持自动分析代码以检测恶意软件，例如ReversingLabs或Grammatech。可以考虑将这些工具与其他更传统的测试形式（如渗透测试或模糊测试）结合使用。传统的应用安全测试工具通常不会尝试检测恶意代码。

在对外部代码进行任何分析或测试之前，SRM领导者必须咨询下法律顾问，以确认拥有执行测试的权利，以及需要遵守的各种限制。软件许可协议通常包含各种对测试、反编译和分析的限制，这是软件使用许可证的一部分。与此同时，各国政府颁布了法律，旨在平衡合法安全研究人员的需求和软件所有者的知识产权需求。鉴于各类许可协议和适用法律的差异，法律顾问的建议和指导对于确保企业机构在其权利范围内进行测试至关重要。

注1：全球供应链和软件物料清单法规和指南

世界各地都已实施了软件供应链——更具体地说，是软件物料清单（SBOM）——相关的监管行动和各种正式建议。此类行动的代表列举如下：

• 欧盟于2022年9月首次提出《网络弹性法案》（Cyber Resilience Act），该法案涵盖了一系列旨在提高网络安全、保护消费者和企业免受安全事件影响的措施。许多措施专门针对数字供应链安全问题，例如要求提供SBOM。该法案仍处于讨论和辩论阶段，其关注重点在于对开源软件生态系统的潜在影响。

• 日本于2022年5月通过了《经济安全保障推进法案》（ESPA）。该法案涵盖了各种保护关键基础设施安全的规定，包括某些类型的软件。日本经济产业省（METI）发布了《软件管理引入软件物料清单指南》，为实施和采用SBOM提供了指导。

• 2023年9月，澳大利亚信号局（Australian Signals Directorate）发布了《软件开发指南》，出台了安全软件开发各个方面的多项规定。该指南提出的30余条建议中包括一项控制措施，要求创建并向软件消费者分发SBOM。

• 2022年10月，英国政府通信总部（GCHQ）下属的国家网络安全中心（NCSC）向各组织发布了指南，以应对持续发生的供应链事件。该指南侧重于帮助各组织实施NCSC的供应链安全原则，包括针对软件供应链安全的各种具体措施。

• 2023年8月，德国联邦信息安全办公室（BSI）发布了创建SBOM的要求，旨在提高消费者更好地理解和管理所使用软件潜在风险的能力。

 

注2：安全软件开发证明

由于目前没有正式的标准可供供应商寻求外部验证和认证，软件购买者必须依靠供应商提供的自我证明。企业机构可以借鉴美国政府的 安全软件开发证明表单说明（Secure Software Development Attestation Form Instructions）。

注3：漏洞可利用性交换

漏洞可利用性交换（VEX）是提供有关特定产品中特定漏洞状态信息的文档。文档涵盖了产品信息、漏洞信息和与特定产品相关的状态详细信息。VEX文档至少应包含产品状态信息，因其与特定漏洞相关。VEX信息可包含在软件包数据交换（SPDX）或CycloneDX SBOM文档中。不过，该文档仅适用于当下，随着更多的漏洞被披露、修复和调查，其将逐渐过时。

注4：软件供应链攻击示例

• 始于2019年9月（但直到2020年末才被报道）的SolarWinds攻击仍是最知名的软件攻击事件之一。人们普遍认为，攻击者的背后是某个民族国家。攻击者获得访问权限后，并对SolarWinds系统进行了一些修改。这些修改暗地里在代码中植入了一个后门，得以访问SolarWinds客户运营的数千个网络。

• 2021年7月的Kaseya攻击与SolarWinds类似。在这个案例中，攻击者通过伪装的产品自动更新向Kaseya客户分发恶意软件。攻击有效载荷是勒索软件，受害者数量不详。

• Codecov作为一种工具，可以帮助企业机构了解其应用代码的测试覆盖率，也曾遭到类似上述示例的攻击。公司分发给客户的软件包中的部分内容遭到破坏，被安插了分发后门，以致于各种敏感信息被检索和窃取。多达29,000名客户受到影响。

• 最近，互联网协议语音（VoIP）通信软件制造商3CX的开发环境遭到攻击。该攻击分发恶意代码，能够远程访问3CX客户端。与SolarWinds一样，人们也认为攻击者背后是某个民族国家。此次针对3CX的攻击是首个已知的多层级软件供应链攻击。此前3CX遭遇过另一武器化软件分发的攻击。