2023年11底，美国ODN、NSA CCC、CISA、CSCC等多个政府机构部门联合发布了《保障软件供应链安全：SBOM推荐实践指南》，《SBOM推荐实践指南》主要由ESF（Enduring Security Framework长久安全框架）小组编撰，该文件根据行业内对于SBOM的最佳实践和原则提供了非常具有建议性的指导意见，并且鼓励软件开发商和供应商共同参考，以维护和提升对软件供应链安全的认识。
下面是翻译的全文，请大家参考。
应
执行摘要
网络攻击是通过网络空间进行的，其目标是针对企业使用网络空间，目的是破坏、禁用、销毁或恶意控制计算环境或基础设施；或破坏数据的完整性或窃取受控信息。1
针对 SolarWinds 及其客户实施的攻击以及利用 Log4j 等漏洞的攻击，凸显了软件供应链中的弱点，该问题涉及商业软件和开源软件，并影响私营和政府企业。因此，对软件供应链安全意识和认知的需求日益增加，因为软件供应链有可能被国家对手使用类似的战术、技术和程序 (TTPs) 武器化。
作为回应，白宫发布了《关于提高国家网络安全水平的行政命令》（EO 14028），该命令为保护联邦政府的软件供应链制定了新的要求。由私营企业、学术界和政府组成的合作伙伴关系领导的《持久安全框架》（ESF）成立了软件供应链工作小组，该小组发布了由三部分组成的《推荐实践指南》系列，作为建议实践的纲要，以帮助确保为开发人员、供应商和客户利益相关者提供更安全的软件供应链。
同样，ESF软件供应链工作小组制定了第二阶段的指导方针，为第一阶段推荐实践指南中的几项活动提供了进一步的细节。该指导方针可用作描述、评估和衡量与软件生命周期相关的安全实践的基础。此外，本文所列的建议实践可应用于软件供应链的采购、部署和运营阶段。
软件供应商负责客户与软件开发人员之间的联络。因此，供应商的责任包括通过合同协议、软件发布和更新、通知以及漏洞缓解来确保软件的完整性和安全性。本指南包含建议的最佳实践和标准，以帮助客户完成这些任务。
本文档将提供符合行业最佳实践和原则的指导，鼓励软件开发人员和软件供应商参考这些原则。这些原则包括管理开源软件和软件物料清单，以维护和提供对软件安全性的认识。
免责声明
背书免责声明
本文件仅供一般参考之用。提及任何特定商业产品、工艺或服务的商品名、商标、制造商或其他内容，均不构成或暗示美国政府的认可、推荐或支持。本文件旨在适用于各种实际情况和行业利益相关者，本文提供的信息仅供咨询。本文件中的指导本文档“按原样”提供。一旦发布，其中的信息可能不构成最新的指导或技术信息。因此，本文档不构成，也不打算构成合规或法律建议。
读者应咨询各自的顾问和主题专家，以根据他们的个人情况获得建议。在任何情况下，美国政府均不对因使用或依据本指南而导致的任何损害承担责任。
目标宗旨
国家安全局、国家情报总监办公室和计算机应急响应小组为促进各自的网络安全任务，包括制定和发布网络安全建议和缓解措施的责任，而编写了本文件。本文件信息可能会广泛共享，以覆盖所有相关利益方。
联系我们
客户要求/咨询：持久安全框架nsaes@cyber.nsa.gov
媒体咨询/新闻处：
- NSA媒体关系部，443-634-0721，MediaRelations@nsa.gov
- CISA媒体关系部，703-235-2010，CISAMedia@cisa.dhs.gov
- ODNI媒体关系部，dni-media@dni.gov
1 介绍
软件供应链中未缓解的漏洞对组织构成重大风险。本文基于之前发布的软件供应链开发、生产、分销和管理过程的建议实践，以提高这些过程抵御妥协的弹性。
本指南还基于并支持管理和预算办公室（OMB）关于通过安全软件开发实践增强软件供应链安全的备忘录。
由于保护软件供应链的考虑因素各不相同，因此本后续指南侧重于软件物料清单（SBOM）消耗和开源软件（OSS）。这些信息将有助于继续促进不同角色之间以及网络安全专业人员之间的沟通，从而促进软件供应链流程中弹性和安全性的提高。
鼓励所有组织积极管理和降低风险，作为不断发展的安全软件开发实践的一部分。组织在软件供应链生命周期中作为软件开发商、供应商或客户的作用将继续决定这一责任的形状和范围。
鉴于最近备受关注的软件供应链事件，建议收购企业方在做出购买决策时进行供应链风险评估。软件开发人员和供应商应改进其软件开发流程，降低对员工和股东以及用户的危害风险。
1.1 背景
与软件缺乏透明度相关的已知安全风险已成为公共和私营部门组织的主要关注点，这在很大程度上是由于2020年和2021年代价高昂的软件供应链妥协。 SolarWinds供应链妥协涉及在政府机构和其他组织广泛使用的商业监控软件中插入恶意代码，突显了威胁行为者通过访问目标使用的软件来危害目标的方式。 发布行政命令（EO）14028是为了降低这种供应链风险。
针对软件供应链的常见妥协方法仍然包括利用软件设计缺陷、将易受攻击的第三方组件纳入软件产品、在软件产品最终交付之前用恶意代码渗透供应商的网络，以及在部署到客户环境的软件中注入恶意软件。
公共和私营部门的利益相关者应不断寻求缓解其责任范围内的安全问题。然而，其他问题可能需要一种缓解方法，该方法要求依赖另一个利益相关者或由多个利益相关者共同承担责任。
软件依赖性沟通或处理不当可能导致漏洞和潜在的妥协。软件供应链的透明度是管理该风险的必要条件。
1.2定义：
1.2.1软件产品的定义
OASIS通用安全咨询框架（CSAF）将“产品”定义为“任何可以用名称指代的可交付成果（如软件、硬件、规范）。这适用于任何来源、许可模式或可交付成果的分发模式。”产品来自供应商，适用于企业内的所有软件。
1.2.2SBOM的定义
软件物料清单（SBOM）已成为软件安全和软件供应链风险管理中的关键组成部分。SBOM是一个嵌套的清单，是组成软件组件的成分列表。自2018年以来，SBOM工作作为一个协作社区取得了进展
在国家电信和信息管理局（NTIA）多方利益相关者流程的推动下，我们付出了努力。请注意，第14028号行政命令指示商务部长在2021年就SBOM的最低要素和其他相关参数提供指导，而OMB此后表示，CISA可能会发布“后续指导”以更新这些内容。有关SBOM和相关供应链风险管理（SCRM）工件的更多信息，请参阅2022年11月发布的《保护软件供应链客户推荐实践指南》的第2节。
1.2.3SBOM格式
在本文发布时，SBOM有两种广泛使用的机器可读格式：软件包数据交换（SPDX）和CycloneDX。软件标识标签（SWID）也被确定为传递SBOM数据的潜在手段，但在固件依赖性等狭窄用例之外的使用并不多，在这些用例中，数据在硬件本身中传递。
1.2.4使用 SBOM 和风险评分
SBOM可能与其它数据和威胁源相关联，以增加所提供内容的价值和范围。组织将使用大量SBOM，这些SBOM可能无法在当前技术工具和服务的一些用例中扩展。风险评分的应用可用于基于SBOM内容创建高级抽象，该内容可以快速与外部数据源，并根据收到的 SBOM 和优先级采取及时行动。风险评分方法可能有助于成功使用 SBOM，以简化原始 SBOM 数据，以便快速进行自动/手动分析/利用 SBOM。SBOM 信息，加上来自其他来源的信息，将使数据与第 4 节中概述的四个类别的风险评分相关联。
1.2.5漏洞可利用性交换的定义
与SBOM相关的概念是漏洞利用交换（VEX）。VEX文档是一种断言，一种安全咨询形式，表明一个或多个产品是否受到已知漏洞的影响。因此，它提供了表明产品不受特定漏洞影响的新颖好处。
1.3文件概述
本文件包含以下附加章节和附录：
第2节：软件物料清单消耗
第3节：企业中的SBOM生命周期
第4节：SBOM风险评分
第5节：实施SBOM
附录A：参考文献
附录B：缩略语列表
附录C：术语表
2 软件物料清单消耗
这项后续工作侧重于各种客户组织所收到的软件物料清单（SBOM）的消耗，并为客户使用SBOM提供指导。SBOM传达了软件中包含的信息。仅仅知道供应商可以提供高质量的SBOM，就可以为软件用户带来好处，因为它提供了一定程度的信心，即软件供应商更有可能能够应对供应链问题。然而，充分利用SBOM需要将SBOM数据转化为安全情报的能力，然后可以推动安全行动。
从安全角度来看，SBOM很有价值，因为它们可以确保软件保持最新状态，并针对已知的安全漏洞进行修补。根据Synopsys 2022年开源安全和风险分析报告，他们在2021年审计的代码库中有97%包含开源软件。该报告的主要发现包括：
- 虽然使用开源软件本身可能会纳入风险计算，但81%的代码库至少有一个已知的开源漏洞。
- 85%的被审计代码库包含的开源软件在4年多时间里没有得到软件开发人员的更新。这通常表明该软件没有得到积极维护，可能存在未修补的漏洞。
- SBOM 的安全性和合规性优势一直很重要。然而，由于以下三个主要原因，SBOM 在今天变得尤为重要：
- 根据 Linux 基金会的数据，开源软件的普及率目前为 72%，其中 15% 的公司内部使用开源软件或将其作为商业产品的一部分。
- SBOMs帮助企业确保他们对（开源）软件的使用符合
业务的风险偏好。
-
- SBOMs，加上其他来源的信息，一旦在软件包或软件列出的组件中识别出漏洞，就可以通过通知组织并允许更快地采取缓解控制和措施来降低风险，从而帮助减少暴露窗口。
- 未修补的漏洞为改善供应链安全提供了重要机会。
通过SBOM实现透明度还可以解决其他风险。例如，从SBOM中获得的许可信息可以帮助企业在使用开源和第三方许可软件时确保遵守许可要求。例如，软件供应商在产品中包含的开源库可能包括许可条款，要求库的原始作者在产品相关文档中获得归属权。如果SBOM提供信息，使用该应用程序的组织也可以获得归属信息。这种更高的可见性为许可证合规提供了另一种潜在途径。SBOM数据还可以提供对应用程序中组件的最新状态的洞察，以及在组件未保持最新状态时相应的技术债务风险。这反过来可能会提供对维护成本和潜在拥有成本或未来合同的一些洞察。
2.1与软件SBOM消费来源相关的安全风险
SBOM为改善客户组织的软件资产管理、补丁管理和漏洞管理提供了透明度，并有可能衍生出增强的供应链风险数据。有效的开发人员或供应商提供的SBOM列举了纳入供应商产品的第三方软件依赖关系（包括开源和专有）。另一种方法可能在运行时需要任何额外的依赖关系，并由OSS供应商的包管理器工具集下载，在单独创建的SBOM中列举，例如由包管理器工具集。 SBOM集为软件资产管理和漏洞管理提供了必要的透明度。
图 1： 必需的 要素： 对于 自动化 可扩展性 SBOM 消耗
2.1.1如何实施和扩大SBOM的使用
将所有软件版本的 SBOM 纳入其中，将导致客户不得不消耗数千个 SBOM 来了解组织的风险暴露。使用相对简单的工具可以实现一些基本的好处：一个简单的脚本可以帮助解决一些直截了当的问题，例如“哪些产品的 SBOM 包含最近宣布的主要漏洞？”
然而，为了实现SBOM可以提供的更广泛的好处，组织应该最大限度地实现自动化的SBOM处理、分析和相关性。这需要软件供应链上的自动数据交换和互操作性，然后需要标准化的数据格式、实体解析和自动解析和摄取SBOM。一些工具可用于生成、使用和转换这些SBOM，随着用户和行业经验的积累，会有更多的工具。下面确定的SBOM格式解决了识别软件组件和相关元数据的核心问题，并包括必要的字段，以满足NTIA指导或CISA或其他组织进一步指导所定义的基线SBOM的需求。
2.1.2基线组件信息
SBOM的主要目的是识别组件及其相互关系。为此，需要一些基线组件信息。第4节中确定的SBOM属性，如产品版本号、依赖性标识符和SBOM作者，可以识别特定组件的基线属性。随着SBOM生态系统的成熟，最佳实践和要求可能会提前。例如，商务部2021年的指导意见将组件的哈希值视为“推荐数据字段”，而不是必填数据字段。政府或其他机构的未来指导意见可能会强制要求某些SBOM类型使用哈希值或类似的强标识符（参考上述SBOM类型文件）。
2.1.3自动共享和交换
整个供应链的SBOM数据需要技术组件、系统和功能的组合；标准化的数据格式；SBOM消费工具；以及与操作流程的集成。由于软件生态系统的多样化需求，没有一种通用的解决方案来满足SBOM消费。然而，在现有方法和手段的基础上对SBOM消费过程进行建模，将使供应商之间实现互操作性，减少差异，最大限度地减少对新SBOM消费工具的需求，从而通过适当应用SBOM消费自动化通过工具集成简化及时和可扩展的SBOM消费所需的过程。第3节确定了消费SBOM的详细过程。
对于安装在客户场所系统上的软件，SBOM元数据可以与二进制文件和软件一起分发。一些软件生产商可能愿意公开分享他们的SBOM，而其他生产商可能不想在客户之外分享这些数据，并使用访问控制机制来保护这些数据。
更广泛地说，SBOM共享模型应包括发现机制、任何潜在的访问控制模型和一些传输机制。消费者应该有一些方法知道SBOM是否存在、在哪里以及是否已经更新。客户应该管理访问技术，如凭证或解密密钥。使用SBOM需要集成到客户现有的操作基础设施中。完全消费能力还将允许集成到供应商可能没有预料到的各种工具中，如消费者的资产管理解决方案。如下所述，SBOM数据可以集成到现有的安全工具中，如资产管理或漏洞管理工具。
3 企业中的 SBOM 生命周期
本节描述了软件消费者获取、管理和使用 SBOM 的工作流程。“软件消费者”被广泛定义为包括从供应商、开发商或开源获取第三方软件功能的商业和非商业实体。
图 2： SBOM表生命周期管理
3.1软件 SBOM 交付
软件类型众多，交付软件的方法也多种多样。客户可以通过各种机制以各种方式接收 SBOM：
-
-
- 作为商业产品合同采购的一部分，
- 作为商业闭源软件下载的一部分或同时下载，
- 作为专业服务合同采购的一部分，包括开发和交付软件功能，
- 作为开源软件应用程序或组件的收购的一部分，
- 在设备连接到网络时的发现过程中，
- 通过供应商/开发商直接交付给客户，
- 通过客户门户或其他预先安排的机制，或
- 通过旨在帮助交付软件元数据的服务或存储库。
-
请注意，一些SBOM用户在购买相关软件之前或没有购买相关软件的情况下，就会发生SBOM用例，例如收购风险分析或提供数据验证或丰富。
3.1.1验收/验证
收到 SBOM 后，客户可以使用 SBOM 中描述的方法或通过预先商定的流程验证 SBOM 的完整性和真实性。为了最大限度地提高此流程的有效性，如何跨不同的软件生态系统一致地生成哈希值的标准化应该是 SBOM 社区的首要任务，并且应该包括当前流行的 SBOM 格式共享。
SBOM可能包含描述如何使用散列/签名方法验证SBOM完整性和真实性的嵌入信息。客户和供应商也可以使用未嵌入SBOM中的预先商定的方法。如果SBOM交付方法/基础设施可以进行完整性和真实性检查，建议消费者也验证SBOM的完整性和来源。ESF发布的《保护软件供应链（适用于开发人员、供应商和客户）》指南建议验证SBOM（例如，用于验证真实性和准确性），并在摄入之前解决任何不匹配问题。这可能还包括分析软件物料清单数据的完整性或依赖树中故意留出的“已知未知项”（见第4节）。软件成分分析（SCA）和/或软件扫描工具可用于确定软件产品或包的组件，以验证软件物料清单的准确性和真实性，也可用于验证或核实VEX信息，以支持SCRM风险决策。
如果提供给客户的 SBOM 不完整、深度不够或未包括专有组件的依赖关系，则可能需要调整供应商合同或其他风险缓解措施。
3.1.2企业的SBOM集成和管理
来自SBOM的数据可以用于许多企业工作流程，包括采购、资产管理、漏洞管理以及总体供应链风险管理和合规功能。因此，SBOM通常作为文件使用不如作为数据集合使用，这些数据可以被解析、提取并加载到自动化流程或记录系统中。企业可能有多种选择来使用SBOM，包括内部开发的工具/脚本、开源工具、商业产品和服务，以及这些选项的各种组合。
组织可能需要一个数据管理层来跟踪 SBOM，将它们映射到资产，并允许其他工具链接到 SBOM 数据并与之相关联。通过实现更好、更灵活和自动化的数据管理，该层可以支持多个工作流和企业流程，包括供应链风险管理、漏洞管理、未来采购分析、企业风险管理和风险评分（有关基于 SBOM 的风险评分的更多信息，请参阅本文档的第 4 节）。有利用 SBOM 内容的替代方法，如特定于 SBOM 的存储库、托管服务模型和基于 SBOM 文件的存储和检索方法。截至 2023 年，支持 SBOM 数据管理的工具才刚刚开始出现。
在某些情况下，数据可以存储在相关软件的附近，以便扫描工具更容易访问。消费者可能希望将其整合到SBOM存储库中。对于某些消费者，软件可能驻留在敏感网络或不允许直接扫描的系统上，如工业控制系统。
3.1.2.1 SBOM的提取、转换和加载
将SBOM提取、转换和加载到企业流程和平台中需要一个映射过程，将特定组件与一个或多个应用程序、系统或端点相关联。这些流程和平台的大部分价值来自映射和更新功能，这些功能可以保持整个企业软件库存和配置的准确性。在某些方面，SBOM数据类似于任何软件资产的属性数据。然而，SBOM数据的数量和粒度存在显著差异。与没有SBOM的传统商业采购软件功能相比，每个软件资产都有更多数据和更详细的数据。
因此，工作流程量，特别是在自动化工作流程中，可能会显著扩大，企业应该为此做好准备。这一步可能是上述管理步骤的一部分，也可能是更进一步的下游步骤。
出于监管原因或客户目前缺乏进一步处理 SBOM 的能力，客户可能希望在解析后存储原始 SBOM 文档/文件。无论哪种方式，SBOM 存储过程都使用内容管理方法：SBOM 接收时间、文件位置、文件内容、数据保留和文件存储的生命周期策略。这可能需要：
-
-
- 存储在企业库存或信息技术（IT）资产管理数据库中（例如，存储计算机序列号和软件许可证的同一数据库或文件系统）。
- 利用能够进行物料清单处理的统一端点管理（UEM）系统。它可以跟踪硬件资产、在其网络上运行的相关软件，并监控重大安全态势变化。
- 利用安全信息和事件管理（SIEM）软件解决方案，该解决方案可以收集、存储、汇总和分析来自网络设备、服务器等的数据。
-
如果合同中规定了供应商SBOM信息存储的具体安全措施，建议消费者确保SBOM数据流所进入系统的安全控制达到或超过SBOM供应商条款和条件中规定的控制。
作为文件的SBOM存储的生命周期政策应与该SBOM所代表的软件交付物的生命周期相关。该文件应持续存在，直到消费者正确地停用该软件资产，例如，自动扫描或手动清单表明与SBOM对应的软件资产不再存在于消费者的基础设施上，并且该信息不再与法律或取证目的相关（例如，发现软件资产更新或删除之前发生的违规行为）。停用 - 验证资产已从系统或设施中删除 - 比部署资产要困难得多。它需要比大多数IT企业更高的透明度和积极控制。因此，特别是考虑到许多SBOM数据的可压缩性，许多组织可能希望为SBOM制定默认的档案保留政策。为了支持这一点，SBOM应与版本信息相关联，以确保当前数据和存档数据之间的区别。客户需要能够发现和访问与其环境相关的SBOM。
3.1.3测绘和资产管理
如前所述，SBOM中的内容将输入现有的企业工作流程，包括采购、资产管理、漏洞管理以及总体供应链风险管理和合规功能。优先工作流程是将SBOM数据用于资产管理存储库、工具或系统，这些工具或系统可以将SBOM元素和数据映射到在整个企业中利用和部署的软件产品和组件。一些资产管理和漏洞管理系统在2023年刚开始整合SBOM数据。
一旦处理了SBOM，SBOM内容可以支持其他企业流程（安全、供应链风险管理（SCRM）、质量、许可、产品比较等），SBOM信息可以提供给客户企业内的各种SBOM信息消费者：
-
-
- 配置管理数据库（CMDB），
- 软件资产管理（SAM）系统，
- 安全运营中心（SOC），
- 采购工作流程，其中可能包括采购前尽职调查、承包商/供应商管理系统以及第三方风险和合规管理和报告，以及
- 软件供应链风险评估和管理功能
-
第4节描述了可以评估潜在自动化的SBOM消费过程。建议通过自动化流程而不是手动传播方法进行分发。
3.2使用SBOM内容
如果在实际收购发生后不久对 SBOM 进行评估，SBOM 可以告知与收购产品相关的风险决策，这可能会随着时间的推移而变化。最初，可以根据 SBOM 的内容（包括与 SBOM 组件相关的已知漏洞）来评估风险，但随着时间的推移，由于环境或新漏洞的变化，可以重新评估风险。
发现了“零日”漏洞。
“零日”漏洞可以在漏洞数据库中识别，例如通过与组件或产品相关的新注册的常见漏洞和暴露（CVE）。新威胁的通知可能来自媒体（新闻或社交）、供应商或其他第三方。理想情况下，“零日”漏洞使用标准化的机器可读格式宣布。
3.2.1拥有 SBOM 的内在价值
SBOM提高了客户组织在其环境中评估、部署和/或操作软件的谱系的可见性。对所有软件的这种更高的可见性对于适当的供应链风险管理和整体企业风险管理至关重要。提供给客户并由客户消费的SBOM内容为客户组织的风险管理提供了信息，同时不会影响软件供应商的敏感知识产权利益。即使在客户使用SBOM数据之前，客户也会受益于供应商拥有SBOM数据并有可能使用它来告知风险决策。这并不能保证供应商会使用这些数据，但拥有这些数据是必要的第一步。
如果供应商无法了解其软件供应链，客户应该谨慎对待对该软件及其供应链的信任。虽然目前可能没有任何已知的主动漏洞或漏洞，但这样的供应商可能无法做出任何声明或保证。提供SBOM的供应商表明其供应链的可视性，以及这种可视性的质量。
3.2.2已知漏洞
国土安全部（DHS）/网络安全和基础设施安全局（CISA）赞助了由MITRE公司维护的CVE列表。CVE列表是公开披露的计算机安全缺陷/漏洞列表，这些缺陷/漏洞被分配了CVE标识号。CVE列表中的CVE被输入由美国商务部非监管机构国家标准与技术研究所（NIST）维护的国家漏洞数据库（NVD）。NVD对CVE进行分析，提供元数据结果，如关联影响度量（通用漏洞评分系统-CVSS）、漏洞类型（通用弱点枚举-CWE）和适用性声明（通用平台枚举-CPE）以及其他相关元数据。
CVE 有助于 IT 专业人员协调工作，优先处理漏洞，使计算机系统更加安全。CVE 计划的任务是识别、定义和分类公开披露的网络安全漏洞，以及动态的已知漏洞利用（KEV）目录。
3.2.2.1 使用VEX澄清漏洞风险
并非软件产品依赖关系中的所有漏洞都会实际影响该产品的安全性。从这个角度来看，在SBOM中识别的漏洞可能会夸大产品的实际风险。解决这些问题对于供应商和客户来说都是无效的，因为供应商和客户都拥有有限的资源。
为了应对这些风险，国家电信和信息管理局（NTIA）和中国国家互联网信息办公室（CISA）促进了公共和私营部门在漏洞利用交换（VEX）方面的合作。VEX文件是一种机器可读的安全建议，可用于澄清和优先处理漏洞风险。VEX在技术上不是SBOM的一部分，两者都可以独立存在，但同时使用将最大限度地提高SBOM消费的效率和安全效益。
VEX实现、框架和/或规范提供机器可读信息，表明产品（或其组件之一）是否受到特定漏洞的影响，以及如果“受到影响”，是否存在建议采取的补救措施或是否存在解决漏洞的缓解措施。VEX的目标是允许软件供应商或其他方声明特定产品中特定漏洞的状态。VEX文档允许供应商和消费者关注构成最直接风险的漏洞，同时不会浪费时间搜索或修补不可利用的漏洞，因此不会产生影响。为此，VEX指示每个漏洞的状态：
- 不受影响 - 不需要针对此漏洞进行补救。
- 受影响 – 建议采取措施修复或解决此漏洞。
- 已修复 - 这些产品版本包含针对漏洞的修复程序。
- 正在调查中 - 目前尚不清楚这些产品版本是否受此漏洞的影响。将在以后的版本中提供更新。
此外，当产品被标为“不受影响”时，VEX允许文件包含一份说明文件创建者选择断言产品状态不受影响的理由声明。状态理由包括表明产品不受漏洞影响，因为组件未包含在产品中，以及易受攻击的代码在应用程序的上下文中永远无法执行。
虽然VEX是最近的一项发展，但有效的企业安全包括实施或利用现有的能力，以帮助识别产品是否受到漏洞的影响或建议缓解措施。
VEX可以通知补救措施。然而，重要的是要验证VEX中信息的准确性，包括任何建议的措施。理想情况下，VEX发起者应经过身份验证和筛查，VEX本身应检查其完整性。VEX将有助于扩大SBOM的消耗，并允许组织专注于实际对组织构成真正风险的漏洞。VEX工具和VEX集成到现有的安全工具中，在2023年刚刚出现。
一般来说，我们建议在消费者和开发人员/供应商之间的合同中提供VEX或类似VEX的信息。供应商可能希望在何时发布VEX方面采取不同的政策，例如在回应高调的错误、公开利用的漏洞，或者当一个新的
CVE是供应商SBOM中的一个组件。
3.2.3查询/报告
有效的企业漏洞管理需要确定与漏洞相关的风险。企业可以通过以下方式了解漏洞：
- 使用SBOM查询漏洞库；或
- 从供应商处收到与组件或产品相关的VEX（或类似信息）。
建议客户将SBOM或VEX与漏洞库相关联，其结果有助于确定风险评分。确定的风险评分用于确定适当的风险响应或行动（见第3.2.4节）。加权结果的概念是消费者责任的一部分。CISA优先考虑对上述KEV目录中列出的漏洞进行补救。
3.2.4行动
NIST SP 800-40r4“企业补丁管理计划指南：技术预防性维护”概述了软件漏洞生命周期，并概述了客户可能采取的软件漏洞风险应对方法（接受、缓解、转移和避免）。
根据软件产品的具体部署和其他安全控制的实施，客户可以评估风险是否可以接受，而无需采取任何额外行动。一个客户可以通过各种缓解措施避免新漏洞的利用，包括：
- 卸载易受攻击的软件，
- 停止使用存在漏洞的资产，或
- 禁用资产中不需要计算能力即可运行的功能。
修补并不总是立即可行的选择。该系统可能对组织的任务至关重要，停机将干扰运营，特别是在运营技术领域。该系统可能不受支持，或者供应商可能根本不存在或缺乏提供补丁的能力。其他潜在风险的缓解措施超出了所讨论的软件。在网络层面，经过调整的网络工具可以将易受攻击的软件与互联网或企业网络的其他部分隔离开来。组织可以假设，虽然已知的漏洞目前没有被利用，但威胁情报工作应该实时检测更广泛社区中的任何潜在利用，并设置自动防御措施作为回应。无法访问特定威胁情报的小型组织可以进行与当前CVE相关的软件组合分析，并/或执行主动和被动代码扫描，以解决部署软件的风险。组织可以通过实施第4节和第5节中引用的最佳实践来设置自动防御措施。
或者，可以通过购买网络安全保险或用软件即服务（SaaS）或云使用代替传统软件安装来转移组织风险。最后，可以通过消除（修补易受攻击的软件、禁用易受攻击的功能或升级到较新的软件版本）或部署额外的安全控制来减少漏洞利用。客户应向其SaaS提供商提出一系列问题，以确保其做法是安全的，并告知客户风险管理决策。
值得注意的是，VEX或其他建议或指导中建议的行动可能不会立即适用。例如，应用推荐的补丁可能会中断操作。
3.3现有软件的 SBOM 更新
应提供/获取现有软件产品的新的SBOM，用于软件更新、软件升级或增强现有软件产品先前SBOM的完整性。获取、验证、处理和存储新SBOM的过程将遵循第3.1节中描述的相同过程和方法，但有一个额外的步骤。新/更新的SBOM应与上一个SBOM进行比较，以识别自上一个版本以来引入或删除的新组件/依赖关系。这些更改应根据当前的威胁信息（例如CVE和/或VEX）进行验证，以确定、通知和更新当前的风险状况和风险评分（见第4节）。更新SBOM内容的持续使用将遵循第3.2节中描述的过程和方法。
3.4客户使用 SBOM 的示例
通过在企业威胁、风险和漏洞管理过程中利用SBOM内容，客户可能会减少暴露给特定漏洞的时间，并加快其补救过程。
图 3： 实例 属于 SBOM 物料清单 在里面 使用
以下用例说明了与上图3所示的SBOM消耗相关的流程和最佳实践：
-
-
- 软件产品XYZ软件已被收购并部署在整个企业中。在收购时，该产品的SBOM被接收、验证和处理。SBOM内容被加载到企业资产管理存储库中，与企业漏洞和威胁管理系统和流程相关联。
- 在未来的某个日期，将发布一个CVE，其中包含一个针对常用开源实用程序的主动利用漏洞。
- 该组织的威胁/风险管理系统将使用CVE数据，然后查询资产管理库，以识别在整个企业中利用/部署的任何软件产品，这些软件产品包含或依赖于易受攻击的实用程序。
- 在本例中，XYZ 软件包含易受攻击的开源实用程序。
- 客户的安全团队现在可以查看其组织内包含易受攻击的实用程序的软件产品，并可以评估该软件产品与此新报告的漏洞相关的风险，制定风险应对措施，并（如果决定减轻新漏洞造成的风险）开始准备并采取缓解措施以降低暴露风险。
- 所有这些都可以在CVE发布后近乎实时地完成。而在当前的模型中，如果没有SBOM内容，客户应该等待软件产品的供应商/开发商验证漏洞，然后通知其客户群潜在的漏洞。
-
在供应商/开发商开发出补丁或缓解控制措施之前，通常不会发出此通知。随着供应商/开发商提供有关漏洞的额外信息（例如VEX）和/或漏洞补丁，客户组织可以调整和更新其缓解措施和风险应对措施。
此外，将部署在企业内部的软件产品之间的SBOM内容相关联，可以为事件响应团队、取证团队、风险管理和采购提供强有力的洞察力。
4 SBOM风险评分
4.1将SBOM转化为风险信息
本节提供有关如何基于SBOM量化软件产品或组件风险的信息。
除了跟踪定义明确、已知的风险，如检查已知漏洞列表，SBOM数据还可以作为进行更多特定于上下文的风险分析的起点。可以进一步调查SBOM中提到的组件，以了解组件来源的详细信息，例如管辖权、成熟度（例如只有一个维护者的开源项目）或供应商的财务稳定性。这些数据可能不是SBOM中直接可用的，但SBOM数据可以用作这种增强的起点，可以提供更强的风险分析。
4.2风险评分的基本原理
在软件供应链中，缺乏一种一致的方法来与客户沟通给定产品或组件的风险。目前的方法在许多方面都不够充分，包括：
-
-
- 过时的合同或基于许可证的支持可能会影响下游补丁和产品更新的可用性。
- 供应商与客户之间缺乏透明度。
- 软件产品中依赖关系的复杂性呈指数级增长。
- 供应商对开源组件的使用呈指数级增长，但没有透明的方法来了解所获得的内容。
-
4.3风险评分定义
风险评分使组织能够根据定义的风险因素了解其供应链风险，并预测企业中给定软件产品未来风险的潜在可能性。风险评分是用于预测软件和/或其组件当前和未来风险的指标。该指标使用SBOM、VEX等指标以及支持SCRM的其他提要和内容开发。风险分析和用于评估产品和/或软件组件评分的标准将包括一个分类定义，以鼓励评估结果的透明度。在应用或评估风险评分时，软件的使用环境、软件的访问或隔离方式，或支持的流程和系统应该是考虑相关风险的因素。风险评分告知软件产品或软件组件的整体风险确定。
值得注意的是，在许多复杂的系统和系统体系中，可能存在多个SBOM作为集体解决方案的一部分，因此，风险评分是多种多样的。组织可以选择在总体层面结合风险评分，或在单个SBOM层面管理风险评分。
4.4风险评分建议
四个因素——漏洞、许可证、社区和依赖性——被确定为风险评分开发的良好起点。这些因素的完整性和/或覆盖范围将影响相关的SBOM风险评分。
下表显示了一组有形的来源和指标，用于在给定组织内实例化风险评分。粗体项目是主要的网络风险集中因素。
表1： SBOM 物料清单 危险 评分标准 过程
| 标准因素 | 描述 | 来源 | 评分指标 |
| 漏洞；弱点 （第4.3.1节） | 衡量给定软件产品中潜在和已实现的网络安全问题的基本标准。漏洞通用枚举或CVE、国家漏洞数据库（NVD）和相关的通用漏洞评分系统（CVSS）已经使用了数十年，并且被普遍采用，以推动优先级决策： | SBOM中的CVSS分数 LFX VEX机器人 | CVSS评分；Linux基金会LFX平台、VEX实施、框架或规范（见第3.2.2.1节） |
| |||
| 许可证类 （第4.3.2节） | 软件获取/采购流程的一个组成部分。 专有和开源软件许可证都对客户有隐含或明确的要求。SBOM中包含的许可证信息提供了对软件组件和依赖关系的透明度，这对SCRM和收购风险评估至关重要。许可证信息有助于SCRM流程 通过了解产品中是否存在任何不可接受的版权或许可条款来评估产品的可行性。 | SBOM 中的许可证信息 | 在许可证列表中找到 |
| 社区 / | 关注整体的理念 | 独立的 | 示例包括， |
| 供应商（S） | 给定软件的供应链 | 评价 | libraries.io 源码排名 |
| （第4.3.3节） | 产品软件产品正在 | 源(例如， | （Tidelift，未注明日期）；Linux |
| 消耗是它各部分的总和， | 图书馆.io，Linux | LFX基金会 | |
| 越来越多的第三方供应商被用于产品的创造。这个 | 基础等） | 平台（基础，N.D.） | |
| 以下因素是软件供应链完整图景的一部分：
-对已知漏洞的响应 | |||
| 依赖关系背景（第4.3.4节） | 组件应该是软件产品的一部分，以便其发挥作用。了解特定产品中存在的依赖关系对于确定使用特定软件产品的风险至关重要。SBOM是供应商与客户之间沟通依赖关系的新兴标准方式。 | SBOM 中的包装，或 独立评估来源 | 示例包括：libraries.io SourceRank；Linux Foundations LFX平台 |
4.4.1风险评分指导建议
制定供应商中立的指导或开放标准，以确定可汇总为风险分数的风险因素，可能会有所帮助。除了总价值本身外，这种风险分数还可以包括用于计算总体总价值的独特值的突破。
4.4.2漏洞风险
在创建SBOM时，CVE引用的漏洞是SBOM中的可选字段。虽然CVE引用可能来自SBOM，但新的CVE经常被发现，应该咨询其他来源（使用SBOM中的信息）。从CVE中，可以获得一组CVSS分数，以在风险评分中使用。从数学上讲，这些可以总结为创建一个汇总的漏洞因素结果或分数。例如：1个高+1个中=CVSS分数（7.7）+CVSS分数（4.1）=漏洞因素（11.8）为2个漏洞。也可以使用其他风险评分机制，包括特定利益相关者的漏洞分类。
此外，VEX内容将提供有关漏洞对软件产品适用性的关键信息，并将减少误报。
客户可能需要或要求当前的漏洞数据作为软件采购/交付的一部分，与SBOM（或等效物料清单）一起提供。值得注意的是，此漏洞列表将是动态的，很快就会过时。或者，上述流程（第3节）使用VEX或直接CVE映射/查询是更好的方法，可以用于SCRM和持续的风险/漏洞管理。
消费者可能希望探索能够将SBOM数据链接到漏洞数据库的工具，例如纽约长老会医院开发的开源DaggerBoard工具。如果可用，SBOM信息应与VEX、CVE、漏洞扫描工具等相关联。
例如DaggerBoard工具，以及软件组合分析工具和自动风险评分算法。
产品依赖关系中存在的漏洞只能说明问题的一部分。易受攻击的组件实际上可能不会使产品或其用户面临风险。漏洞利用交换（VEX）提供了进一步的背景信息。由CISA推动的SBOM社区正在将VEX作为一种安全咨询形式进行完善，通过传达机器可读的漏洞信息及其对特定产品的适用性来增强SBOM的使用。特别是，VEX引入了标记产品不受特定漏洞影响的能力。VEX将通过引入原始CVSS评分的上下文来增强风险评分脆弱性因素。这使得消费者可以看到特定产品的潜在可利用性，从而提高了准确性。将SBOM与漏洞联系起来可以标记风险，而VEX文档允许消费者对漏洞进行优先级排序。我们建议客户使用最新的漏洞信息来告知风险决策过程。
4.4.3许可证管理
大多数软件都是根据某种许可协议分发的。消费者应该意识到他们签订了哪些许可协议，以帮助避免其组织面临的潜在法律挑战。通常，在供应链采购过程中会对许可证进行分析，而SBOM提供了许可证信息的扩展可见性。
正如美国国家远程通信和信息管理局（NTIA）的《软件物料清单（SBOM）的最低要素》中所述，SBOM可以传达每个组件的许可证数据。许可证信息可用于以下方式来创建许可证风险因素结果：
- 涉及多少种不同的许可证？许可证数量越多，复杂性越高，风险也越大；和
- 限制或使消费者面临不利条款的关键许可证类型。
4.4.4社区
社区（例如开源或供应商）是分析和获取准确信息最困难的要素。然而，SBOM中的几个条款使分析得以进行，以告知风险决策。
可以从开源资源（例如ClearlyDefined、libraries.io、Linux Foundation LFX等）或直接从开源存储库的源代码中收集其他信息。这些源代码可以用作情报分析和关联的输入，以回答关键问题，从而创建风险评分，包括：
- 社区或供应商如何积极使用或支持，
- 规模有多大（社区成员数量/支持团队规模），
- 更新频率，
- 遵守各种开源最佳实践，如OpenSSF最佳实践，包括使用版本控制软件、代码审查过程文档和实际实践、治理等。
- 表现出应对安全问题的能力，
- 潜在的坏行为者影响，
- 地理参与和设施（外国所有权、控制权或影响力（FOCI））。
不同的组织会关注这种风险的不同方面。司法管辖风险可能是国防承包商的首要合规问题，而重视弹性的组织可能会关注供应商的漏洞披露政策，以及它在历史上对报告的漏洞做出快速有效反应的能力。我们建议客户使用这些参数来为他们的风险决策提供信息。第1阶段客户文件介绍了SBOM消费的概念。
4.4.5依赖关系
依赖关系是 SBOM 的关键部分，为消费者的决策提供了宝贵的信息。SBOM 依赖关系信息为情报分析提供了输入，从而可以开发依赖因素评分。这可用于权衡许多关键问题，包括使用特定软件产品需要多少外部包/库/事物。
客户应使用依赖关系来评估使用特定软件的风险。
4.4.5.1示例：
- 考虑购买两家竞争产品的供应商。
- 供应商A提供了一份SBOM，表明他们的产品使用了大量旧的开源依赖关系，但没有VEX。
- 供应商B提供了一份SBOM，表明他们的产品使用了少量较旧的开源依赖项，并包含一个VEX产品，为漏洞提供了上下文。
- 这种新的依赖透明度使消费者能够在采购决策中对两家供应商进行更好的比较。
4.4.6自定义风险模型的局限性
虽然许多组织面临类似的风险，但每个组织都是独一无二的，并且具有不同的风险承受能力。将风险归结为单一的分数对于管理建模和执行仪表板非常有用，但从行动导向的角度来看，这可能不是最好的。例如，CISA已经开始强调利益相关者特定漏洞计算器（SSVC），该计算器使用决策树来补充和补充通用漏洞严重性评分（CVSS）。从更广泛的宏观层面来看，独特的评分计算可能更难证实、写入合同，并由市场上的其他人验证。
现有的服务和工具提供了从漏洞优先级到第三方供应链风险管理等特定的见解。其中许多工具已经开始整合SBOM。组织可以选择在内部构建这些能力，或通过合同管理/服务模型方法来支持这些风险管理功能。
4.4.7其他信息
有关 SCRM 和收购工件实践的更多信息，请参阅第 2.1 节“采购和收购”中的“保护软件供应链：客户推荐实践”。
4.5组织如何使用SBOM风险评分来降低风险
启用风险评分的第一步是实施SBOM的使用，如第5节所述。SBOM可用于通过已建立的自动化框架计算风险评分因素。自动化框架可以扩展到工作流系统，以建立可审计的决策。
图4 实施运作 SBOMs 对于 危险 评分标准
可以从公开来源收集更多信息。
在建立工具以支持消费组织内的风险评分时，应制定加权标准。该标准使根据产品用例定制结果评分成为可能。有效的加权标准将仔细考虑给定用例中评分的时间点性质。没有适用于所有客户组织的通用风险评分。
4.5.1利用风险评分进行供应链风险管理和企业威胁管理
风险评分方法提供了一种持续沟通风险的方法，以支持组织内的SCRM实践。风险评分可用于多种类型的分析，包括：
- 在平整的平面上并排比较产品，
- 消费者组织可以根据组织的需求灵活地衡量风险评分，
- 在SBOM中定义的依赖关系摘要；产品依赖多少个级别和多少个外部组织/项目，
- 在实践社区或大型企业内共享商定的风险水平。
在组织内部，企业威胁管理（ETM）实践了解其环境内软件的组成是关键的第一步。SBOM在软件组件级别提供细粒度可见性，以暴露新漏洞带来的潜在威胁。
不幸的是，一旦你开始收集 SBOM，你很快就会拥有大量的数据。通过添加风险评分方法来增强 SBOM，可以汇总威胁以进行更高级别的分析。这为已经负担过重的 ETM 组织提供了一种节省时间的方法，使其能够将精力集中在软件产品上。
5 实施 SBOM
为了充分实现SBOM的价值，需要组织网络政策和程序，以便企业中所有软件成功、敏捷、自动地实施SBOM消耗。这与其它类型的安全数据没有什么不同。例如，威胁情报数据已经经历了类似的演变，并且具有类似的成熟度多样性。实施适当的操作流程将是使决策最小化SBOM内容所显示风险的先决条件。以下一系列缓解措施将有助于降低与软件相关的风险。
-
- 识别软件的易受攻击和/或可利用版本，并相应地优先修补。监控这些系统/软件的恶意或异常行为，确定与这些观察相关的风险，并自动实施纠正行为。人工智能/机器学习模型可以帮助自动检测恶意或异常行为。
- 使用从SBOM收集的数据及其分析，并将其直接纳入您的风险管理流程，以确定软件供应风险和组织的风险承受能力。这也意味着要结合应用对策、缓解措施或其他风险控制活动的机制。
- SBOM和SCRM流程的使用与“零信任”架构方法相辅相成。
一旦发现漏洞，可以使用SBOM提供的数据。首先，根据可能性和影响来评估结果。可能性是指使用发现的漏洞成功攻击的概率。影响应考虑对公司品牌、底线和客户体验的直接损害和长期影响。
四象限方法是一种评估在COTS软件中发现的开源漏洞的有效方法。例如，具有某些漏洞的软件——这些漏洞被认为影响较小，不太可能被利用——可以通过简单地接受低风险水平来批准购买、续订或维护合同。显然，具有高影响、高攻击可能性的软件可能需要被拒绝。
然而，通常不可能拒绝任何对业务至关重要的软件。虽然在COTS采购过程中使用SBOM数据是一个相对较新的学科，但这里的假设是，客户和供应商都将真诚地采取行动，以提高产品的安全性并降低。
随着时间的推移，安全风险也会增加。此评估过程适用于所有已部署的软件。图3描述了SBOM结果到手后要遵循的连续决策工作流程。
图 5： 这个 4 象限 方法
6 结论：SBOM的今天和明天
- SBOM消耗是新的，并将不断发展和扩大。
- 新兴工具将有助于自动化和扩展。
- 可以理解的是，工具还没有到位——直到最近，SBOM数据还相当稀缺，因此当时对开源软件或专有SBOM消费工具的需求并不多。
- 不同的组织将关注不同的风险，他们可以通过软件透明度更好地管理这些风险。
- 该行业仍在想象用例，并期望随着SBOM变得越来越普遍，会出现更多用例。
- 仅仅询问 SBOM 并保留 SBOM 数据以应对紧急咨询仍然有价值。
- 软件源代码管理只是软件供应链安全的一部分，基本的卫生和关注其他C-SCRM指导仍然很重要。
- 应开发一套与供应商无关的开放式标准风险因素，这些风险因素可以汇总到SBOM的风险评分中。
SPDX - https://spdx.github.io/spdx-spec/
SPDX2 - SPDX format 2.2.2 CycloneDX - https://cyclonedx.org SWID ISO/IEC 19770 - https://www.iso.org/standard/65666.html & https://csrc.nist.gov/projects/software-identification-swid/guidelines KEV - https://www.cisa.gov/known-exploited-vulnerabilities CVE - https://cve.mitre.org/about/cve_and_nvd_relationship.html VEX1 - https://ntia.gov/files/ntia/publications/vex_one-page_summary.pdf VEX2- https://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_April2022.pdf VEX3 - https://www.cisa.gov/sites/default/files/publications/VEX_Status_Justification_Jun22.pdf SWID1 - https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/ LIO1 - https://libraries.io LFX1 - https://lfx.linuxfoundation.org CD1 - https://clearlydefined.io/ SBOM - https://www.cisa.gov/sbom Risks and costs of treating SBOM data as confidential/classified/etc. There are tradeoffs. See NTIA myths document: https://ntia.gov/files/ntia/publications/sbom_myths_vs_facts_nov2021.pdf SPDX specific Risk Scoring fields and criteria SBOM formats SPDX format 2.2.2 https://www.ntia.gov/files/ntia/publications/sbom_formats_survey-version-2021.pdf) Formats https://becomingahacker.org/sboms-csaf-spdx-cyclonedx-and-vex-todays-cybersecurity-acronymsoup-5b2082b2ccf8 extra info SBOM formats 2021 https://www.ntia.gov/files/ntia/publications/sbom_formats_surveyversion-2021.pdf
附录B：缩略语列表
| 缩略语 | 描述 |
| 人工智能/机器学习 | 人工智能/机器学习 |
| CMDB数据库 | 配置管理数据库 |
| CIPAC | 关键 设施 伙伴 咨询 委员 |
| 中国国际安防展 | 网络安全和基础设施安全局 |
| CMT模型 | 危机管理团队 |
| 国家社会服务委员会 | 国家安全系统委员会 |
| 中国石油集团工程设计有限责任公司 | 通用平台枚举 |
| CSAF | 通用安全咨询框架 |
| CVE漏洞 | 常见漏洞和暴露 |
| CVSS评分 | 通用漏洞评分系统 |
| 国土安全部 | 国土安全部 |
| 行政命令 | 行政命令 |
| ER 电子记录 | 实体解决方案 |
| 欧洲科学基金会 | 持久安全框架 |
| ETL认证 | 提取、转换和加载 |
| ETM 电子交易市场 | 企业威胁管理 |
| FOCI | 外国所有权、控制权或影响力 |
| IAMR 音频 | 集成资产管理库 |
| IMDRF | 国际 医疗 器械 监管 论坛 |
| 信息技术 | 信息技术学 |
| KEV | 已知的漏洞 |
| LFX | Linux基金会 |
| 美国国家标准技术研究所 | 美国国家标准与技术研究院 |
| 国家安全局 | 国家安全局 |
| 美国国家远程通信和信息管理局 | 国家 电信 和 信息 管理 局 |
| NVD | 国家漏洞库 |
| ODNI：国家情报总监办公室 | 国家情报局局长办公室 |
| OMB 办公室 | 管理 和 预算 办公 |
| ONCD公司 | 国家网络主管办公室 |
| OSS系统 | 开源软件 |
| OWASP安全 | 开放Web应用程序安全项目 |
| SAM 部门 | 软件资产管理 |
| SBOM 供应链管理 | 软件物料清单 |
| SCA 架构 | 软件成分分析 |
| SCRM客户关系管理系统 | 供应链风险管理 |
| SIEM系统 | 安全信息和事件管理 |
| SOC，系统芯片 | 安全 运营 中心 |
| SP 模式 | 专门出版物 |
| SPDX 协议 | 软件包数据交换 |
| SWID 标签 | 软件标识 |
| TTPs | 策略、技巧和程序 |
| UEM系统 | 统一端点管理 |
| VEX机器人 | 漏洞利用交换 |
| 词语 | 释义 |
| 合规风险 | 违反监管要求或公司政策的风险 |
| 退役处理 | 退役是一种战略方法，用于系统地淘汰过时且成本高昂的遗留应用程序，而不会影响业务需求或合规性要求。 |
| 实体解决方案 | 确定多个记录是否引用同一实体/组件的过程 |
| 许可证风险 | 违反组件许可条款的风险 |
| SBOM 集成资产管理库 | 一个数据库，允许用户存储、管理、检索和搜索与集成产品相关的 SBOM。 |
| 安全风险 | 组件暴露漏洞或被主动利用的风险 |
| 开源软件 | 开源软件通常是通过开放式协作开发的，其源代码由作者/制作者提供，供任何人使用、检查、修改和/或重新分发。 |
1094
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
