3、全软件框架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软件遗产项目，为组件提供唯一标识符20192020202120225定义内涵随着SBOM研究的不断深入，其理论体系已基本搭建完
7、软件组件的能力；减少因复杂上下游关系导致的计划外低效率的工作；对支持透明度的供应商予以支持；使用通用的标准化格式以减少重复性工作；协助识别可疑的或假冒的软件组件。意义降低网络安全风险提高信任度和可信度降低开发、采购和维护数字化基础设施的成本92.2价值SBOM可以识别已知漏洞并及时应对可以量化并管理许可证可以识别安全性，检查许可证的合规要求可以量化软件包中已存在的风险可以提高效率，降低工作量，从而降低运营成本SBOM对软件供应商和消费者的好处可以管理针对漏洞的缓解措施（包括对新漏洞的补丁与补偿控制）创建SBOM可以提高供应商自身竞争力软件生产者可以协助构建和维护其软件，包括知晓软件的上游组件
9、状态的方法（如VEX）难点：基于有限信息（如版本字符串、协议标语或其他试探法）可能无法准确检测到漏洞漏洞管理和VEX分析漏洞的危险性和可利用性，即漏洞可用性交流（VEX）软件组件安全性检查流程分析开源组件输出SBOM分析漏洞使用工具：软件成分分析（SCA）112.3价值用例VEX主要用来判断有关产品是否受到特定漏洞的影响。如果产品受到影响，是否已建议采取补救措施，确定是否存在其他防护手段，保证此漏洞无法有效利用等。为减少用户在漏洞确认方面所花精力，厂商可以发布VEX，以判断漏洞的状态：不受影响无需对此漏洞进行补救；受影响建议采取措施来修复或解决此漏洞；已修复表示这些产品版本包含针对漏洞的修复
14、属性都支持每个用例，所需的具体信息取决于用例的具体情况。以三大用例为例，附加元素和组件属性包括但不限于：组件的使用寿命结束日期或技术支持结束日期；显示组件实施或支持技术的能力；对组件进行分组的机制；可能是通过生产线或已实现的技术进行分组（一组可以被视为一种特殊类型的上游组件）。163.1组成要素数据字段：SBOM格式除了基线属性之外，作者还应该遵守其选择的SBOM格式的规范。SBOM有三种格式，分别是：SPDX、CycloneDX和SWID。下表为将基线组件信息对应到现有格式属性SPDXCycloneDXSWID作者姓名Creator:metadata/authors/authorrole
18、83.1组成要素数据字段：组件关系下面提供一个SBOM示例来进一步说明上一节中描述的关系。SBOM概念图组件名称供应商名称版本字符串作者哈希值UID关系ApplicationAcme1.1Acme0x123234主要|-BrowserBob2.1Bob0x223334包含于|-CompressionEngineCarol3.1Acme0x323434包含于|-BufferBingo2.2Acme0x423534包含于具有上游关系断言的SBOM概念图组件名称供应商名称版本字符串作者哈希值UID关系关系断言ApplicationAcme1.1Acme0x123234主要已知|-Br
19、owserBob2.1Bob0x223334包含于部分已知|-CompressionEngineCarol3.1Acme0x323434包含于无|-BufferBingo2.2Acme0x423534包含于未知193.2组成要素自动化支持自动化支持包括自动化生成和机器可读性，允许跨软件生态系统进行扩展，特别是跨组织边界。使用SBOM数据则需要使用可预测的实现工具和数据格式。用于生成并使用SBOM的数据格式SPDX（SoftwarePackageDataeXchange）CycloneDXSWID（SoftwareIdentification）国际参与公开制定通用句法机器可读
20、人类可读互操作性自动化支持某些机构希望将SBOM集成到现有的漏洞管理实践中；某些机构希望能够实时审计安全策略的合规性。当出现可与现有格式兼容的新标准，考虑将其纳入自动化支持中；当某种格式不再兼容，或不再得到主动维护，则将其剔除。203.3组成要素实践流程SBOM不仅是结构性数据集；在将其集成到安全开发生命周期时，组织机构应遵循SBOM使用机制的实践流程。在任何要求提供SBOM的策略、合同或约定中，都应当明确提出多个元素。频率当软件组件以新版本或发布的形式更新，那么必须创建新的SBOM来体现该软件的新版本。其中包括集成已更新组件或依赖项的软件版本。深度SBOM应当包含所有主要（顶层）组件，
23、cloneDXCycloneDX是一种轻量级SBOM格式，由CycloneDXCore工作组管理，起源于OWASP社区。2012年由ISO定义，并在2015年被更新为ISO/IEC19770-2:2015。SWID标签文件包含有关软件产品特定版本的描述性信息。234.1SPDX概述2010年，SPDX格式发布1.0版本，于2021年8月成为国际标准（ISO/IEC5962:2021），支持在软件开发的过程中自动生成，目前已有5种文档格式，支持4种语言，设有许可证表达式。为Maven构建环境自动生成SPDX文档支持CI/CD集成以生成SPDX文档244.1SPDX的广泛使用英特尔、微
24、软、西门子、索尼、新思科技、VMware和WindRiver在内的众多公司已经使用SPDX传达SBOM信息，以确保全球软件实现合规和安全开发。DocumentName:SPDX-Tools-v2.0SPDXID:SPDXRef-DOCUMENTDocumentComment:ThisdocumentwascreatedusingSPDX2.0usinglicensesfromthewebsite.#ExternalDocumentReferencesExternalDocumentRef:DocumentRef-spdx-tool-1.2#CreationInfo
25、rmationCreator:Tool:LicenseFind-1.0Creator:Organization:ExampleCodeInspect()Creator:Person:JaneDoe()Created:2010-01-29T18:30:22ZCreatorComment:Thispackagehasbeenshippedinsourceandbinaryform.LicenseListVersion:1.19#AnnotationsAnnotator:Person:JaneDoe()AnnotationDate:2010-01-29T18:30:22ZAnn
27、是一种轻量级SBOM格式，于2021年成为第三种通用格式纳入NTIA文件中，侧重于网络安全风险管理，尤其适用于依赖服务的现代软件。274.2CycloneDX工具与特点支持硬件作为组件，更好匹配消费电子、物联网等场景，定义了硬件设备的配置、分类可与VEX连接获得漏洞及其可利用性，支持使用CDX披露漏洞，用CPE、SWID和PURL识别可用于表示应用、容器、库、文件、固件、框架、操作系统、服务等组件可用于描述微服务架构、面向服务的架构（SOA）、功能即服务、n层架构、演员模型、系统的系统等服务支持哈希、加密签名以验证完整性、真实性结合SPDX许可证ID和表达式可装配组件SBOM，支持S
28、BOM分别签名验证可表示组件谱系，包括组件的祖先、后代、派生、补丁和差异284.3SWID概述软件识别（SWID）标签旨在为组织提供一种方式来跟踪其软件，2012年由ISO给出定义，并在2015年成为国际标准ISO/IEC19770-2:2015。SWID标签在软件产品安装过程中被添加到终端，并在软件产品卸载时同步删除。在此生命周期中，给定SWID标签的存在直接对应于该标签描述的软件产品的存在。主标签识别和描述软件产品，安装在计算设备上。补丁标签识别和描述已安装补丁，该补丁对软件产品进行增量更改。语料库标签为其他SWID标签提供附加信息。识别和描述处于预安装状态的可安装软件产品。补充标签29
30、社区和CycloneDX行业工作组的反馈，以指导该格式标准标准的未来方向目前正在开发多个扩展目前正在开发多个扩展，包括对现有漏洞扩展的审计、制定和增强通过每年发布的版本不断完善核心规范IETF正在对一种更轻量级的表示法更轻量级的表示法CoSWID进行标准化，这是一种基于简明二进制对象表示法的SWID标签信息，用来支持受限的物联网用例支持受限的物联网用例3101.总体介绍02.价值与用例03.组成要素04.格式与工具05.生命周期5.1生成SBOM5.2交付SBOM5.3使用SBOM5.4验证SBOM06.常见问答07.知产与保密08.选择与决策09.行业实践10.发展趋势32概述SBO
32、型识别软件交付品中包含的软件组件获取可交付软件中的组件数据将组件数据导入结构化的SBOM格式验证SBOM以确保格式有效且包含“基线”属性生成阶段构建前（源码级SBOM）生成方法：作为版本控制系统一部分，或由挖掘产品构建管道输入的工具创建源码级SBOM。特点：有助于关键组件的识别及在创建产品之前查找漏洞；便于构建到源文件的追溯；可能会呈现并不包含在最终可执行文件中的脆弱源码。适用：对保障性和安全性要求高。345.1生成阶段“构建前”的源码级SBOM目前在实践中采用较少，“构建时”和“构建后”已大量应用于行业实践，且开始适应软件容器化交付。生成阶段构建后生成方法：填写接近工程过程的组件数据；填
34、中应当明确“已知的已知”和“已知的未知”。软件物料清单中的组件范围软件本身的组件依赖项外部服务调用其他非基线要求，尚在发展中。最佳实践需标注清楚是否已含在SBOM中。具体内容创建软件的工具应用程序调用Internet服务、自动更新服务运行时依赖项、操作系统、动态链接库、更新程序、共享库、安装程序部署的其他软件、安装程序本身SBOM基线要求，分层外部服务调用枚举可以简化动态测试，解决网络检测警报问题，可以合理化网络权限建立。365.1生成责任分配在宏观经济意义上，SBOM的使用对社会各方具有广泛效益，供应商是拥有其组件的高质量权威信息，并且生成和共享这些信息的成本相对较低，对生成SBOM负有
36、它的机制。它的一个重要目标就是自动化发现SBOM；“访问”是指使用“发现”的方法连接到SBOM。供应商传输/消费者访问SBOM5.2交付流程38为适应各种软件和设备生态系统的多样性，行业内也设计出现了多种SBOM共享机制。当SBOM被用于操作部署时，它可能会作为一个URL被包含在产品资料或产品包装中，或者作为制造商使用说明(MUD)的一部分。SBOM可以在搜索引擎中被搜索到，也可以通过一个公开的URL从设备本身检索到。当下游开发人员使用SBOM时，软件包可能会包含一份写清楚SBOM具体地址的清单。软件包管理工具和容器也有关于清单信息地址的指南。用来说明许可要求和包装内容。另一种共享SBOM的
37、方法是通过发布或订阅系统。这种情况下，消费者可通过订阅供应商的服务来获取即将发布的更新。共享SBOM示例URL清单发布/订阅系统5.2交付共享方式39通过电子邮件或类似的“外带”机制将SBOM直接提供给接收方01此方法适用于制造商拥有SBOM，但缺乏自动化基础设施共享它。SBOM储存在运行软件的设备上02当SBOM共同储存在一个设备上时，可以使用多个协议中的某一个进行检索。SBOM储存在软件消费者自有的存储库中03SBOM可以被发布到公共或私人网站、数据库、或其他可供软件消费者使用的共享存储库中。访问是指用“发现”的方法传输SBOM。这个过程首先是要检索SBOM的位置和访问方法。根据S
38、BOM所在的位置，可以将传输机制进行简单划分，但不同的机制并不是相互排斥的。5.2交付传输机制405.3使用SBOM归档存储获取到SBOM之后，具体使用场景分为将SBOM数据汇入工作流程和归档储存SBOM文件。将SBOM数据汇入工作流程SBOM的最佳实践是数据汇入企业工作流程，包括采购、资产管理、漏洞管理以及总体风险管理和合规管理。在这种情况下，SBOM作为一个可以解析、提取和加载(ETL)到自动化进程或系统中的数据集，比作为一个独立的文件更加有用。使用Python脚本等方法从指定的SBOM字段中提取数据并将其加载到外部数据平台和工作流程中。内部开发的工具（如脚本）开源的包或依赖管理系统
41、关标题文字对SBOM组件并行监控或带外监控为消费者创建了态势感知，并提高了供应商对易受攻击组件进行安全补救的透明度。这种“信任但验证”的能力可以持续监控供应商软件依赖项的漏洞状态，通过缩小消除态势感知方面的差距生成保障连续性。优点供应商负责任的供应商可能会在不删除易受攻击依赖项的同时，采取一些步骤修复其中的安全问题。比如通过限制函数调用或删除子组件修复。消费者消费者须承认和接受VEX文件中列举的有效补救措施，而不是要求一个“干净扫描”，不包含任何CVE。更高层次的透明度可以提高安全性435.3使用SBOM机密性要求不论SBOM是由供应商或开源社区或其他作者生成或提供，其许可状态都应该明确化
44、要求获取SBOM的数字化签名。455.4验证SBOM软件实体解析SBOM验证包括格式验证和组件验证，常用的验证方法是软件实体解析，其执行方法和名称分配方法依具体情景和使用方法而异，用于证明SBOM的完整性和真实性。在可能的情况下应要求获得供应商许可的组件提供权威标识符，以确保这些具有合同指定供应商的组件在包括这些许可组件的软件产品中命名一致。如果使用商业SWID标签，它们必须包括商业软件的精确版本控制，在发行版、服务包和补丁的命名上不同于开源组件。相同版本的商业软件可能在其组成和安全配置文件方面存在显著不同，这取决于已安装的更新。软件实体解析执行方法通过查找的方式手动执行使用脚本和人工判断的
45、组合半自动执行由甲方自有的或获得商业许可的软件实体解析引擎自动执行使用别名或伪标识符手动分配名称使用别名或伪标识符自动分配名称在没有权威的外部标识符的情况下，利用供应商和组件级别的实体解析来制定组件名称软件实体解析名称分配465.4验证SBOM软件实体解析完整的软件实体解析还包括对软件组件依赖关系的解析，即软件依赖项解析。传递性依赖解析如果SBOM仅仅提供直接软件依赖，完整的软件实体解析需要解析那些直接依赖关系，以对软件交付物中所有传递依赖项进行分类。因为易受攻击的往往是传递依赖项，而且漏洞数据库中从传递依赖项到直接依赖项的映射不是最新，也是不完整的。传递依赖项解析可使用开源工具或商业解决方
51、律协议或其他要求可能禁止披露某些组件。SBOM是否会暴露企业的知识产权/商业机密？事实：不会。只要存在被许可的软件，就会产生相应的许可义务，这些义务与SBOM无关。SBOM提供了在其他方面可能会被隐藏的软件清单。因此，SBOM曝光了潜在的许可证违规行为，促使人们有意识地减少此类违规行为。SBOM是否会增加软件的许可证违规风险？事实：由于行业活动的融合，商业和开源工具的列表正在不断增加。随着跨部门采用率的提高，流程和集成也在共同发展。SBOM机器可读性的提高进一步实现了SBOM的可扩展性。所有这些发展和创新的结合为SBOM的大规模实施提供了许多选择。不存在支持SBOM扩展性的生产和使用流程？事实
63、2年4月，FDA发布医疗设备网络安全草案，专章推荐使用SBOM。SBOM工具提供商制造商SBOM生产者医院SBOM消费者灵活性迭代：渐进的复杂性波动：新SBOM的增量发布方法与能力格式工具与自动化提升的SBOM层级深度上下文信息SBOM在医疗利用定义更明确、更复杂的资源61汽车、能源行业2020年，美国交通部下属国家公路交通安全管理局更新了现代车辆安全的网络安全最佳实践，建议通过SBOM维护车辆的电子控制单元，包括跟踪软件组件并快速准确定漏洞位置。2021年11月，汽车信息共享和分析中心启动SBOM概念证明”项目，以提供所有主要汽车制造商都将接受的标准SBOM方法。Linux基金会
65、针对的是用于管理软件开发和构建流程的工具和系统。现代应用开发和云原生架构也值得进一步考虑软件透明度某些现代软件执行涉及动态依赖和调用第三方服务，以及其他未直接包含进软件构建中的依赖项。依赖项需要确保软件按计划运营，不因滥用引入漏洞。要完全描述这种数据需要进一步的工作，并辅助自动化解释和使用。确保软件安全用加密保证安全地捕获整个软件生命周期的细节基础实现自动化有效途径政策强制执行机器可读性语义解释数据规范标准化基本条件前提64SBOM可以发展的维度较多，受到广泛重视的发展方向主要有以下6方面。软件标识理想情况下希望实现一个单一且广泛使用的命名空间，因为多样化版本方法和系统阻碍了SBOM可扩展自动