 其中，在解释“SCA”的时候， 谈到了SBOM，那么，具体什么是SBOM呢？除了与系统的安全性紧密相关之外，SBOM还有怎样的价值呢？ 1. 从BOM到SBOM 在详细了解SBOM之前，理解什么是BOM可能大有裨益。 BOM（Bill of Material）即物料清单，也就是以数据格式来描述产品结构的文件， 是一份列出生产和制造产品所需原材料的清单。产品开发涉及多个团队，BOM在产品设计、开发、生产和分销之间架起了桥梁，有助于实现多方通力合作。BOM 不仅包含详细的物料清单，还包括所需物料的采购和使用说明。这些信息可以存储在电子表格、ERP 或 PLM 之类的现代化集成系统等许多位置。 从技术上看，BOM是计算机可以识别的产品结构数据文件，BOM是系统识别产品的结构，也是联系与沟通企业各项业务的纽带。在ERP系统中，BOM往往分为生产BOM、成本BOM和计划BOM等。在物联网产品中，硬件的BOM往往与成本直接相关。一份好的 BOM 有助于高效、准确地制造产品，帮助企业在实际生产开始前确定制造产品所需的全部要素和流程并进行定价。 SBOM（Software Bill of Material，软件物料清单）是企业使用的所有软件组件的完整列表。SBOM通常由第三方开源库、供应商提供的软件包和企业自己编写的专有软件构成。从技术维度看，软件物料清单（SBOM）是一种正式的且机器可读的元数据，可唯一地标识软件组件、其依赖项和许可证信息。SBOM旨在跨组织共享，特别有助于提高软件组件的透明度，尤其是当这些组件是由供应链中的参与者交付提供的。 SBOM最小必需元素是实践过程中需要的元素最小集，如下图所示：  企业可通过参考以上三类元素，并扩展企业自身需要管理的额外信息，构成适合自身标准的SBOM清单。 2. 为什么需要SBOM 关于SBOM的产生，与系统的安全性息息相关，尤其是Log4Shell风波之后, 关注软件安全的企业一般会把SBOM 作为网络安全战略的基石。 系统安全是一个全球性的问题。欧盟早在2014年就通过了《通用数据保护条例》（GDPR），并在2016年成为一项可执行的法规。GDPR旨在为人们提供对其个人信息的高度控制，通过规则来满足如何处理个人信息的要求。在此基础上，2019年出台了《网络和信息系统安全指导》和《欧盟网络安全法》。  在我国，从2017年的《网络安全法》开始，该法对IT服务提供商以及他们如何处理个人信息提出了规范要求。2021年的《数据安全法》，该法对 “国家核心数据 “实施了以政府主导的更严格监管。2021年11月，颁布了新的《个人信息保护法》，提高了政府对技术公司的监管力度，同时也逐步提高了对个人信息处理的要求。 安全性是影响企业选择软件的第一考虑因素，许可证合规性是第二考虑因素，即便考虑其他要素，安全性和许可证合规性仍然是最重要的考量因素。企业关注软件安全的主要原因包括财务风险、法律风险和声誉风险，要强调软件安全问题的策略连贯性。 提高软件供应链的透明度和安全性是至关重要的，解决软件供应链的安全问题涉及一系列的活动，例如： ·开发环境的安全 ·检查软件组件中已知的和潜在的漏洞，并对其进行修复 ·维护准确和最新的数据，明确软件代码的来源 ·为购买者提供每个软件产品的SBOM SBOM是解决其中一些问题的有效方式，特别是那些专注于了解软件产品的漏洞、许可证合规义务和代码来源的需求。因此，生产和消费SBOM被认为是解决所有类型的软件产品（包括开源和闭源组件）的各种信任问题的有效途径。也就是说，SBOM是解决软件供应链安全的一个关键催化剂。 SBOM的主要目的是明确地识别组件及其彼此之间的关系。SBOM并不会解决所有的软件安全问题，但是它构成了一个基础的数据层，在这之上可以进一步构建安全工具、实践和保证。 3. SBOM的特点和优势 一般认为，SBOM具有6个维度的特点： 具有丰富的元数据 机器可读性是SBOM的关键指标 识别已知和未知的依赖传递 随着每次代码变更而更新 元信息应该与模块绑定 应在发现漏洞时及时反馈 SBOM使开发人员更容易理解广泛且复杂的项目中的依赖关系。在微服务应用程序具有许多组件的时代，每个组件通常具有一定数量的依赖关系，在现实的软件系统中经常会遇到依赖地狱——  SBOM通过显式的方式标识出依赖关系，随着应用程序中组件的复杂性和数量的增加，这一点越来越有用。 SBOM的生产通常与构建商业软件的企业紧密相连，生产SBOM 的三大益处：开发人员更容易理解应用程序组件之间的依赖关系，也更容易对组件的漏洞进行监控，以及更容易确认许可证的合规性。从而，这三大益处同样会带来3个使用SBOM的优势：由SBOM提供的软件透明度使得及时发现漏洞、主动识别已达到生命周期终点的组件和及时察觉风险组件成为可能。这些好处有助于组织提高安全性，减少风险并为其客户和商业伙伴提供更可靠的服务。 SBOM提供的信息改进了之前基于风险的决策方式，SBOM的漏洞报告使组织能够更快速、更直接地了解安全风险。使用SBOM的收益与生产SBOM的效益完全一致，体现了相同的价值观：解决合规性要求与管理许可证合规性密切相关，改进基于风险的决策和安全风险的暴露与组件依赖关系的清晰度和组件漏洞的监管程度密切相关。  此外，在一些特定场景中SBOM也会最大限度地发挥作用，例如—— 融资、并购和IPO：SBOM是收购、IPO或融资过程中技术尽调的重要一环。利益相关方会要求获取文档以更好地了解产品中的软件成分以及许可证合规性、安全性或代码质量风险。 客户要求：由于企业都将防止软件供应链风险的优先级提高了，未来会有越来越多的企业要求采购环节中需要提供SBOM。 版本兼容：维护大量旧软件的公司经常需要进行软件包的更新和升级，如果对这些旧产品中的源码软件有一个完整的SBOM，做起来就容易多了。 4. SBOM的构建框架 从SBOM生产者的视角出发，包括数据层、构建层、应用层三大维度，涵盖创建信息、软件信息、组件信息、文件信息、代码片段信息、生成方式、生成频率、生成深度、更新校验机制、软件资产管理、软件漏洞管理、安全事件响应等重点内容，从而构建出SBOM总体框架模型，具体如下图所示。  数据层明确了SBOM所应具备的最小数据要素，具体包括清单创建信息、软件信息、组件信息、文件信息、代码片段信息五部分，各部分数据之间存在依赖或关联关系。构建层明确了所需收集的数据要素和SBOM的构建方式，包括生成要求、生成方式、生成频率、生成深度、更新校验机制五部分。应用层明确基于构建完成的SBOM体系以及在组织内部的实际使用场景，至少包括软件资产管理、软件漏洞管理、安全事件响应三部分。 4.1 数据层 在数据层，首先要明确SBOM的创建信息，包括： 清单名称 清单创建者 清单版本号 清单创建时间 清单唯一标识符 软件是SBOM中的描述主体，其元数据包括： 软件类型 软件来源 软件供应商信息 软件名称 软件版本 软件下载地址 软件哈希值/数字签名 软件唯一标识符 软件许可证信息 软件校验码 软件外部引用 软件分发信息 颗粒度变小，SBOM还要尽量描述到组件或子系统，软件一般都是由组件或子系统组成的，其元数据包括： 组件名称 组件作者 组件类型 组件版本 组件唯一标识符 组件校验码 组件依赖关系 组件许可证信息 组件使用方式： SBOM的最小颗粒度是文件，文件的描述内容包括： 文件名称 文件作者 文件类型 文件唯一标识符 文件校验码 文件许可证信息 4.2 构建层 SBOM的创建者应通过加密或数字签名的方式对软件物料清单的真实性和完整性进行保证。SBOM的生成方式包括人工生成和自动化生成两种，其中：自动化生成应明确生成模式，包括基于构建活动生成和基于二进制解析，有源代码的情况下应优先采用前者；人工生成的方式应明确收集阶段和收集方法。 当软件组件以新版本或发布的形式更新，应创建新的相对应版本的SBOM，包括集成已更新组件或依赖的组件版本。特别地，当SBOM创建者更正已有软件物料清单数据中错误的时候，也应该在第一时间发布新的经过修订的SBOM。SBOM的更新校验机制同样包括手动校验及自动校验两种方式，手动校验需记录操作人、操作时间、操作结果等，而自动校验应具备校验失败拒绝更新的机制。 SBOM生成深度应包含所有主要（顶层）组件，并列出其中包括的直接依赖，对于可以直接获取到完整依赖树的技术栈，应记录从根节点到叶子节点全部深度的清单。 4.3 应用层 从应用的视角来看，通过对SBOM的管理，能够从组件名称、组件名称+版本维度看到软件资产数量，能够从组件出发，溯源目前被哪些服务在线上使用。从安全漏洞出发，通过对SBOM的管理，可以溯源哪些组件被影响，能够从应用维度出发，查看应用中的安全漏洞信息。  基于对SBOM的管理，建立安全事件的响应机制尤为重要，要能够追踪漏洞修复的状态，如线上未修复、修复中、已修复，能够统计时间维度漏洞的产生、修复趋势变化，能够统计不同风险等级/不同安全类型的漏洞占比。在安全维度之外，还要支持其他风险维度的信息记录，例如支持一次性自动化生产/人工生成SBOM后，对SBOM进行更新/追加，并支持用户的自定义查询，如根据SBOM多风险维度组合过滤。 5. SBOM 文件的交付格式 企业可以通过各种不同的格式创建和发布SBOM。对于一个想要在其网站发布 SBOM 的企业来说，HTML 是一个合理的选择。如果 SBOM 中包含了文档或者源代码，那么纯文本也许是更好的选项。此外，还有Markdown、PDF、CSV等格式可供使用。 除了这些常见的格式外，还有几种专门为交付SBOM而设计的格式，如 SPDX，SWID Tags以及Cyclone DX。 5.1 SPDX SPDX是由 Linux 基金会运营的项目，旨在标准化企业共享和使用SBOM中信息的方式。SPDX 捕捉了软件中与溯源、许可证和安全相关的数据，如下图所示：  通俗地说，SPDX提供了一个通用的许可证列表标识符以及每个许可证的规范URL。该格式支持以下文件类型： YAML JSON RDF/XML tag:value的纯文本 .xls 5.2 SWID Tags SWID 是一个标准化的 XML 格式，可以识别软件产品的组成部分并将其与上下文结合。在软件开发生命周期中，有4种类型的 SWID Tags ： Corpus Tags：识别和描述在安装前阶段的软件成分。 Primary Tags：在软件产品安装后对其进行识别和关联 Patch Tags：可以识别和描述补丁（而不是核心产品本身）。此外，还包含了补丁和其他产品或补丁之间的上下文关系信息。 Supplemental Tags：SWID 格式仅允许 tag 创建者修改 corpus、primary和patch tags。但是 Supplemental Tags 可以让软件用户及软件管理工具在本地添加有益的上下文信息，如许可证密钥以及相关方的联系信息。 在决定将哪些标签和具体的数据元素纳入其产品时，各企业有一定程度的灵活性。在SWID规范中，除了几个必需的字段外，其他的元素和属性都是可选的。最终，一个最低限度的有效和符合要求的标签只需要描述软件产品（如名称和标签ID）和创建它的少数实体元素。 5.3 OWASP CycloneDX CycloneDX 是一个轻量级SBOM标准，旨在用于应用安全上下文和供应链组件分析。也就是说，它旨在提供构成一个应用程序的软件组件的关键信息。该标准非常完整，并且超出了软件库的范围，甚至扩展到了SaaSBOM、VEX等标准范围。 Cyclone DX 支持以下4种类型的数据： 物料清单元数据：关于应用/产品本身的信息——供应商、制造商、SBOM所面熟的组件以及用于汇编SBOM的任意工具 组件：完整的专利清单及开源组件清单，包含许可信息 服务信息：软件可能调用的外部API、终端URI、身份认证要求和信任名单 依赖项：包含直接依赖项和间接依赖项 在展现方式上，SBOM的信息可以通过图、表格等方式进行展现。  6. 如何生成SBOM 有不少的开源工具都可以生成SBOM，而有效的SBOM依赖软件成分分析能力和大量知识数据的储备。 SBOM的生成依赖软件成分分析（SCA）技术，识别组件和版本，并输出对应的层级依赖关系，其复杂性在于： 1）要适配不同的编程语言，而像java和c/c++这样不同语言的包管理机制会有较大差异； 2）要从源码、制品、二进制等不同形态的软件产物中解析提取特征，这些特征的提取策略依赖于对各类产物的理解。 除了SBOM中的基线字段信息外，漏洞、开源许可证也可以作为SBOM的附加信息，而这样的数据严重地依赖于云端知识库的积累。知识库需要实时跟踪当前的各种漏洞情报，并由人工运营加工；需要采集大量的代码和软件信息，分析依赖、计算哈希、提取特征等等，进而加工形成能和SCA工具结果匹配的特征数据。 6.1 SBOM的生成工具 市场上有很多值得关注的SBOM生成工具，包括： Anchore FOSSA Mend Rezilion SPDX SBOM Generator Tern TauruSeer Vigilant Ops 2022年7月，微软宣布开源SBOM生成工具——Salus，作为一款通用的、经过企业验证、构建时（build-time）的 SBOM 生成器，SBOM 适用于包括 Windows、Linux 和 Mac 在内的平台，并且采用了标准的软件包数据交换（SPDX）格式。  Salus 能够轻松集成到软件的构建工作流程中，并通过组件自动检测 NPM、NuGet、PyPI、CocoaPods、Maven、Golang、Rust Crates、RubyGems、容器内的 Linux 包、Gradle、Ivy、以及 GitHub 等公共平台上的存储。 Salus 生成的 SBOM，包含了基于 SPDX 规范的四个主要部分。 文档创建信息：例如软件名称、SPDX 版本 / 许可证、文档创建者、创建时间等。 文件部分：组成软件的文件列表，每个文件都包含有一些属性、以及 SHA-1 / SHA-256 内容的哈希值。 软件包部分：构建软件时使用的包列表，每个包都具有名称、版本、供应商、哈希值、包 URL（purl）、软件标识符等属性。 关系：SBOM 不同元素之间的关系列表，比如文件和包。 值得一提的是，Salus 还可参考其他 SBOM 文档来捕获完整的依赖关系树。 回到本文的开始，国内的悬镜安全在满足以上SBOM能力需求的基础上，也在开源OpenSCA并提供了公开SBOM生成工具，方便软件生产商自动生成SBOM清单。 6.2 SBOM的工具选择与治理 市场上许多SBOM工具一般捆绑在代码安全扫描程序和其他类似程序上，用户选择起来比较困难，Gartner建议使用提供以下功能的工具： 在构建过程中创建SBOM 分析源代码和二进制文件（如容器镜像） 为这些工件生成SBOM 编辑SBOM 以人类可读的格式查看、比较、导入和验证SBOM 将SBOM内容从一种格式或文件类型合并和翻译成另一种格式或文件类型。 支持通过API和库在其他工具中使用SBOM操作。 对于企业的内部治理而言，单点的工具往往是不足够的，还需要有管理平台输出全局的风险视图，提供了管理和控制能力。例如，记录每一次的SBOM变化情况，从而能够展现不同时间点的风险指标情况；要能够基于项目、资产等不同维度对结果进行聚合，便于对总体风险进行梳理。基本的管理平台以SBOM和知识库作为核心数据，控制模块通过和制品库、代码库等的联动，进行数据收集和策略下发，出现问题时帮助企业及时止损。决策模块对黑白名单进行维护并对阻断等策略进行管理，管理模块提供SBOM查询和相关管理指标看板的能力。 从企业角色类型来看，对SBOM有不同的使用需求： 项目团队：用于管理软件资产，在开发早期即可评估安全风险，筛选适合的组件/软件，并持续更新SBOM； 安全团队：通过提交的SBOM分析软件风险，并通过统一管理进行持续监控，及时响应安全事件； 法务团队：核查软件授权问题，避免后续公司业务自身权益受到损害。  当SBOM被重新定义后，SBOM具有更高的透明度、具体来源和传播效率，企业在一定条件下通过SBOM即可识别和修复漏洞风险，而且还可以指导开发人员或供应商在整个SDLC中进行应用安全软件开发实践。 7. 一句话小结 软件物料清单 (SBOM) 相当于软件嵌套的清单，是构成软件组件的成分清单，正在成为确保软件供应链健康的重要组成部分，然而，仅仅发布 SBOM 是不够的，还需要积极地使用它们。 |
|
|
