2024软件物料清单实践指南

2022024软件物料清单实践指南PAGEPAGE2总体介绍诞生背景代表工作定义内涵价值与用例组成要素格式与工具

生命周期常见问答知产与保密选择与决策行业实践发展趋势诞生背景诞生背景PAGEPAGE3NTIASoftwareComponent医疗保健概念验证工作组格式和工具工作组意识和采用工作组框架工作组2018NTIASoftwareComponent医疗保健概念验证工作组格式和工具工作组意识和采用工作组框架工作组2018年7月19日，美国国家电信和信息管理局（NTIA）召开了多部门利益相关者会议，讨论增强软件透明度的一项提案，目的是建立一个通用框架，以在软件产品中描述组件。工作重点定义和完善SBOM规范，推动广泛、可扩展的采用NTIA多利益相关方流程计划将SBOMNTIA多利益相关方流程计划格式构建信息共享格式构建信息共享促进实践所有行业支持活动证明SBOM的成功应用，为其他行业提供参考代表工作代表工作自SBOM诞生以来，美西方多个组织机构积极开展研究，多个行业已开始推进SBOM的应用，使得SBOM理论发展不断完善，并开始在实践中丰富内涵。自SBOM诞生以来，美西方多个组织机构积极开展研究，多个行业已开始推进SBOM的应用，使得SBOM理论发展不断完善，并开始在实践中丰富内涵。ISO/IEC5230:2020，高质量开源许可证合规2022.2，NIST《安全软件开发框架》2020.11，ENISA确保物联网安全的准则20192019联 盟安全软件框架2020.7，大西洋理事会 “BreakingTrust”报告20212019.1，JSP— —联合安全计划20202022《现代车辆安全的网络安全最佳实践》2020，美国国家公路交通安全管理局2019.3，MUD，制造商使用说明2018、2021，MITRE“交付无碍”项目2022.4，FDA售前准则中心《使用SBOM增强网络安全》2021.1，荷兰政府的国家网络安全CISQ《可信系统宣言》 组件分析项目 中心《使用SBOM增强网络安全》2021.1，荷兰政府的国家网络安全定义内涵定义内涵随着SBOM研究的不断深入，其理论体系已基本搭建完成并通过行业实践不断完善，包含有供应商、作者、消费者等术语体系。随着SBOM研究的不断深入，其理论体系已基本搭建完成并通过行业实践不断完善，包含有供应商、作者、消费者等术语体系。SBOM是一份正式规范且机器可读的软件组件清单，清单中包含这些组件的依赖关系、层次关系以及相关信息。特定SBOM中包含的组件信息的数量和类型可能会根据行业、部门、SBOM消费者的需求等方面而有所不同。SBOMSBOM是一份正式规范且机器可读的软件组件清单，清单中包含这些组件的依赖关系、层次关系以及相关信息。特定SBOM中包含的组件信息的数量和类型可能会根据行业、部门、SBOM消费者的需求等方面而有所不同。SBOM商业软件发布者；合同约定的提供可交付软件的软件开发人员；免费开源软件供应商，在开源代码存储库中维护源代码以及在包管理器中维护二进制文件。商业软件发布者；合同约定的提供可交付软件的软件开发人员；免费开源软件供应商，在开源代码存储库中维护源代码以及在包管理器中维护二进制文件。组件

根供应商 由供应商或作者定义的软件单位。一个产品即一个组件，库、单个文件、组件的集合也是组件。上下游视角中，产品、中间产品、最终产品均可被视为组件。软件中不包含上游组件的供应商。作者 由供应商或作者定义的软件单位。一个产品即一个组件，库、单个文件、组件的集合也是组件。上下游视角中，产品、中间产品、最终产品均可被视为组件。软件中不包含上游组件的供应商。SBOM的创建者，不一定是供应商。SBOM的创建者，不一定是供应商。定义内涵定义内涵PAGEPAGE6随着SBOM研究的不断深入，其理论体系已基本搭建完成并通过行业实践不断完善，包含有供应商、作者、消费者等术语体系。随着SBOM研究的不断深入，其理论体系已基本搭建完成并通过行业实践不断完善，包含有供应商、作者、消费者等术语体系。消费者 最小元素 从供应商处获得第三方软件的商业或非商业实体。从供应商处获得第三方软件的商业或非商业实体。支持基础SBOM功能的必要部分：数据字段支持基础SBOM功能的必要部分：数据字段依赖关系、SBOM数据作者以及时间戳等元素的信息结构。自动化支持通过自动生成和机器可读性来扩展至软件生态系统。实践流程定义SBOM请求、生成和使用的操作，包括：频率、组件、组件、SBOM的特征或相关信息，主要用于识别组件。包括基线属性和其他属性。SBOM条目指组件及其关联属性，在SBOM表中，一行即为一个条目。SBOM条目指组件及其关联属性，在SBOM表中，一行即为一个条目。PAGEPAGE9总体介绍价值与用例构建SBOM的价值SBOM用例组成要素格式与工具

生命周期常见问答知产与保密选择与决策行业实践发展趋势PAGEPAGE8价值——提高软件透明度如果缺乏对软件系统组件和功能的全局可见性，将大大增加网络安全风险及软件开发、采购和维护的成本。随着全球互联程度日益增加，这些风险和成本不仅会影响到个人用户和相关组织，还会影响到公共安全和国家安全等集体利益。意义降低网络安全风险意义降低网络安全风险降低开发、采购和维护数字化基础设施的成本减少因复杂上下游关系导致的计划外低效率的工作；PAGEPAGE9可以识别已知漏洞并及时应对价值——SBOM可以识别已知漏洞并及时应对软件生产者可以协助构建和维护其软件，包括知晓软件的上游组件成分及对应属性。可以量化并管理许可证可以管理针对漏洞的缓解措施（包括对新漏洞的补丁与补偿控制）的应用场景SBOM软件生产者可以协助构建和维护其软件，包括知晓软件的上游组件成分及对应属性。可以量化并管理许可证可以管理针对漏洞的缓解措施（包括对新漏洞的补丁与补偿控制）的应用场景SBOM对软件供应商和消费者的好处软件购买者可以告知购买者关于预购买保证协议、协商折扣、或计划实施策略。有助于用户理解软件生态系统。可以量化软件包中已存在的风险可以提高效率，降低工作量，从而降低运营成本可以识别安全性，检查许可证的合规要求软件购买者可以告知购买者关于预购买保证协议、协商折扣、或计划实施策略。有助于用户理解软件生态系统。可以量化软件包中已存在的风险可以提高效率，降低工作量，从而降低运营成本可以识别安全性，检查许可证的合规要求创建创建SBOM可以提高供应商自身竞争力2.3价值——用例2.3价值——用例PAGEPAGE10SBOMSBOMSBOMVEX三类用例。漏洞管理和VEX漏洞管理和VEX需要漏洞信息源（如CVE和NVD）需要漏洞到组件的映射（如NVD中使用的CPE）需要传达漏洞或可利用性状态的方法（如VEX）难点：基于有限信息（如版本字符串、协议标语或其他试探法）可能无法准确检测到漏洞使用工具：软件成分分析（使用工具：软件成分分析（SCA）分析漏洞的危险性和可利用性，即漏洞可用性交流（VEX）分析开源组件分析开源组件输出SBOM分析漏洞VEX主要用来判断有关产品是否受到特定漏洞的影响。如果产品受到影响，是否已建议采取补救措施，确定是否存在其他防护手段，保证此漏洞无法有效利用等。：软件包括一个漏洞组件；软件厂商发现，漏洞不会影响编译软件；例如，有关代码没有包含在编译器里；例如，存在相关代码，但没有使用或暴露；：软件包括一个漏洞组件；软件厂商发现，漏洞不会影响编译软件；例如，有关代码没有包含在编译器里；例如，存在相关代码，但没有使用或暴露；厂商提交一个VEX，声明组件“不受影响”，不需要采取行动；客户把SBOM数据、漏洞数据、VEX数据集成到一起，做出基于风险的决策。不受影响—无需对此漏洞进行补救；受影响—建议采取措施来修复或解决此漏洞；已修复—表示这些产品版本包含针对漏洞的修复；调查中—尚不清楚这些产品版本是否受到漏洞影响。将在以后的版本中提供更新。2.3价值——用例2.3价值——用例传送传送许可证和授权信息许可管理需要将不同的许可证和许可证类型与组件关许可管理需要将不同的许可证和许可证类型与组件关联起来 需要一种方法来评估由具有不同许可证的不同组件合成的组装商品的实际效果常见用例2：跟踪授权（允许使用组件的副本或功能）常见用例1：管理所包含组件的软件许可（包括对使用或重新分发的限制）高可信流程需要需要有关组件的谱系和出处的信息 有关信息包括但不限于：如何构建和打包组件、谁创建和修改了组件、组件的监管链需要相关组件、不同的关系类型和可能不同的供应商信息的附加属性。二进制分析工具确定组件内容以确定许可证要求软件组成分析工具二进制分析工具确定组件内容以确定许可证要求软件组成分析工具SWIDSPDX总体介绍价值与用例组成要素数据字段实践流程格式与工具

生命周期常见问答知产与保密选择与决策行业实践发展趋势133.1组成要素——数据字段：基线属性3.1组成要素——数据字段：基线属性SBOMSBOM基线属性：SBOM系统的必要元素。作者许可证信息姓名时间戳其他组件关系姓名生命周期SBOM基线属性组件名称组件版本关系唯一SBOM的主要目的：唯一且明确地识别软件组件及其依赖关系。作者不一定是供应商；时间戳即SBOM最后一次更新的日期和时间；供应商名称也可为其标识符；组件名称由供应商或作者定义；建议使用语义版本控制版本字符串；组件哈希值是组件的固有标识符，可由数字签名代替；和组件14唯一标识符和组件14默认的关系类型是包含（includes）3.1组成要素——数据字段：其他属性3.1组成要素——数据字段：其他属性PAGEPAGE15原因缺乏有关组件组成的第一手知识。原因缺乏有关组件组成的第一手知识。当SBOM的作者不是软件组件的供应商时，作者可能缺乏生成某些属性所需的信息或可见性。创建SBOM（和组件）的时间点不同，大致为：预构建、构建或打包时以及构建后。应对总是提供所有的基线属性。但需明确定义区分“无断言（no assertation）”(即数据缺失)，和“没有值（novalue）”SBOM)或者，SBOM格式可以允许缺少基线属性，并将缺失某几项属性视为默认值（）。除了基线属性外，SBOM可能还需要附加元素和组件属性以三大用例为例，和对组件进行分组的机制；可能是通过生产线或已实现的技术进行分组（）。除了基线信息，除了基线信息，SBOM还会包含其他未确定属性、附加元素等其他信息。附加元素和组件属性未确定属性PAGEPAGE16组成要素——数据字段：SBOM格式除了基线属性之外，作者还应该遵守其选择的除了基线属性之外，作者还应该遵守其选择的SBOM格式的规范。SBOM有三种格式，分别是：SPDX、CycloneDX和SWID。下表为将基线组件信息对应到现有格式属性SPDXCycloneDXSWID作者姓名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/ordependencygraphs)<Link>@rel,@href3.1组成要素——数据字段：组件关系3.1组成要素——数据字段：组件关系PAGEPAGE17开发开发SBOM组件中的一级组件。SBOM知的嵌套关系。基线关系属性定义了一种单一类型的关系：包含（或包含于）。上游组件（通常称为依赖项）包含在下游组件中。有的SBOM格式支持不同类型的关系。SBOMSBOM当供应商未提供SBOM，需要SBOM关系断言属性关系断言属性未知无 表示没有直接的上游关。根据供应商的定义，该组件没有上游组件。表示至少有一个直接的上游关系；可能是也可能不是其他关系。已知关系会列出来。已知 表示已知并列出了完整直接游关集。部分已知SBOM概念图SBOM概念图下面提供一个下面提供一个SBOM示例来进一步说明上一节中描述的关系。SBOM概念图组件名称供应商组件名称供应商名称版本字符串作者哈希值UID关系ApplicationAcme1.1Acme0x123234主要|--BrowserBob2.1Bob0x223334包含于|--CompressionEngineCarol3.1Acme0x323434包含于|--BufferBingo2.2Acme0x423534包含于组件名称供应商名称版本字符串作者哈希值UID关系关系断言ApplicationAcme1.1Acme0x123234主要已知|--BrowserBob2.1Bob0x223334包含于部分已知|--CompressionEngineCarol3.1Acme0x323434包含于无|--BufferBingo2.2Acme0x423534包含于未知3.2组成要素——自动化支持3.2组成要素——自动化支持PAGEPAGE19国际参与公开制定国际参与公开制定通用句法机器可读人类可读互操作性自动化支持包括自动化生成和机器可读性，允许跨软件生态系统进行扩展，特别是跨组织边界。使用SBOM数据则需要使用可预测的实现工具和数据格式。用于生成并使用用于生成并使用的数据格式SWID（SoftwareIdentification）CycloneDXSPDX（SoftwarePackageDataeXchange）某些机构希望将SBOM有的漏洞管理实践中；策略的合规性。当出现可与现有格式兼容的新标到主动维护，则将其剔除。3.3组成要素——实践流程3.3组成要素——实践流程SBOM不仅是结构性数据集；在将其集成到安全开发生命周期时，组织机构应遵循SBOM使用机制的实践流程。在任何要求提供SBOM的策略、合同或约定中，都应当明确提出多个元素。频率当软件组件以新版本或发布的形式更新，那么必须创建新的SBOM来体现该软件的新版本。其中包括集成已更新组件或依赖项的软件版本。深度SBOM应当包含所有主要（顶层）组件，并列出其中包含的所有传递依赖项。

已知的未知对于在SBOM中未列举出完整依赖项的实例，SBOM作者必须明确识别出“已知的未知“。即明确区分不含其它依赖项的组件和所含依赖项未知及不完整的组件。参见关系断言。分发和交付及时地向所需方提供SBOM，并设置恰当的访问权限。共享SBOM数据可分为：如何获悉SBOM的存在和可用性（宣传或发现）；SBOM是如何被具有权限（访问）的人员检索或获得。

访问控制 必须指定相关术语，包括将SBOM数据集成到用户安全工具中的费用和空间。可通过许可、合约或其它现有机制来约束软件本身的使用和权益。 容错空间 SBOM客户应当明确容忍偶然的无心之过，允许遗漏和错误，以此鼓励SBOM数据更新。 20总体介绍价值与用例组成要素格式与工具SWID

生命周期常见问答知产与保密选择与决策行业实践发展趋势21概述概述当前，国际上较为流行的SBOM格式共3种，SPDX当前，国际上较为流行的SBOM格式共3种，SPDXSWIDSPDXSPDXSPDXSPDX是一个由Linux开源项目。软件、系统和工具的供应商、集成商，基金会等代表参与。工作由三个小组完成：技术团队、法律团队和外展团队。2012年由ISO定义并在2015年被更新为 ISO/IEC19770-2:2015。SWID标签文件包含有关软件产品特定版本的描述性信息。CycloneDX是一种轻量级SBOM格式，由CycloneDXCore管理，起源于\h社区。224.1SPDX概述4.1SPDX概述2010年，SPDX格式发布1.0版本，于2021年8月成为国际标准（ISO/IEC5962:2021），支持在软件开发的过程中自动生成，目前已有5种文档格式，支持4种语言，设有许可证表达式。2010年，SPDX格式发布1.0版本，于2021年8月成为国际标准（ISO/IEC5962:2021），支持在软件开发的过程中自动生成，目前已有5种文档格式，支持4种语言，设有许可证表达式。支持CI/CD集成以生成SPDX文档为 Maven构建环境自支持CI/CD集成以生成SPDX文档为 Maven动 生 成SPDX文档 234.1SPDX的广泛使用4.1SPDX的广泛使用英特尔、微软、西门子、索尼、新思科技、英特尔、微软、西门子、索尼、新思科技、VMware和WindRiver在内的众多公司已经使用SPDX传达SBOM信息，以确保全球软件实现合规和安全开发。ocuenae:PX-Toov.0SPDXID:SPDXRef-DOCUMENTDocumentComment:<text>Thisdocumentwas

Creator:Organization:ExampleCodeInspect()Creator:Person:JaneDoe()Created:2010-01-29T18:30:22ZCreatorComment:<text>ThiscreatedusingSPDX2.0usingpackagehasbeenshippedinlicensesfromthewebsite.</text>##ExternalDocumentReferencesExternalDocumentRef:ocuenedoo.2##CreationInformationCreaor:Too:LceneFnd-1.0

sourceandbinaryform.LicenseListVersion:1.19##AnnotationsAnnotator:Person:JaneDoe()AnnotationDate:2010-01-29T18:30:22ZAnnotationComment:<text>Documentlevel 244.1SPDX优势与工具4.1SPDX优势与工具将许可证与SPDX许可证列表中包含的许可证进行匹配语言使用语言使用变换查看对比检索导入转换合并支持JavapythongolangJavaScript25用于表示发行版光盘映像文件、容器、软件包、二进制文件、源文件、补丁、嵌入在其他文件中的代码片段能够对与复杂系统相关的文档进行逻辑划分和链接4.24.2概述PAGEPAGE26起源于OWASP社区，CycloneDX是一种轻量级SBOM格式，于2021年成为第三种通用格式纳入NTIA文件中，侧重于网络安全风险管理，尤其适用于依赖服务的现代软件。4.24.2工具与特点PAGEPAGE27支持硬件作为组件可与VEXCDXCPE、SWID和PURL识别可用于描述微服务架构、面向服务的架构（SOA）、功能即服务、n层架构、演员模型、系统的系统等服务结合SPDX许可证ID和表达式可装配组件SBOM，支持SBOM可表示组件谱系4.3SWID概述4.3SWID概述PAGEPAGE28识别和描述已安装补丁，该补丁对软件产品进行增量更改。识别和描述已安装补丁，该补丁对软件产品进行增量更改。软件识别（SWID）标签旨在为组织提供一种方式来跟踪其软件，2012年由ISO给出定义，并在补丁标签SWID标签补丁标签SWID标签在软件产品安装过程中被添加到终端，并在软件产品卸载时同步删除。在此生命周期中，给定SWID标签的存在直接对应于该标签描述的软件产品的存在。主标签识别和描述软件产品，安装在计算设备上。主标签识别和描述软件产品，安装在计算设备上。语料库标签识别和描述处于预安装状态的可安装软件产品。补充标签为其他语料库标签识别和描述处于预安装状态的可安装软件产品。补充标签为其他SWID标签提供附加信息。4.3SWID与软件生命周期4.3SWID与软件生命周期PAGEPAGE29SWID定义的四种标签类型基于软件的生命周期，标签可以定义产品名称、版本和其他详细信息，标签可以明确地链接到其他标签来表示依赖关系。SWID定义的四种标签类型基于软件的生命周期，标签可以定义产品名称、版本和其他详细信息，标签可以明确地链接到其他标签来表示依赖关系。构建组件时自动生成加密哈希实现软件相关信息关联，包括补丁、更新、配置设置、漏洞等构建组件时自动生成加密哈希实现软件相关信息关联，包括补丁、更新、配置设置、漏洞等未来发展方向未来发展方向PAGEPAGE30●●需要时，指明创建SPDX时的已知漏洞，以及这些漏洞何时/何地/如何在更新或补丁中被修复，或被确定在交付软件中不可利用●增强谱系和上下游关系的表示，以支持监管链●●更丰富的交互间关系集与完整性检查识别当前无法由SPDX表示的用例，并在即将发布的规范中添加元素以支持这些用例 纳入社区和CycloneDX纳入社区和CycloneDX行业工作组的反馈，以指导该格式标准的未来方向目前正在开发多个扩展对现有漏洞扩展的审计、制定和增强通过每年发布的版本不断完善核心规范IETF正在对一种更轻量级的表示法CoSWID进行标准化，这是一种基于简明二进制对象表示法的SWID标签信息，用来支持受限的物联网用例01.总体介绍5.3使用SBOM02.价值与用例5.4验证SBOM01.总体介绍5.3使用SBOM02.价值与用例5.4验证SBOM03.组成要素06.常见问答04.格式与工具07.知产与保密05.生命周期08.选择与决策5.1生成SBOM09.行业实践5.2交付SBOM10.发展趋势SBOM生命周期可分为4个阶段，存在于软件生命周期中的开发、部署和运行阶段，有所相关又有所不同。SBOM生命周期可分为4个阶段，存在于软件生命周期中的开发、部署和运行阶段，有所相关又有所不同。生成SBOM阶段。生成SBOM

使用SBOM SBOM纳入公司全流程的方式，监测漏洞，机密性要求一般存在于运维阶段。交付SBOM

发现阶段。

验证SBOM

软件实体解析依赖项解析完整性真实性一般存在于软件交付、运维阶段。325.1生成——流程与阶段5.1生成——流程与阶段SBOM的生成包括生成流程、方式与阶段，不同的场景下，组织可以通过多样、自动化的工具，在软件开发生命周期的不同阶段生成SBOM，并通过源代码或二进制文件的方式交付。SBOM的生成包括生成流程、方式与阶段，不同的场景下，组织可以通过多样、自动化的工具，在软件开发生命周期的不同阶段生成SBOM，并通过源代码或二进制文件的方式交付。一般性工作流程模型生成阶段——构建前（源码级SBOM）适用：对保障性和安全性要求高。生成方法：作为版本控制系统一部分，或由挖掘产品构建管道输入的工具创建源码级SBOM。特点：生成阶段——构建前（源码级SBOM）适用：对保障性和安全性要求高。生成方法：作为版本控制系统一部分，或由挖掘产品构建管道输入的工具创建源码级SBOM。特点：有助于关键组件的识别及在创建产品之前查找漏洞；便于构建到源文件的追溯；可能会呈现并不包含在最终可执行文件中的脆弱源码。获取可交付软件中的组件数据 将组件数据导入结构化的SBOM将组件数据导入结构化的SBOM格式验证SBOM以确保格式有效且包含“基线”属性验证SBOM以确保格式有效且包含“基线”属性5.1生成——阶段5.1生成——阶段“构建前”的源码级SBOM目前在实践中采用较少，“构建时”和“构建后”已大量应用于行业实践，且开始适应软件容器化交付。“构建前”的源码级SBOM目前在实践中采用较少，“构建时”和“构建后”已大量应用于行业实践，且开始适应软件容器化交付。生成阶段——构建时生成阶段——构建时自动化生成需确定构建过程中生成的的格式自动化生成需确定构建过程中生成的的格式件特征无人工输入错误自动化签名可审计性强构建管道/工厂中生成需要额外的资源集成管道构建管道方法易用性高软件工厂方法可解决多开发系统的SBOM一致性问题生成应汇总并识别来自所有层的所有软件的信息应包括容器间依赖关系、构建时间、签名等生成阶段——构建后适用：非自动化生成方式生成方法：填写接近工程过程的组件数据；填写已知的未知情况、统一标识符等；使用代码分析工具可扫描上游供应商组件的SBOM特点：商业组件识别能力不足；5.1生成——组件范围5.1生成——组件范围PAGEPAGE35无论SBOM生成的阶段、软件交付的方式如何，SBOM中组件的范围都是相同的，在SBOM中应当明确“已知的已知”和“已知的未知”。具体内容软件物料清单中的组件范围其他外部服务调用软件物料清单中的组件范围其他外部服务调用依赖项软件本身的组件运行时依赖项、操作系统、动态链接库、更新程序、共享库、安装程序部署的其他软件、安装程序本身应用程序调用Internet服务、自动更新服务创建软件的工具

非基线要外部服务调用枚举可以简化动态测试，解决网络检测警报问题，可以合理化网络权限建立。求，尚在外部服务调用枚举可以简化动态测试，解决网络检测警报问题，可以合理化网络权限建立。发展中。最佳实践需标注清楚是否已含 在SBOM中。5.1生成——责任分配5.1生成——责任分配PAGEPAGE36在宏观经济意义上，SBOM的使用对社会各方具有广泛效益，供应商是拥有其组件的高质量权威信息，并且生成和共享这些信息的成本相对较低，对生成SBOM负有主要责任。外部效应：一项经济活动对非当事人的第三者所产生的影响具有正向/负向效应是，经济活动主体将不会承担全部成本或占有全部收益。科斯定理：即最低成本法则，所有理性的选择最终都会选择成本最低的那一个选项。5.2交付——流程5.2交付——流程PAGEPAGE37SBOM的交付主要通过点对点的方式，从供应商到消费者进行传递。供应商交付SBOM需要特定的流程，以在正确的时间将SBOM数据传输给正确的人。SBOM的交付主要通过点对点的方式，从供应商到消费者进行传递。供应商交付SBOM需要特定的流程，以在正确的时间将SBOM数据传输给正确的人。供应商共享“宣传”消费者获取“发现供应商共享“宣传”消费者获取“发现”供应商传输/访问SBOM消费者获取SBOM“宣传”是作者告知消费者如何访问SBOM的机制，消费者要么通过一个常用存储地址访问，要么通过某种形式的公告；“发现”是指消费者了解SBOM位置的方式，由消费者使用，用于了解SBOM的存在以及如何访问它的机制。它的一个重要目标就是自动化发现SBOM；“访问”是指使用“发现”的方法连接到SBOM。5.2交付——共享方式5.2交付——共享方式PAGEPAGE38为适应各种软件和设备生态系统的多样性，行业内也设计出现了多种SBOM共享机制。为适应各种软件和设备生态系统的多样性，行业内也设计出现了多种SBOM共享机制。URL当SBOM被用于操作部署时，它可能会作为一个URL被包含在产品资料或产品包装中，或者作为制造商使用说明(MUD)的一部分。SBOM可以在搜索引擎中被搜索到，也可以通过一个公开的URL从设备本身检索到。共享SBOM示共享SBOM示例当下游开发人员使用SBOM时，软件包可能会包含一份写清楚SBOM具体地址的清单。软件包管理工具和容器也有关于清单信息地址的指南。用来说明许可要求和包装内容。发布/订阅系统另一种共享SBOM的方法是通过发布或订阅系统。这种情况下，消费者可通过订阅供应商的服务来获取即将发布的更新。5.2交付——传输机制5.2交付——传输机制访问是指用“发现”的方法传输SBOM。这个过程首先是要检索SBOM的位置和访问方法。根据SBOM所在的位置，可以将传输机制进行简单划分，但不同的机制并不是相互排斥的。此方法适用于制造商拥有 01SBOM，但缺乏自动化基础设施共享它。

通过电子邮件或类似的“外带”机制将SBOM直接提供给接收方

SBOM储存在运行软件的设备上02当SBOM备上时，可以使用多个协议中的某一个进行检索。SBOM储存在运行软件的设备上0203SBOM储存在软件消费者自有的存储库中SBOM可以被发布到公共或私人网站、数据库、或其他可供软件消费者使用的共03SBOM储存在软件消费者自有的存储库中享存储库中。 395.3使用SBOM—归档存储5.3使用SBOM—归档存储获取到SBOM之后，具体使用场景分为获取到SBOM之后，具体使用场景分为将SBOM数据汇入工作流程和归档储存SBOM文件。将SBOM数据汇入工作流程SBOM的最佳实践将SBOM数据汇入工作流程SBOM的最佳实践是数据汇入企业工作流程，包括采购、资产管理、漏洞管理以及总体风险管理和合规管理。在这种情况下，SBOM作为一个可以解析、提取和加载(ETL)到自动化进程或系统中的数据集，比作为一个独立的文件更加有用。

内部开发的工具（如脚本）使用Python脚本等方法从指定的SBOM字段中提取数据并将其加载到外部数据平台和工作流程中。从SBOM中提取数据开源软件工具开源的包或依赖管理系统提供相应的工具；用于生成列表甚至依赖树的命令。商业工具供应商管理平台、配置管理系统、软件保障平台和软件资产管理系统。405.3使用SBOM—持续检测漏洞5.3使用SBOM—持续检测漏洞各SBOM的最大价值来源之一是：不论供应商在管理何种漏洞，终端用户都能够同步监控漏洞。我们称之为SBOM“信任但验证”的能力。供应商检测漏洞所需的时间

这对于如果漏洞检测是作为软件开发管道中静态分析的一部分，并且软件并不是每天都信任但验证 从检测到漏洞到供应商修复漏洞所需的时间如果供应商知道存在严重漏洞并正在努力修复，但信任但验证从检测到漏洞到供应商修复漏洞所需的时间如果供应商知道存在严重漏洞并正在努力修复，但没有通知消费者这些漏洞存在，供应商发布修复更新所需的时间。供应商发布修复更新所需的时间。在没有SBOM或信息披露通知的情况下，消费者无法在发布修正更新之前实施补5.3使用SBOM—持续检测漏洞5.3使用SBOM—持续检测漏洞PAGEPAGE42各SBOM之间的最大区别和最大价值来源之一是：不论供应商在管理何种漏洞，终端用户都能够同步监控漏洞。优点这种的能力可以持续监控供应商软件依赖项的漏洞状态，通过缩小消除态势感知方面的差距生成保障连续性。对SBOM组件并行监控或带外监控各SBOM之间的最大区别和最大价值来源之一是：不论供应商在管理何种漏洞，终端用户都能够同步监控漏洞。优点这种的能力可以持续监控供应商软件依赖项的漏洞状态，通过缩小消除态势感知方面的差距生成保障连续性。对SBOM组件并行监控或带外监控为消费者创建了态势感知，并提高了供应商对易受攻击组件进行安全补救的透明度。供应商负责任的供应商可能会在不删除易受攻击依赖项的同时，采取一些步骤修复其中的安全问题。比如通过限制函数调用或删除子组件修复。消费者消费者须承认和接受VEX文件中列举的有效补救措施，而不是要求一个“干净扫描”，不包含任何CVE。5.3使用SBOM—机密性要求5.3使用SBOM—机密性要求PAGEPAGE43消费者是中间供应商消费者是中间供应商SBOMSBOMSBOM不论SBOM是由供应商或开源社区或其他作者生成或提供，其许可状态都应该明确化，最好在不论SBOM是由供应商或开源社区或其他作者生成或提供，其许可状态都应该明确化，最好在SBOM内部列举。供应商和承包商的软件交付物适用于SBOM供应商和承包商的软件交付物适用于SBOMSBOMSBOMSBOM。开源软件供应商提供的SBOM一部分，此类SBOM5.4验证SBOM-完整性与真实性5.4验证SBOM-完整性与真实性PAGEPAGE44SBOM用户可能会考虑验证SBOMSBOM用户可能会考虑验证SBOM数据的来源并确保其未被修改。软件的完整性和真实性通常是通过签名和公钥基础设施来支持的。鼓励供应和请求SBOM的用户探索签署SBOM和验证篡改检测。——这类机制应允许签名既定软件的每个组件，并允许用户判断签名是否合法。完整性和真实性是很多政府机构的优先考虑事项，尤其是在国家安全领域。SBOM信息越完整，能提供的价值就越大。SBOM信息的真实性更是用户和监管部门关注的重点。SBOM信息越完整，能提供的价值就越大。SBOM信息的真实性更是用户和监管部门关注的重点。正在进行的开源工作致力于解决开发环境中遇到的签名元数据优先级的问题。在今天，某些SBOM数据用户可能还会坚持要求获取SBOM正在进行的开源工作致力于解决开发环境中遇到的签名元数据优先级的问题。在今天，某些SBOM数据用户可能还会坚持要求获取SBOM5.4验证SBOM—软件实体解析5.4验证SBOM—软件实体解析SBOM验证包括格式验证和组件验证，常用的验证方法是软件实体解析，其执行方法和名称分配方法依具体情景和使用方法而异，用于证明SBOM的完整性和真实性。软件实体解析执行方法

通过查找的方式手动执行使用脚本和人工判断的组合自动执行由甲方自有的或获得商业许可的软件实体解析引擎自动执行

使用别名或伪标识符手动分配名称使用别名或伪标识符自动分配名称在没有权威的外部标识符的情况下，利用供应商和组件级别的实体解析来制定组件名称

软件实体解析名称分配在可能的情况下指定供应商的组件在包括这些许可组件的软件产品中命名一致。在可能的情况下

如果使用商业SWID在发行版、服务包和补丁的命名上不同于开源组件。相同版本的商业软件可能在其组成和安全配置文件方面存在显著不同，如果使用商业SWID在发行版、服务包和补丁的命名上不同于开源组件。455.4验证SBOM—软件实体解析5.4验证SBOM—软件实体解析PAGEPAGE46完整的软件实体解析还包括对软件组件依赖关系的解析，即软件依赖项解析。完整的软件实体解析还包括对软件组件依赖关系的解析，即软件依赖项解析。传递性依赖解析如果SBOM仅仅提供直接软件依赖，完整传递性依赖解析如果SBOM仅仅提供直接软件依赖，完整的软件实体解析需要解析那些直接依赖关系，以对软件交付物中所有传递依赖项进行分类。因为易受攻击的往往是传递依赖项，而且映射不是最新，也是不完整的。传递依赖项解析可使用开源工具或决方案来实现。软件类别的监管需求供的。除包括一个或多个由容器交付的软件的SBOM外还应以容器作为顶级清单，提供容器中所有组件的SBOM。定性的风险接受程度应该是“已知的未知”，并且可信需求的软件功能监管链需求。PAGEPAGE47总体介绍价值与用例组成要素格式与工具生命周期常见问答SBOM

SBOMSBOM的创建及维护SBOM的分发与分享与SBOM知产与保密选择与决策行业实践发展趋势6.1SBOM6.1SBOM的优势SBOMSBOM优势体现在很多应用场景，例如，网络攻击事件应答、漏洞管理及其他行业等。发生网络攻击事件时，SBOM可以提供什么帮助？答：当某个组件存在缺陷或漏洞时，SBOM可以快速识别受漏洞组件影响的软件，评估其使用情况，并推断由此带来的风险。这使供应商能够发布补丁或提供其他补救方案；使消费者能够从供应商处自行选择对应的缓解措施。SBOM还能识别不受影响的软件，这样就能把重点放在可能受影响的软件上。漏洞管理，SBOM还能什么？ 答：SBOM使组织中从采购者到运营者都能清晰认识软件的情况。SBOM提高可视性和问责制的优点可以为用户带来更多的业务优势，如资产整合、许可认定、审查新政策和法规的影响以及及时应对不断变化的商业环境。物料清单和透明度在其他方面还有什么帮助？答：物料清单对汽车业、食品业和传统制造业的行业改革都有助力作用。其中许多原则由丰田公司在20世纪40年代开创，并在越来越多的行业中持续改进。早在2013年，金融业就已经开始尝试实现软件上下游透明度。SBOM划承将经验证原则用于代软开发。 486.2SBOM6.2SBOM的常见误解与事实随着随着SBOM越来越广泛地应用到开放性行业（例如金融服务和医疗保健），由此产生的网络效应放大了SBOM提供的初始固定收益。由此产生了一些误解和担忧，这里给出部分问题的解答。SBOM会为黑客攻击指明方向？事实：SBOM确实会给恶意人员提供一些信息，节约了恶意人员收集信息的时间，但是SBOM带给防御方的好处远远超过它带来的问题。SBOM在企业范围内提供额外的透明度和标准的、机器可读的决策支持，为防御方提供了公平的竞争环境。SBOM无法提供有用的信息？ 事实：基线组件信息为生产、选择和操作软件的人员提供了许多示例。在被攻击的阶段，SBOM可以帮助企业在短时间内了解他们是否被影响了，什么地方被影响了。基线组件信息提供了重要的透明度和可审计性。SBOM是否需要公开源代码？事实：不需要。专有源代码仍然属于版权所有者，版权所有者可以自行决定共享或保密。因此不必担心因暴露代码而导致可能操作内部信息，这些软件组件只是“拼图的碎片”，完全不能近似指代某个软件程序的“完整拼图。 496.2SBOM6.2SBOM的常见误解与事实SBOM是否会暴露企业的知识产权/商业机密？事实：SBOM只是包含的软件组件的清单，不会公开知识产权(IP)，也不会披露专利和算法实现。SBOM内容和IP之间的关系：1、类似于食品成分表和配方，SBOM和软件著作权是有区别的。2、第三方开源组件的IP属于其各自的作者或版权所有者。3、要求披露组件许可条款的情况已经越来越普遍。4、SBOM中不包含代码，只包含组件引用。5、合同、法律协议或其他要求可能禁止披露某些组件。SBOM是否会增加软件的许可证违规风险？事实：不会。只要存在被许可的软件，就会产生相应的许可义务，这些义务与SBOM无关。SBOM提供了在其他方面可能会被隐藏的软件清单。因此，SBOM曝光了潜在的许可证违规行为，促使人们有意识地减少此类违规行为。不存在支持SBOM扩展性的生产和使用流程？事实：由于行业活动的融合，商业和开源工具的列表正在不断增加。随着跨部门采用率的提高，流程和集成也在共同发展。SBOM机器可读性的提高进一步实现了SBOM的可扩展性。所有这些发展和创新的结合为SBOM的大规模实施提供了许多选择。SBOM会增加软件许可成本或授权承诺吗？事实：不会。通过创建SBOM所获得的软件信息允许制造商解决可能潜伏在软件程序中的未知许可承诺。这允许制造商通过授权费或获取更有利的许可条款来解决这些问题，从而避免罚款、诉讼和许可承诺，以防暴露软件持者的有代。 506.3SBOM6.3SBOM的创建及维护SBOMSBOM流程中涉及到创建和维护环节的责任者和时间，以及SBOM列举的组件依赖关系程度。创建和维护SBOM？ 答：SBOM由软件生产商负责创建并维护。“生产商”包括制造商、供应商和个人作者。理想情况下，生产商应将其供应商提供的SBOM整合起来；在没有SBOM数据的情况下，生产商可能必须为某些组件生成SBOM数据。、更改或维护SBOM？ 答：组件的每个新版本都应创建一个新SBOM。当对组件做出修改，包括添加新的上游组件，那么组件的SBOM也需要进行相应修改才能有效。组件更改通常包括更新、升级、发布和补丁。理想情况下，对组件的更改由版本字符串的更改来表示。SBOM应该列举的依赖关系图需要达到什么样的程度？答：这取决于目标受众和沟通媒介。在SBOM机器可读的情况下，最小可行模型是单一层级，目标是在链条上循环往复。许多用例（如FDA医疗设备网络安全管理）希望SBOM能够尽可能完整，但他们也明白构建完整的SBOM需要时间。对于大多数用例，SBOM越完整，能产生的价值就越大。 516.4SBOM6.4SBOM的分发和共享透明度使软件供应商和用户都能做出更好的风险决策。这意味着透明度使软件供应商和用户都能做出更好的风险决策。这意味着SBOM应该在正确的时间被正确的实体访问。SBOM作者必须公开其制作的SBOM吗？答：无强制性要求。SBOM的制作和共享是两件事。SBOM作者可以自行决定是否与相关方共享。SBOM是一种选择而不是要求，供应商可直接提供或通过互联网向买家提供每种产品的SBOM。享SBOM数据？ 答：由于SBOM将供大量软件使用，共享SBOM数据的方法依不同场景而异。但SBOM数据可以通过一系列可预测和可发现的方式进行宣传、共享和访问控制，包括：b）c）d）（MUD））；f）OpenChain)。 注：共享机制与SBOMNTIASBOM有些软件组件是由其他软件组件本身组成的，SBOM能否体现这种层次结构？答：SBOM可以提供分层信息。如果SBOM中包含的每个组件本身也包含组件，则包含其他组件的组件应该有自己的SBOM。将每个软件组件所提供的SBOM组合在一起形成的SBOM，包含了充分理解软件及其各个部分所需的所层面信息这样成的SBOM类似产品造的级材清单。 526.5与SBOM6.5与SBOM有关的其他内容PAGEPAGE53SBOMSBOM流程中涉及到创建和维护环节的责任者和时间，以及SBOM列举的组件依赖关系程度。SBOM与医疗器械安全制造商披露声明（MDS2）有什么关联?？答：MDS2为医疗设备制造商提供了一种向医疗保健提供者披露其医疗设备安全特性的手段。负责建立和修改最新版本的MDS2工作组是NTIA-SBOM多利益相关者过程的参与者。MDS2的SBOM部分是根据这些类似经验而创造出来的。SBOM与OpenC2有什么关联？答：OpenC2是一种用于指挥和控制网络安全的标准化语言。OpenC2的部分命令可以获取设备的SBOM、分析SBOM，并根据分析采取适当的行动(例如，连接、修补、沙箱或锁定）。SBOM与与制造商使用说明（MUD）有什么关联？答：制造商使用说明(MUD)描述了物联网设备及其功能和需求。对这些描述的扩展可以通过指向一个URL、指示适当的本地机制或指示联系点，告知本地部署如何找到对应的SBOM。SBOM与数字物料清单（DBOM）有什么关系？答：数字物料清单（DBOM）是共享包括供需成员间SBOM信息在内的数据的认证共同主干部分。OpenC2是一种用于OpenC2是一种用于机器对机器通术的命令和控制。通过提供机器对机器通信的通用语言，OpenC2不受供应商和应用程序的限制，进而实现了各种网络安全工具和应用程序之间的互操作性而与开发它们的厂商、编程语言和实现的功能无关。OpenC2OpenC2的部分命令可以获取设备的SBOM、分析SBOM，并根据分析采取适当的行动(例如，连接、修补、沙箱或锁定）。PAGEPAGE58总体介绍组成要素生命周期

常见问答知产与保密选择与决策行业实践10.发展趋势PAGEPAGE56知产与保密软件的知识产权通过软件协议彰显，SBOM同样也具有知识产权。当供应商不希望其SBOM被公开传播时，还会对其SBOM制定保密协议。中间商在沿链条传递SBOM时同样面临两类合规问题。软件的知识产权通过软件协议彰显，SBOM同样也具有知识产权。当供应商不希望其SBOM被公开传播时，还会对其SBOM制定保密协议。中间商在沿链条传递SBOM时同样面临两类合规问题。恰当的知产与保密制度将SBOM视为享有专有所有权的软件包附属材料，受合约、谈判、协议约束，而不是利用SBOM的版权来阻止SBOM的传播与分享。“知识共享”是CreativeCommons在中国大陆地区的通用译名，一般简称为CC。CC既是该国际组织的名称缩写，也是一种版权授权协议的统称。在目前网络上流行的授权许可证主要有BSD许可证及其系列、GNU系列、CopyLeft系列（这个概念包括前两者）以及CC系列。其中，BSD和GNU恰当的知产与保密制度将SBOM视为享有专有所有权的软件包附属材料，受合约、谈判、协议约束，而不是利用SBOM的版权来阻止SBOM的传播与分享。CreativeCommonsCC0许可证是SPDX的默认值，按CC0许可证提供的SBOM允许附加保密协议，允许在谈判达成的保密协议的许可范围内传输数据。PAGEPAGE57总体介绍组成要素生命周期常见问答

知产与保密选择与决策行业实践发展趋势PAGEPAGE588SBOM的选择与决策本节主要介绍本节主要介绍NTIA多利益相关方SBOM流程中出现的六个分类和三个维度。分类回退（-）初步共识增强（+）分类回退（-）初步共识增强（+）基本组件信息包含基础组件信息属性的核心子集