软件物料清单实践指南2023.02中国信息通信研究院 201.总体介绍1.1 诞生背景1.2 代表工作1.3定义内涵02. 价值与用例03.组成要素04.格式与工具05.生命周期06.常见问答07.知产与保密08.选择与决策09.行业实践10.发展趋势 3诞生背景上世纪以来，物料清单在提高透明度中的作用愈发重要，已惠及汽车业、食品业、传统制造业等，形成的基本理论和原则于2013年开始应用于现代软件开发，并于近5年取得长足进步。2018年7月19日，美国国家电信和信息管理局（NTIA）召开了多部门利益相关者会议，讨论增强软件透明度的一项提案，目的是建立一个通用框架，以在软件产品中描述组件。NTIA Software Component Transparency框架工作组意识和采用工作组格式和工具工作组医疗保健概念验证工作组工作重点证明SBOM的成功应用，为其他行业提供参考自动化SBOM 的生成和使用将SBOM 推广为一种理念、一种实践定义和完善SBOM 规范，推动广泛、可扩展的采用信息共享格式构建促进实践支持活动所有行业NTIA多利益相关方流程计划 4代表工作自SBOM诞生以来，美西方多个组织机构积极开展研究，多个行业已开始推进SBOM的应用，使得SBOM理论发展不断完善，并开始在实践中丰富内涵。2020.7，大西洋理事会“Breaking Trust”报告2020.9，BSA联盟安全软件框架CISQ 《可信系统宣言》2020.11，ENISA确保物联网安全的准则2022.4，FDA售前准则ISO/IEC5230:2020，高质量开源许可证合规2019.1，JSP——联合安全计划2018、2021，MITRE “交付无碍”项目2019.3，MUD，制造商使用说明2021.1，荷兰政府的国家网络安全中心《使用SBOM增强网络安全》2020，美国国家公路交通安全管理局《现代车辆安全的网络安全最佳实践》2022.2，NIST《安全软件开发框架》OWASP组件分析项目SWHID软件遗产项目，为组件提供唯一标识符2019202020212022 5定义内涵随着SBOM研究的不断深入，其理论体系已基本搭建完成并通过行业实践不断完善，包含有供应商、作者、消费者等术语体系。SBOMSBOM是一份正式规范且机器可读的软件组件清单， 清单中包含这些组件的依赖关系、层次关系以及相关信息。特定SBOM中包含的组件信息的数量和类型可能会根据行业、部门、SBOM消费者的需求等方面而有所不同。供应商商业软件发布者；合同约定的提供可交付软件的软件开发人员；免费开源软件供应商，在开源代码存储库中维护源代码以及在包管理器中维护二进制文件。根供应商作者组件SBOM的创建者，不一定是供应商。软件中不包含上游组件的供应商。由供应商或作者定义的软件单位。一个产品即一个组件，库、单个文件、组件的集合也是组件。上下游视角中，产品、中间产品、最终产品均可被视为组件。 6定义内涵随着SBOM研究的不断深入，其理论体系已基本搭建完成并通过行业实践不断完善，包含有供应商、作者、消费者等术语体系。消费者从供应商处获得第三方软件的商业或非商业实体。属性组件、SBOM的特征或相关信息，主要用于识别组件。包括基线属性和其他属性。SBOM条目SBOM条目指组件及其关联属性，在SBOM表中，一行即为一个条目。最小元素支持基础SBOM功能的必要部分：数据字段包括供应商、组件名称、组件版本、其它唯一标识符、依赖关系、SBOM数据作者以及时间戳等元素的信息结构。自动化支持通过自动生成和机器可读性来扩展至软件生态系统。实践流程定义SBOM 请求、生成和使用的操作，包括：频率、深度、已知的未知、分发和交付、访问控制和容错等。 701.总体介绍02. 价值与用例2.1 提高软件透明度的价值2.2 构建SBOM的价值2.3SBOM用例03.组成要素04.格式与工具05.生命周期06.常见问答07.知产与保密08.选择与决策09.行业实践10.发展趋势 82.1价值——提高软件透明度如果缺乏对软件系统组件和功能的全局可见性，将大大增加网络安全风险及软件开发、采购和维护的成本。随着全球互联程度日益增加，这些风险和成本不仅会影响到个人用户和相关组织，还会影响到公共安全和国家安全等集体利益。提高软件透明度的方法：提高识别易受攻击的软件组件的能力；减少因复杂上下游关系导致的计划外低效率的工作；对支持透明度的供应商予以支持；使用通用的标准化格式以减少重复性工作；协助识别可疑的或假冒的软件组件。意义降低网络安全风险提高信任度和可信度降低开发、采购和维护数字化基础设施的成本 92.2价值——SBOM可以识别已知漏洞并及时应对可以量化并管理许可证可以识别安全性，检查许可证的合规要求可以量化软件包中已存在的风险可以提高效率，降低工作量，从而降低运营成本SBOM对软件供应商和消费者的好处可以管理针对漏洞的缓解措施（包括对新漏洞的补丁与补偿控制）创建SBOM可以提高供应商自身竞争力软件生产者可以协助构建和维护其软件，包括知晓软件的上游组件成分及对应属性。软件运营者可以向漏洞管理和资产管理提供信息、管理许可证及产品合规性，并快速识别软件或组件的依赖关系与风险。软件购买者可以告知购买者关于预购买保证协议、协商折扣、或计划实施策略。 有助于用户理解软件生态系统。SBOM的应用场景 102.3价值——用例SBOM可以降低成本、减少安全风险、许可风险和合规风险。具体价值因生产、选择和操作软件的利益相关者而异。SBOM用例包括软件开发改进、漏洞管理、资产管理、采购管理和高可信流程。其中需要注意的是漏洞管理和VEX、知识产权和高可信流程三类用例。需要漏洞信息源（如CVE和NVD）需要漏洞到组件的映射（如NVD中使用的CPE）需要传达漏洞或可利用性状态的方法（如VEX）难点：基于有限信息（如版本字符串、协议标语或其他试探法）可能无法准确检测到漏洞漏洞管理和VEX分析漏洞的危险性和可利用性，即漏洞可用性交流（VEX）软件组件安全性检查流程分析开源组件输出SBOM分析漏洞使用工具：软件成分分析（SCA） 112.3价值——用例VEX主要用来判断有关产品是否受到特定漏洞的影响。如果产品受到影响，是否已建议采取补救措施，确定是否存在其他防护手段，保证此漏洞无法有效利用等。为减少用户在漏洞确认方面所花精力，厂商可以发布VEX，以判断漏洞的状态：•不受影响—无需对此漏洞进行补救；•受影响—建议采取措施来修复或解决此漏洞；•已修复—表示这些产品版本包含针对漏洞的修复；•调查中—尚不清楚这些产品版本是否受到漏洞影响。将在以后的版本中提供更新。软件包括一个漏洞组件；软件厂商发现，漏洞不会影响编译软件；•例如，有关代码没有包含在编译器里；•例如， 存在相关代码，但没有使用或暴露；厂商提交一个VEX，声明组件“不受影响”，不需要采取行动；客户把SBOM数据、漏洞数据、VEX数据集成到一起，做出基于风险的决策。 122.3价值——用例需要将不同的许可证和许可证类型与组件关联起来需要一种方法来评估由具有不同许可证的不同组件合成的组装商品的实际效果常见用例1：管理所包含组件的软件许可（包括对使用或重新分发的限制）常见用例2：跟踪授权（允许使用组件的副本或功能）许可管理需要需要有关组件的谱系和出处的信息有关信息包括但不限于：如何构建和打包组件、谁创建和修改了组件、组件的监管链需要相关组件、不同的关系类型和可能不同的供应商信息的附加属性。高可信流程SWIDSPDX传送许可证和授权信息确定组件内容以确定许可证要求软件组成分析工具二进制分析工具 1301.总体介绍02. 价值与用例03.组成要素3.1数据字段3.2自动化支持3.3实践流程04.格式与工具05.生命周期06.常见问答07.知产与保密08.选择与决策09.行业实践10.发展趋势 143.1组成要素——数据字段：基线属性SBOM的主要目的：唯一且明确地识别软件组件及其依赖关系。作者不一定是供应商；时间戳即SBOM最后一次更新的日期和时间；供应商名称也可为其标识符；组件名称由供应商或作者定义；建议使用语义版本控制版本字符串；组件哈希值是组件的固有标识符，可由数字签名代替；唯一标识符：CPE、URL(PURL)、UUID、SWHID和组件哈希值；默认的关系类型是包含（includes）SBOM基线属性作者姓名时间戳供应商姓名组件名称版本字符串唯一标识符关系组件哈希值生命周期其他组件关系许可证信息SBOM基线属性：SBOM系统的必要元素。 153.1组成要素——数据字段：其他属性除了基线信息，SBOM还会包含其他未确定属性、附加元素等其他信息。未确定属性原因•缺乏有关组件组成的第一手知识。当SBOM的作者不是软件组件的供应商时，作者可能缺乏生成某些属性所需的信息或可见性。•创建SBOM（和组件 ）的时间点不同，大致为：预构建、构建或打包时以及构建后。应对•总是提供所有的基线属性。但需明确定义区分“无断言（noassertation）”(即数据缺失)，和“没有值 （novalue）”(即该属性不适用于此特定的SBOM)•或者，SBOM格式可以允许缺少基线属性，并将缺失某几项属性视为默认值（例如“无断言”或“没有值”） 。附加元素和组件属性除了基线属性外，SBOM可能还需要附加元素和组件属性以支持不同的用例。并不是所有附加元素或属性都支持每个用例，所需的具体信息取决于用例的具体情况。以三大用例为例，附加元素和组件属性包括但不限于：•组件的使用寿命结束日期或技术支持结束日期；•显示组件实施或支持技术的能力；•对组件进行分组的机制；可能是通过生产线或已实现的技术进行分组（一组可以被视为一种特殊类型的上游组件）。 163.1组成要素——数据字段：SBOM格式除了基线属性之外，作者还应该遵守其选择的SBOM格式的规范。SBOM有三种格式，分别是：SPDX、CycloneDX和SWID。下表为将基线组件信息对应到现有格式属性SPDXCycloneDXSWID作者姓名Creator: metadata/authors/author <Entity> @role (tagCreator), @name 时间戳Created: metadata/timestamp<Meta>供应商名称PackageSupplier: Supplier publisher <Entity> @role (softwareCreator/publisher), @name 组件名称PackageName: name <softwareIdentity> @name 版本字符串PackageVersion: version <softwareIdentity> @version 组件哈希值PackageChecksum: PackageVerificationCode: Hash“alg” <Payload>/../<File> @[hash-algorithm]:hash 唯一标识符SPDX Document Namespace SPDXID: bom/serialNumbercomponent/bom-ref<softwareIdentity> @tagID关系Relationship: DESCRIBES CONTAINS(Inherent innested assembly/subassemblyand/or dependency graphs)<Link> @rel, @href 173.1组成要素——数据字段：组件关系理想情况下，每个供应商都将为其组件创建并提供SBOM，所有消费者都将获得这些权威SBOM的完整链。对于每个组件，作者姓名即供应商名称；当供应商未提供SBOM ，需要SBOM作者收集并提供相关信息时，作者可能想要对“作者不是供应商的组件”做出非权威的声明或断言。未知默认值。表示目前还没有任何关于上游组件的声明、知识或断言。可能当前的上游组件目前还未知，