软件物料清单实践指南（2023）

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