《构建软件组件透明度：建立通用的软件物料清单（SBOM）》解读（下）
1
摘要
2021年10月21日，美国国家电信和信息管理局（NTIA）发布《构建软件组件透明度：建立通用软件物料清单（SBOM）》第二版。该文件旨在建立一个通用的、格式化的、可操作的方法，以便识别并列出软件组件及组件信息和关系依赖清单，从而实现对软件的组成、安全和知识产权等方面的有效跟踪。
本文将简要解读该文件的第三章内容。第三章主要阐述了如何建立和应用软件物料清单（SBOM）。文件中指出应该在软件的开发、打包、测试过程中通过一系列方法，生成准确的SBOM信息。此外，还介绍了应使用通用格式交换和传递SBOM。获取到的SBOM可以应用于漏洞管理、知识产权管理、可信度管理等方面。建立通用SBOM有助于软件安全领域实现SBOM标准统一化，进一步加快修复漏洞的速度，提升漏洞修复能力。
2
背景
如今，大多数软件都包含一系列复杂的第三方软件组件，既有专有的，也有开源的。在处理一组复杂的部件时，保持所有项目和源位置的运行列表至关重要。否则将很难监控正在使用的组件，这可能会导致代码过时或不安全[1]。
为解决软件供应链透明度不佳的问题，2018年7月，NTIA召开了由多部门利益相关者参加的会议，讨论提升软件透明度以及用于描述软件组件通用格式的提案。这次会议启动了一个多利益相关方流程[1]，最终设立多个工作组。本文件由框架研究工作组编写。
SBOM建立了一个动态可跟踪的图表，能够纵览软件中使用的组件或开源库。将SBOM与漏洞管理、知识产权许可等结合使用可以有效管理组件和开源库。从全局范围掌握软件生命周期能够消除软件对核心技术人员的依赖。因此，在软件的开发、打包、测试和使用过程中，需要一些手段和工具回答以下问题：
1、如何确定软件使用了哪些组件或开源库？
2、如何判断这些组件或开源库是否安全？
3、这些组件或开源库什么时候升级？
4、使用的组件是否具有知识产权？
在建立SBOM时，需要明确界定如何创建和何时创建SBOM，以及如何有效获取上游软件和组件的SBOM。本标准中关于SBOM的流程说明详细回答了上述问题，有助于建立通用的、及时的且可交换的SBOM。
3
正文解读
3.1
SBOM流程概述
SBOM流程管理是使用SBOM的重要环节。是否能够有效使用SBOM的关键在于正确创建和交换SBOM信息。SBOM流程需要重点解决的问题包括SBOM的创建、维护和传递三方面，以确保SBOM与实际软件能够完全一致地对应起来。
首先，从利益相关者角度来看，参与SBOM创建和交换过程的利益相关者包括：软件的生产者、消费者和运营者。每个利益相关者都需要非常仔细地维护和创建与自己相关软件的SBOM，如果任何一个相关者在维护和创建时导致SBOM信息错误或者不完整，将很难保证后续SBOM的准确性。
第二，SBOM的生成和修改过程涉及到软件构建、打包和部署三个环节。每个环节都可能涉及到新组件的使用和更新，不论是那个环节，只要出现组件变更或修改，就需要更新SBOM，这样才能确保SBOM的准确性。
第三，如何有效传递生成的SBOM信息也至关重要。在保证SBOM正确性的前提下，还需要有效的可访问通道和互相兼容的格式进行SBOM交换。
完整准确的SBOM的应用场景很多，包括但不限于以下三种情形。首先，通过SBOM可以获知该软件的包含组件及组件信息，便于发现和修补软件漏洞；其次，通过SBOM可以获知该软件包含组件的知识产权，从而便于判断是否存在侵权等问题；最后，通过SBOM可以获知软件完整的组件信息，便于监管和审核软件的可靠性。
3.2
SBOM流程概述
3.2.1
如何创建SBOM
为了创建SBOM，供应商应定义其软件组件，为其创建的组件生成基线信息和附加属性，并一一列举所有直接包含的组件。理想情况下，供应商软件构建和打包过程的组成部分应包括生成的SBOM信息，这可以通过修改现有的开发工具来实现。
任何创建、修改、打包和交付软件或软件系统的实体都被视为供应商，因此该实体同样负责定义组件和创建SBOM。同时还包括系统集成商，他们本质上被视为是SBOM的供应商。组织可以作为内部开发组件的供应商。
当上游供应商提供了所含组件的SBOM时，这些SBOM将添加到主要SBOM中或与主要SBOM合并。如果无法获得此类信息，供应商可以尽最大可能提供SBOM，这使得包含组件的SBOM作者与该组件的供应商不一致。在组件之间的关系章节中描述了一种方法，即SBOM作者对供应商没有提供间接包含的上游组件SBOM的情形进行断言。
SBOM信息包括用于标识组件的属性和用于捕获组件特性或相关信息的附加属性。此外，身份属性也是必不可少的，是否需要其他属性视具体使用情境或应用程序而异。
来自组件供应商的SBOM可以作为组件的记录系统或权威信息来源。一些信息可能需要通过其他外部来源进行验证，例如，有关组件的漏洞信息，有时可以使用通用平台枚举(CPE)从美国家漏洞数据库(NVD)获得。
3.2.2
何时创建SBOM
在发布新组件时应当创建SBOM。这与构建、打包或部署活动的情形类似。当组件发生变化时，包括添加新的上游组件时应更新SBOM。当新的SBOM信息可用时，即使组件本身并未更改，SBOM也应作出更改。组件更改通常包括更新、升级、发布和补丁。理想情况下，对组件的更改由版本字符串的更改来表示。维护当前的SBOM信息至关重要。
更改现有组件（包括打补丁或更新）时，可以将更改本身视为一个单独添加到现有SBOM中的新组件，或最好使用新版本字符串来创建一个新组件。在表1的示例中，“ Bob 's Browser v1.1更新37”相当于“Bob 's Browser v1.1.1”。SBOM作者应始终使用一种标记方法。
3.2.3
SBOM交换
交换SBOM信息是很有必要的。交换信息主要是通过一个单一的下游供应链环节，直接从供应商到消费者进行交换。供应商将SBOM作为交付组件的一部分交付给消费者，或者说提供了一种让消费者可以轻松获得SBOM的方式，例如URL或其他引用。这种直接交付并不妨碍供应商、消费者或其他人对SBOM信息进行汇总或分类。
由于各种软件和设备生态系统的多样性，一个SBOM交换机制可能不够。一些现有的格式（即SWID和SPDX），在组件分发或交付时被当做附加文件。存储和功率受限的设备可以选择提供一个URL，便于在供应商的网站上查找SBOM信息。对于这类设备，动态访问SBOM也是一个不错的选择。互联网工程特别工作组（IETF）已经开发了一种用于最终用户发现SBOM的协议和格式，协议可以在本地设备上使用或在网站上共享。该规范是“格式中立”的，这意味着它支持SPDX、CycloneDX、SWID和未来的格式[2]。协议（如Rolie[3]、OpenChain[4]、MUD[5]和Atom[6]）可用于交换大量信息，并能够按需高效地收集信息。能够使用这些动态协议是继续使用SBOM的关键。
3.2.4
网络规则
SBOM的参与者包括创建SBOM信息的供应商和作者，以及接收SBOM信息的消费者和可选中介服务（如组合分析和相关性分析）的提供者。在许多情况下，参与者既是供应商又是消费者，在供应链中的某个位置中运作。
参与者应遵循一套网络规则，以便SBOM系统能够大规模运行。供应商定义其所开发的组件，并为组件创建SBOM。对于上游组件，供应商从相应的上游供应商处获得SBOM。如果无法获得上游SBOM，即使这涉及创建或省略基线属性，供应商或其他作者也可以创建SBOM。
一个SBOM中必须至少列出一个主要组件，主要组件定义了SBOM的主体。SBOM列出的组件应包括：
1. 最初由作为软件权威来源的供应商所创建的组件
2. 集成为提供了SBOM的上游供应商的组件
3. 集成为不提供SBOM的上游供应商的组件
作为向用户交付组件的一部分，供应商还应交付相关的SBOM，或为消费者提供一种易于获得SBOM的方法。SBOM包括供应商最初创建的组件和供应商从其他供应商获得的组件。
如图1所示，一组相互连接的供应链可能是一个有向无环图。最终上游供应商仅创建原始组件，不包括任何来自其他供应商的组件（即不具有依赖性）。在在用户图中，大多数参与者既是供应商又是消费者。甚至最终用户组织也可以充当供应商，为内外部组件（如网站、移动应用程序或物联网设备）生成SBOM。
供应商不仅负责他们创建和包含的组件，还负责向下游消费者提供收集到的组件集。在宏观经济意义上，供应商是最低成本规避者，因为供应商拥有其组件的高质量权威信息，同时他们生成和共享这些信息的成本相对较低。此模型可以将生成SBOM信息的成本分配给供应商[7]。
在供应链网络中，有一些供应商可以为上游组件创建SBOM。在这些场景中，供应商是SBOM的作者，而不是上游组件的供应商。供应商应当在创建此类SBOM时明确表示他们只是SBOM的作者，而不是上游组件的供应商。这将告知消费者，供应商缺乏该组件的第一手权威SBOM信息。在这种情况下，作者姓名和供应商名称是不一致的。
SBOM交换和网络规则的概念旨在帮助选择和操作软件的人员能够获得他们在不同供应商和供应链中使用的组件的综合列表。图1中示例显示了来自两个不同供应链的两个软件产品（主要组件）的同一位用户。用户有两个SBOM，分别是：Acme Application和Nancy's NanoPhone。其中Nancy的NanoPhone的SBOM如表2所示。
图1：具有两个供应链的用户图
3.2.5
角色和视角
3.2.5.1 视角
不同的利益相关者使用SBOM的方式互补但不相同。SBOM在整个供应链中的角色和利益体现了三个利益相关者（即软件生产者、选择者和运营者）的视角[8]。
3.2.5.1.1 生产
SBOM的设计理念是所有供应商都应为自己的组件创建SBOM。当上游组件的SBOM不可用时，供应商可能需要为其他供应商的组件编写SBOM。如果供应商没有提供SBOM信息，这种不明确性可能导致下游用户对产品的未知部分做出最坏的假设。对供应商来说，SBOM的另一个好处是能够确定应该联系哪个组织来修复上游组件中的漏洞。
3.2.5.1.2 选择
SBOM可以被使用相关组件或产品的潜在选择者(例如，开发、获取或采购)使用。选择者可能对直接归属于产品的信息感兴趣，例如，软件的基线组件或许可证信息。其他SBOM因素如许可、漏洞和支持生命周期等也可能会影响选择过程。
3.2.5.1.3 操作
在任何行业中，软件运营者都在努力解决组件或产品信息不完整的问题。SBOM作为能提供此类信息的合适来源，可以提高对软件及其组件的可见性。其中一些组件信息可能是静态的，例如，许可信息。但由于软件的动态特性，某些信息可能会在组件初次分发后发生更改或更新。
在SBOM的更新中可以找到吸引软件操作者兴趣的大部分信息。软件运营者还可以使用当前信息来验证软件的状态，然后再在其站点或业务中进行生产。
3.2.6
SBOM用例
SBOM基线属性的核心在于识别组件及其关系。大多数SBOM用例需要额外的信息，比如新属性、关系类型或外部数据连接。本节重点介绍几个值得注意的SBOM用例。
3.2.6.1 漏洞管理和VEX
SBOM的重要用例之一是漏洞管理。如今，确定软件是否使用了易受攻击的上游组件以及下游组件，以及组件中是否存在可利用的漏洞，这通常是一项昂贵且耗时的工作。SBOM和VEX数据可帮助供应商、用户和其他维护者更快、更准确地评估易受攻击的组件所带来的风险，这些组件通常隐藏在不透明的供应链关系背后。
漏洞管理通常需要用到漏洞信息源（如CVE和NVD）、漏洞到组件的映射（如NVD中使用的CPE）以及传达漏洞或可利用性状态的方法（如VEX）。虽然最初开发VEX是为了解决漏洞管理用例，但VEX并不局限于与SBOM一起使用，也不一定要包含在SBOM中。需要担心的是基于有限信息（如版本字符串、协议标语或其他试探法）可能无法准确检测到软件漏洞。即使SBOM显示上游组件中存在漏洞，VEX也可以用于说明软件是否容易受攻击。这可以节约供应商和用户在管理、生产和应用未受影响组件时进行安全更新的成本。
3.2.6.2 知识产权
有许多知识产权用例可以通过更好的清单数据加以改进。管理所包含组件的软件许可（包括对使用或重新分发的限制）和跟踪授权（允许使用组件的副本或功能）是两种常见的用例。值得注意的是软件组成分析工具，它可以帮助确定组件信息以便于确定许可证要求。SBOM数据将在不依赖于二进制分析工具的情况下改进对于软件组成的认识。此外，SPDX和SWID最初都被设计用于传送许可证和授权信息。
知识产权用例需要将不同的许可证和许可证类型与组件关联起来，并需要一种方法来评估由具有不同许可证的组件合成的组装商品的实际效果。
3.2.6.3 高可信度
组件谱系和出处的信息能够保证组件来源和完整性的高可信度，例如，组件是如何构建和打包的，谁创建和修改了它们，以及它们在供应链中的监管链。在其他用例中，高可信度还需要相关组件、不同的关系类型和可能不同的供应商信息的附加属性。
3.2.7
工具支持
SBOM生成和管理工具的可用性对于SBOM能否被广泛采用至关重要。可用工具包括SWID-Tools[9]、SWIDGenerator[10]、CycloneDX Tool Center[11]、和SPDX Tools[12]。SBOM需要集成到软件开发、打包和资产管理系统中以体现其功能。
3.3
SBOM流程注意点
SBOM的创建和使用是SBOM是否能有效提高软件组件透明度的重要环节。因此，在运行SBOM流程时应特别关注以下三点：
1、将建立和维护软件的SBOM作为必要工作，以保持SBOM的正确性；
2、使用成熟的工具管理SBOM，防止人工管理出现遗漏；
3、与上下游合作伙伴确定共享SBOM信息的方法，使得相关方能够获取到准确的SBOM信息。
4
影响
首先，通过SBOM流程的运行，生成有效的软件SBOM清单，可以让企业更早识别并缓解系统或许可源代码内的潜在缺陷，因此有效控制风险。
第二，SBOM软件清单还将帮助开发人员更好地审查嵌入至当前项目中的产品代码，推动软件开发安全实践的普及。而在软件使用者方面，更高的透明度则能够有力支持采购决策，轻松了解该软件的安全状况，和开发方是否严格遵循软件许可要求。
第三，通过建立和维护SBOM信息，可以让开发、测试、使用人员开始关注软件的“组成成分”，主动选择安全、可靠、可信的软件进行使用，避免软件供应链产生的风险。
5
趋势预判
趋势一：支持基于云的软件即服务的模式
很多现代软件应用程序都以服务的方式提供。这为SBOM数据带来了独特的挑战。由于软件并未在客户基础设施上或在其控制下运行，因此风险管理角色是不同的。用户并不负责软件维护工作，也并不控制任何环境因素。服务提供商负责了解相关信息并就漏洞或风险信息采取行动。[13]
因此云服务提供商必须维护一个自身提供服务的软件的SBOM清单，并确保该清单能够供使用者进行查阅。同时应建立一种机制，使不同云服务提供商以一种通用方式将SBOM提供给使用者。
趋势二：SBOM工具和信息的开放化和接口化。
构建完成SBOM后，最重要的是SBOM信息能够有效传递给下游使用者。使用标准的开放方式，可以让下游使用者方便、安全地获得该SBOM。应避免软件获得和SBOM获得的分离，以保证SBOM的可用性、完整性。
此外，还应保证SBOM用户能够快速获得该SBOM所包含组件的其他相关信息，例如，组件的漏洞情况、组件的知识产权信息等。因此需要有相应的接口确保可以通过SBOM获取到所包含组件的漏洞信息、知识产权信息等。
趋势三：SBOM工具的集成化。
在建立SBOM时，最大的挑战在于如何保持软件中使用的组件和SBOM记录的信息一致。因此必须使用专门的工具进行自动化维护、检查和生成。目前有部分标准工具可供选择，包括：SWID-Tools、SWIDGenerator、CycloneDX Tool Center和SPDX Tools。此外，必须将工具集成到现有的开发、打包、测试环境中，才能使工具发挥最大的效果。同时还要考虑目前不同行业、客户所使用的开发、打包、测试环境可能存在差异，需要有统一的方法实现SBOM工具的集成。
6
总结语
我们应该仔细研究美国在软件物料清单方面的标准和技术，大力推进我国的软件物料清单的建立。应当建立相关标准，使相关单位在开发和使用软件时能够主动创建并共享SBOM。应当引导我国本土企业开发具有自主知识产权的SBOM管理工具，使我们在软件开发、使用过程中能够应用SBOM管理工具对软件进行有效管理。此外，应当注意标准、流程、工具等能够与国际接轨，以便在进行全球贸易时能够经得住审查，避免使用具有未知风险的软件和开源组件给我国网络安全造成影响。
7
其他
7.1
参考文献
[1]https://blog.websoft9.com/sbom/ SBOM软件物料清单，软件架构的基石
[2]https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-02
[3]https://datatracker.ietf.org/doc/html/rfc8322
[4]https://www.openchainproject.org
[5]https://datatracker.ietf.org/doc/html/rfc8520
[6]https://tools.ietf.org/html/rfc4287
[7]https://www.lawfareblog.com/cybersecurity-and-least-cost-avoider
[8]https://ntia.gov/files/ntia/publications/ntia_sbom_use_cases_roles_benefits-nov2019.pdf
[9]https://apps.fedoraproject.org/packages/swid-tools
[10]https://github.com/strongswan/swidGenerator
[11]https://cyclonedx.org/tool-center/
[12]https://spdx.dev/resources/tools/, https://tools.spdx.org/app/
[13]https://www.csdn.net/tags/MtTaMgxsNjc2NzUyLWJsb2cO0O0O.html
END
SBOM系列政策文件研究由中国信通院、中国联通联合牵头，筹建单位奇安信、会员单位悬镜安全、绿盟、高伟达、比瓴科技、盈高科技、亚信、北银金科、孝道科技、南洋理工大学、华为支持开展，包含13篇政策文件的翻译、解读，涵盖了SBOM整体内容概述，SBOM的生成、获取、交换、共享、管理、使用等全生命周期过程，回答了关于SBOM的常见问题，以期助力社区的安全研究研讨，加速推进提升国内供应链的安全管理水平。
