Gartner发布降低软件供应链安全风险指南

软件供应链攻击已呈三位数增长，但很少有组织采取措施评估这些复杂攻击的风险。这项研究提供了安全和风险管理领导者可以用来检测和预防攻击并保护其组织的三种实践。

主要发现

尽管软件供应链攻击急剧增加，但安全评估并未作为供应商风险管理或采购活动的一部分进行。这使得组织容易受到攻击。
安全团队很难应对漏洞，尤其是当该漏洞包含在软件依赖项中时。由于软件组件传统上并未公开，因此对于试图确定它们是否受到影响的团队来说，它们的内容通常是不透明的。这需要非凡的工作来识别受影响的软件并实施风险缓解措施。
客户很少对商业软件的潜在漏洞或恶意代码进行正式测试和评估------即使对于支持高价值或敏感流程的系统也是如此。缺乏正式的测试创造了横向移动的途径，并促进了窃取数据和知识产权的恶意代码的引入。

建议

安全和风险管理 (SRM) 领导者在解决内部应用程序开发中的供应链问题方面获得了专业知识。他们可以通过帮助其组织进行以下三种实践来利用这些知识：

将软件供应链风险添加到供应商风险管理中，并对担任软件采购角色的同事进行有关这些攻击的风险的教育。该策略旨在取消或减少对应用程序安全实践不足的供应商的依赖。
要求供应商的应用程序安全实践以及这些供应商的软件的组成和内容具有透明度。这样做有助于供应商风险评估并简化对漏洞的响应和缓解。
对支持高价值或敏感系统的软件实施专门的测试和安全评估。测试范围应涵盖传统的软件漏洞检查和恶意代码识别。

战略规划假设

到 2026 年，至少 60% 采购关键任务软件解决方案的组织将要求在其许可和支持协议中披露软件物料清单 (SBOM) ，而 2022 年这一比例还不到 5% 。

介绍

在截至 2023 年 4 月的 12 个月内，近三分之二 (61%) 的美国企业直接受到软件供应链攻击的影响。Gartner 和其他研究表明，软件供应链攻击是一项持续急剧增长的全球挑战。尽管如此，主动识别、评估和减轻软件供应链风险的努力相对较少。在 Sonatype 第九次年度软件供应链状况报告中，只有 7% 的受访者努力审查其供应链中的安全风险。

确保软件供应链的完整性也已成为监管和合规要求。2021 年 5 月发布的美国第 14028 号行政命令受到了相当多的关注。然而，对该命令的关注掩盖了其他重要行动。美国食品和药物管理局已颁布法规，对医疗器械制造商提出供应链要求。美国安全交易委员会发布了一系列针对网络安全事件的规则，有望进一步提高供应链安全。

从全球角度来看，联合国机构制定了网络安全要求，包括联网车辆的软件安全。多个国家/地区的主管部门已发布或提议加强软件供应链安全的法规。

全球软件供应链缺乏透明度和信任已成为各类组织面临的一个关键问题。无论是出于防止攻击的愿望还是出于监管要求（或两者兼而有之），安全和风险管理 (SRM) 领导者都必须积极主动地采取行动，以建立弹性并应对日益增长的威胁。

这项研究为 SRM 领导者提供了有关实践的指导，有助于保护其组织免受商业软件中的软件供应链攻击。它包括在供应商风险管理的讨论中添加软件供应链考虑因素，要求商业软件内容的透明度以及使用软件物料清单（SBOM）作为主动评估软件产品的基础。

分析

将软件供应链安全添加到供应商风险管理中

典型的外部第三方风险管理 (TPRM) 评估（例如安全记分卡、Bitsight 和 Black Kite）支持供应商风险管理的总体框架。然而，这些评估通常不会对供应商的应用程序或软件供应链安全措施进行深入审查。因此，他们无法支持对这些流程的安全性或风险进行明智的评估。TPRM 供应商提供的信息可以提供高级见解，这些见解可能表明供应商供应链安全的潜在问题。然而，他们没有提供足够的信息来形成对供应商可能造成的风险的完整意见。图 1概述了供应商风险管理生命周期和通常考虑的因素。

管理风险的一种更好的方法是直接请求和评估适当的安全软件开发实践的证明（或其他证据）。供应商越来越期望在采购过程中出现此类问题。Checkmarx 的一项调查显示，42% 的受访供应商衡量应用程序安全性并公开发布报告，而 44% 的供应商表示他们根据要求提供此类报告。此类做法应成为常规做法。

供应商无法或不愿意满足有关安全软件开发实践的证明或信息的请求是一个不利的风险信号，应被取消资格。

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

当向供应商询问他们的实践时，组织应该依赖详细介绍最佳实践的新兴框架。最好的例子是安全软件开发框架 (SSDF)，由美国国家标准与技术研究所 (NIST) 作为特别出版物800-218编写。SSDF 是根据美国总统行政命令 14028 制定的。虽然该框架旨在满足美国政府采购更安全软件的要求，但概述的原则是基本原则，适用于广泛的组织。由于向美国联邦政府销售的供应商需要提供遵守 SSDF 的证明，因此其他类型的组织也可以在自己的采购活动中利用这些努力。这种方法可以简化供应商提供证明的过程。

SSDF 包含四组高级推荐实践（见图 2）。供应商应该能够并且愿意证明他们遵守这些做法，其中包括：

**组织准备：**确保人员、流程和技术准备好以安全的方式开发软件。示例包括定义安全要求、建立适当的角色和职责以及实施支持工具链。
**保护软件：**供应链攻击已多次证明，软件工件代表了可以引入恶意代码的攻击面。建议的做法包括防止未经授权的访问和篡改以及验证发布完整性的措施。
**生产安全良好的软件：**这是应用程序安全计划的常见起点，包括安全软件设计、自动和手动代码审查、现有安全良好软件的重用（如果可行）以及安全编码实践。
**应对漏洞：**由于漏洞的产生是不可避免的，因此识别和确认漏洞的存在以及确定漏洞的优先级和进行修复等实践至关重要。

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

在每个实践中，都提供了支持实践的特定任务的指导，以及实施示例，例如工具和流程。

SSDF 是一个健全的标准，软件购买者可以使用它来评估供应商的做法，甚至对于美国以外的非政府组织和实体也是如此。也就是说，组织应该遵守当地或特定行业的规定（如果存在）。

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

软件开发人员验证最低标准指南 (NIST IR 8937) **：**NIST 在 SSDF 发布之前发布了此指南，但其综合性相当低。然而，这些标准对于低风险软件来说可能是可接受的，或者在供应商努力实现对完整 SSDF 的支持时作为临时措施。
**由行业联盟和更广泛的安全社区建立的框架和指南：**无数的努力显示出不同程度的成熟度。三个著名的例子都倾向于关注开发环境和工件的完整性和保护，它们是：

o 软件工件的供应链级别(SLSA)：确保工件完整性和更具弹性的构建系统的标准和控制。重点是保护软件开发过程和相关工件（例如代码和配置文件）。

o 软件供应链安全最佳实践论文：该论文由云原生计算基金会 (CNCF) 制作，提供了信息材料和推荐的最佳实践的组合，以确保软件供应链安全的各个方面。

o 供应链完整性、透明度和信任 (SCITT)：由互联网工程任务组 (IETF) 领导，基于 Microsoft 早期关于供应链完整性模型的工作，SCITT 重点关注软件环境中的供应链安全和信任和数字供应链。

可能与这些工作相关的其他标准和认证包括：

**ISO 27034-1：**一项国际标准，为跨各种用例的应用程序安全指定、设计、选择和实施安全控制和流程提供指导。示例包括内部开发、商业许可软件和外包开发。该标准已存在十多年，但尚未得到广泛采用。它更普遍地适用于应用程序安全计划而不是供应链。然而，供应商持有的认证将是关注应用程序安全问题的有力证据。
**外部审核和认证：**这些框架与 SaaS 产品特别相关，其中开发框架和 SBOM 的标准仍在制定中。示例包括系统和组织控制 (SOC) 以及 ISO 27001。

要求商业软件内容透明

众所周知，现代应用程序开发越来越依赖开源，有时还依赖商业许可的第三方库。现有开源库的重用可以显着提高生产力，并提供更快地生成功能应用程序的能力。尽管如此，这种做法本质上会引入各种运营和供应链风险，必须对其进行管理。

因此，商业软件内容的透明度对于根据供应链和运营风险的组织标准正确评估和审查软件内容至关重要。从这些评估中提取的数据还有助于快速评估高影响力、普遍存在的漏洞对系统用户的影响。了解软件的内容（以开源商业库和专有组件的形式）对于进行以下评估是必要的：

代码中存在已知但未经修复或未缓解的漏洞。
与应用程序的最终用户可能继承的依赖项相关的繁重或无吸引力的许可条款和条件导致的潜在法律风险。
运营和供应链风险。这些通常包括诸如许可软件中存在重大技术债务（例如，易受攻击的组件、过时或报废代码）或软件缺乏适当的安全控制和检查等因素。不良的维护和安全卫生实践表明，未来某个时候出现漏洞、项目放弃和其他风险的风险会增加。

在许多组织中，由于软件内容缺乏透明度，这些问题仍然未知，因此无法得到管理。这种缺乏透明度不可避免地会困扰安全团队，因为他们需要花费巨大的财务和运营成本来确定新披露的漏洞的潜在影响。最著名的例子是与 Apache Log4J 日志实用程序相关的漏洞。该实用程序广泛用于内部开发，并包含在多个商业软件包中。由于该软件中使用的组件缺乏透明度，事件响应团队需要花费大量时间与供应商合作，识别潜在的易受攻击的代码，并最终缓解漏洞。

有效解决和避免此类问题所需的透明度始于SBOM。与其他物料清单一样，SBOM 以其最基本的形式列出了在创建软件时使用的各个组件：开源组件、商业组件和（在某些情况下）专有组件。尽管 SBOM 已经发展了近十年，但它们首次引起广泛关注是由于美国总统第 14028 号行政命令。

供应商无法或不愿意提供 SBOM 应被视为重大风险并可能被取消资格。

SBOM 可以被视为一个容器，用于存储有关已包含在应用程序（第一方、第二方和第三方）中的代码的信息和潜在元数据。SBOM 以机器可读格式以定义的方式创建，以促进各方之间的数据传输，并支持对其内容的自动审查和分析。

有两种主要格式用于创建 SBOM：软件包数据交换 (SPDX) 和开放全球应用程序安全项目 (OWASP) CycloneDX：

SPDX是由 Linux 基金会赞助的项目，并已编入ISO/IEC 5962国际标准。据项目维护人员介绍，SPDX 可以传达 SBOM 信息，包括出处、许可证、安全性和其他相关信息。
CycloneDX是 OWASP 基金会的一个项目，被视为专注于安全的 SBOM。

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

与应用程序安全流程证明类似，供应商无法或不愿意提供 SBOM 应被视为重大风险并可能被取消资格。

预计不同供应商获取 SBOM 的流程会有很大差异。由于一些供应商将 SBOM 中包含的信息视为代表专有知识产权，因此用户可能会发现获取过程受到控制，并且分发仅限于软件产品的许可用户。在这些情况下，工件本身也将受到供应商许可条款的控制，例如，将 SBOM 中的信息视为专有和机密。另一方面，一些供应商可能会对文档采取相当随意的方法，对其使用很少或没有限制。

软件的格式将影响供应商提供 SBOM 的能力。为本地安装或虚拟或云环境中安装的打包应用程序生成 SBOM 相对简单。用户应该能够毫无问题地收到 SBOM。实施混合硬件物料清单 (HBOM) 和 SBOM 是一种既定做法，它可能会合并固件的 SBOM 元素。鉴于围绕此类工件范围的问题，基于 SaaS 的应用程序的 SBOM 仍在进行中。例如，CycloneDX 支持创建 SaaSBOM ，尽管买家应该预期所提供的详细程度存在很大差异。

与采购一样，SBOM 的运输或转移是另一个领域，用户应该预料到供应商处理任务的方式会有很大差异。更正式的方法将纳入请求 SBOM 的定义流程以及严格的身份验证和访问控制。建立来源的技术（例如数字签名）也将作为 SBOM 分发的一个要素出现。这些技术旨在确认文件的流通性和完整性。然而，在某些情况下，SRM 领导者应该能够简单地下载该文件的副本。用户可能需要在软件许可之前和之后协商接收 SBOM（及其各自的更新）的方法。

充分利用 SBOM 的内在价值需要关注支持对其内容进行评价和评估的流程。这是成熟度存在相当大差异的另一个领域。在某些行业领域，已经出现了使用和管理 SBOM 的稳健方法。这些群体的例子往往是监管要求推动 SBOM 采用的领域，例如医疗设备或汽车制造。

出现了两个主要用例：

应对高影响力、普遍存在的漏洞的披露。
主动评估组件以识别潜在的供应链风险。

对高影响、普遍漏洞披露的响应

Apache Log4J 事件（与跨多个代码版本的至少六种不同的常见漏洞和暴露 [ CVE ] 相关）经常被引用作为此用例的示例。这是因为漏洞的严重性以及修复这些风险所花费的大量成本和精力。在大多数组织中，SRM 领导者有理由相信他们自己的专有代码和其他软件中存在缺陷。然而，他们无法快速确定哪些特定软件可能包含违规代码，如果包含，也无法确定它是否会受到利用。这导致我们花费无数时间检查代码、与供应商沟通并评估所带来的风险。

在某些情况下，供应商本身无法确定其产品是否受到影响。SBOM 的现成可用性将节省大量的工作时间。添加漏洞利用 eXchange [VEX ] 文件可以进一步促进响应工作。软件购买者可以根据需要频繁地查看当前的 SBOM，以识别新的漏洞。他们还可以寻找能够自动突出显示新发现的漏洞的工具。

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

在使用或部署软件组件和依赖项之前主动检查和评估软件组件和依赖项的努力也很有希望，但实施得少得多。该用例涉及寻源、采购和供应商管理团队（针对商业软件）以及应用程序安全和软件开发团队。

使用 SBOM 主动评估商业软件

在应用程序安全和软件工程团队中，使用软件组合分析工具和 SBOM 已成为识别软件开发中使用的依赖项风险的常用方法。Gartner 的2022-2024 年技术采用路线图表明，大约一半的受访者已经使用软件组合分析 (SCA) 工具，另外 30% 的受访者预计将在 2023 年采用这些工具。在大多数情况下，这些努力在很大程度上是被动的，也就是说，它们在开发人员已经将开源依赖项添加到他们的应用程序之后，他们就被雇用了。虽然这是开发团队公认的做法，但无论是对于开发还是采购用例，都需要采取更主动的方法。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 的工具。可以分析这些内容的安全和操作风险，或确认供应商提供的文档。

恶意软件或恶意代码的识别

软件（开源和商业）被攻击者用作攻击媒介的现象越来越普遍。废弃或维护不善的开源项目可能会被接管，或者攻击者可能会控制商业软件供应商的构建和部署流程。通过这种访问，攻击者可以嵌入恶意代码，然后由最终用户使用并通过供应链传递。由于许多更新过程都是自动化的，并且受到最少的监督而且许多攻击者似乎拥有很高的技能，迄今为止，这些攻击已经取得了相当大的成功。能够支持自动分析代码以检测恶意软件的供应商数量有限，例如 ReversingLabs 或 Grammatech。这些工具应与其他更传统的测试形式一起考虑，例如渗透测试或模糊测试。传统的应用程序安全测试工具通常不会尝试检测恶意代码。

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