4.3 SBOM格式

为使 SBOM 的采用标准化和成熟化，各方努力围绕几种主要的 SBOM 格式开展工作。迄今为止，三种主要的 SBOM 格式是软件识别 (SWID) 标签、CycloneDX 和软件包数据交换 (SPDX)。这三种 SBOM 格式各有利弊和主要用途。CycloneDX 和 SPDX 分别得到了不同组织的支持，CycloneDX 得到了 OWASP 的支持，而 SPDX 则得到了 Linux 基金会的支持。如前所述，在过去几年中，围绕 SBOM 的公开对话大多是由 NTIA 和 SBOM 格式等工作所引导的，标准也不例外。NTIA发布了《SBOM格式与标准白皮书》（http://ntia.gov/files/ntia/publications/ntia_sbom_formats_and_standards_whitepaper_-_version_20191025.pdf），指出了软件透明度方面的问题，并评估了当前可用的 SBOM 格式。这份白皮书于2019年发布，自此之后，围绕这些 SBOM 格式（尤其是 CycloneDX 和 SPDX）的讨论不断发展。虽然在谈话的早期，NTIA 的文档等资料中提到 SWID 是一种 SBOM 格式，但它并没有具体满足 NTIA 对 SBOM 的最低要求，例如 SWID 规范中规定的 SBOM 生成时间戳。美国陆军这个正在大规模采用 SBOM 的组织明确表示，他们不会使用 SWID 格式的 SBOM，而是需要 CycloneDX 或 SPDX (https://sam.gov/opp/0b824ec63e2541e082c58c65b6e1702d/view)。

NTIA团队关注的一些关键领域包括需要记录可操作和可执行的机器可读格式，同时也承认不会要求单一格式，并推动一个多种格式可以并存的生态系统。每种主要的SBOM格式都以不同的表现形式和文件格式呈现信息。表4.2是使用NTIA SBOM最低要素作为基准的三种格式的示例。

表 4.2: 三种 SBOM 格式

属性 软件包数据交换格式SPDX CycloneDX 软件识别标签SWID
作者名称 (2.8)创作者 元数据/作者/作者 @role (tagCreator), @name
时间戳 (2.9)创建 元数据/时间戳 Meta
供应商名称 (3.5)包装供应商 供应商发布者 @role(softwareCreator/publisher), @name
组件名 (3.1) 软件包名 名称 @version
版本号 (3.3) 软件包版本 版本 @version
组件哈希 (3.10) 软件包校验码: (3.9): 软件包验证码: Hash"alg" /../ @[hash-algorithm]: hash
唯一标识符 (2.5) SPDX 文档命名空间: (3.2) SPDXID: bom/serialNumber component/bom-ref @taqgID
关系 (7.1) 关系: 描述：包含： (嵌套组件/子组件和/或依赖图中的固有属性) @rel, @href

来源: ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf. U.S Department of Commerce, Public domain

软件识别（SWID）标签

SWID标签专注于软件清单和授权管理。它通过在软件中查找SWID标签来实现功能。SWID标签的格式由国际标准化组织（ISO）和国际电工委员会（IEC）的ISO/IEC 19770-2标准定义，截至撰写本文时，最新版本为ISO/IEC 19770-2:2015。

SWID标签文档包括一组结构化的数据元素，用于识别软件产品，包括产品版本、参与产品生产和分发的组织/个人，以及构成软件产品的各种部件。它们还可以用于建立不同软件产品之间的关系。

SWID通常被诸如软件资产管理（SAM）和安全工具等工具使用，帮助自动化与软件产品在整个软件开发生命周期（SDLC）中相关的一些行政开销。

SWID 规范包括多个角色和利益相关者，如标签生产商、平台提供商、软件提供商、标签工具提供商和标签消费者。在更广泛的软件生态系统中，这些利益相关者中的每个人都在使用 SWID 来完成他们的各种用例和任务。

尽管在早期的NTIA文档中SWID 被认可为是一种 SBOM 格式，但业界已将 CycloneDX 和 SPDX 作为两种主要的 SBOM 格式。与 SBOM 格式相比，SWID通常被认为更像是CPE（公共漏洞与曝光，Common Platform Enumeration）

CycloneDX

SPDX 由 Linux 基金会等组织倡导，而 CycloneDX (http://cyclonedx.org) 则由安全社区的长期领导者 OWASP 领导。CycloneDX是一种自定义的“轻量级SBOM标准，设计用于应用安全环境和供应链组件分析”（见图4.1）。CycloneDX的核心团队包括Patrick Dwyer、Jeffry Hesse、软件供应链领导者和依赖性跟踪（Dependency Track）的创建者Steve Springett，后者担任该小组的主席（http://dependencytrack.org）。除了 OWASP 的支持，CycloneDX 还得到了洛克希德-马丁公司、Contrast Security、Sonatype 等公司的支持。

CycloneDX 的独特之处在于，它从一开始就被设计为一种 BOM 格式，可满足各种使用情况，包括软件即服务 BOM（SaaSBOM）。除软件外，CycloneDX 还支持多种使用情况。

CycloneDX 还支持在其他系统和 BOM 中引用组件、服务和漏洞，采用嵌套和分层方法，以适应现代软件生态系统在硬件、云和 SaaS 方面的复杂性。CycloneDX 将这种功能称为 BOM 链接。它支持 JSON 和 XML 格式。用户可以引用外部 BOM 的 URL，甚至是 BOM-Link URI，其中使用了外部 BOM 的序列号和版本。

此外，CycloneDX 还可对所有第一和第三方组件进行完整、准确的清查，以进行风险识别。它通过组件类型和类别的强大列表来实现这一点，这些组件类型和类别不仅包括软件和应用程序，还包括设备甚至服务。它可以通过三个字段识别漏洞：

  • CPE（Common Platform Enumeration）：用于操作系统、应用程序和硬件设备漏洞的规范。

  • SWID（Software Identification）：用于安装的软件的规范。

  • PURL（Package URL）：用于软件包元数据的规范。

CycloneDX 支持通过哈希值和加密技术对与 BOM 相关的组件进行完整性验证。通过 Sigstore 及其配套的 Cosign 等项目，软件签名正日益成为推动软件供应链安全成熟的最佳实践。CycloneDX 支持可扩展标记语言（XML）和 JavaScript Object Notation（JSON）的封套签名，而 Cosign 目前还不支持这种签名。CycloneDX 还支持出处（provenance），即表示组件作者和组件供应商的能力。基于出处的概念，CycloneDX 可通过交流组件的祖先、后代和变体来描述组件的世系，从而支持组件的世系。对于高保证软件供应链要求而言，实施出处、血统和数字签名代表了强大的供应链能力，也是 NIST 的网络安全供应链风险管理（C-SCRM）等指南所推荐的。

CycloneDX 还支持漏洞可利用性交换 (VEX)，该交换提供了对软件产品和组件中已知漏洞可利用性的深入了解，并可由软件生产商进行交流。我们将在 "Vulnerability Exploitability eXchange (VEX) and Vulnerability Disclosures "一节中更深入地介绍 VEX。

软件包数据交换(SPDX)

作为一个项目，SPDX 的成立旨在为软件包相关信息创建一种通用数据交换格式，以便共享和收集。在主要的 SBOM 格式中，SPDX 支持的文件格式最多，包括 RDF、XLSX、SPDX、JSON 和 YAML。SPDX 还旨在成为一种动态规范，能够描述一组软件包、文件或片段。与 SWID 一样，SPDX 也是目前获得 ISO 认证的三大主流格式之一 (http://linuxfoundation.org/press/featured/spdx-becomes-internationally-recognizedstandard-for-software-bill-of-materials)，这意味着它已满足 ISO 规定的标准化和质量保证的所有要求。这项成就是由 Linux 基金会于 2021 年 9 月宣布的。该公告还强调了 SPDX 已被英特尔、微软、西门子、索尼等大公司所采用，这些公司都参与了 SPDX 社区。

SPDX 规范目前是 2.3 版（http://spdx.github.io/spdx-spec）。要被视为有效的 SPDX 文档，必须包含 SPDX 规范本身定义的特定字段和部分。

SPDX 文档可由各种字段和数据组成，如文档创建信息、包信息、文件信息、片段信息、许可信息、关系和注释。文档创建信息用于在使用处理工具时实现向前和向后兼容性。包信息用于描述不同的实体，如产品、容器和组件等，并可用于对共享上下文的相关项目进行分组。文件信息包括文件元数据，如名称、校验和许可证和版权信息。片段是可选的，主要用于数据来自不同的原始源或与其他许可证绑定的情况。SPDX 还支持文档、包和文件的关系。最后，注释允许审阅者将其审阅活动中的信息纳入 SPDX 文档。

SPDX还提供了“SPDX Lite”配置文件，它是SPDX规范的子集，旨在与特定行业的工作流程保持一致，同时兼顾遵守总体 SPDX 标准和规范。Lite配置文件侧重于文档创建和软件包信息部分以及相关的基本信息。

漏洞利用可行性交换（VEX）和漏洞披露

SolarWinds 网络安全事件 (http://cisa.gov/news/2020/12/13/cisa-issues-emergency-directive-mitigate-compromise solarwinds-orion-network)的余波，再加上网络安全 EO，将软件供应链安全以及相关的 SBOM 话题推向了安全对话的中心舞台。再加上 Log4j 漏洞 (http://cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf) 让无数企业忙于确定其影响，SBOM 现在已被视为现代网络安全漏洞计划的一个重要组成部分，并将迅速得到采用 (http://cisa.gov/sites/default/files/publications/VEX_Use_Cases_April2022.pdf)。

如上图4.2所示，一个SBOM树可以展示上游关系声明，以展示组件及其关系，包括声明组件起源是否未知。

使用 SBOM 所带来的最大好处之一就是能够识别潜在的易受攻击组件。领先的 SBOM 平台和工具（如 Dependency Track）通过将与组件相关的漏洞与使用 SBOM 分析其软件组件的人员的注意力联系起来来实现这一目的。Dependency Track 和其他工具通过查询国家漏洞数据库 (NVD；http://nvd.nist.gov)、Sonatype OSS 索引 (http://ossindex.sonatype.org)、VulnDB (http://vulndb.cyberriskanalytics.com) 或 OSV (http://osv.dev) 等来源来促进这一过程。然而，漏洞与软件中的某个组件相关联，并不意味着该组件可以被利用。这就是 VEX 发挥作用的地方。

VEX进入对话

根据NTIA的指南（http://ntia.gov/files/ntia/publications/vex_one-page_summary.pdf），VEX的主要用例是

为用户（如运营商、开发商和服务提供商）提供更多信息，说明产品是否受所含组件中特定漏洞的影响，如果受影响，是否建议采取补救措施。

VEX 为漏洞添加了背景信息，为风险管理活动提供了依据。与其他领先的 SBOM 和软件供应链透明度与安全指南一样，VEX 也是在 NTIA 的软件组件透明度多方利益相关者流程（Multistakeholder Process for Software Component Transparency）的基础上诞生的。尽管如此，该指南指出虽然 VEX 是针对特定的 SBOM 用例开发的，但它并不局限于SBOM 的使用，同时也不一定是必需的。

正如本书其他章节所述，存在漏洞并不意味着它是可以利用的。这是非常重要的信息，因为漏洞管理程序和活动与组织一起执行风险管理。在网络安全风险管理中，组织试图根据组织的风险承受能力识别、分析、评估和应对网络安全威胁。这样，组织就会根据风险发生的可能性和严重程度确定风险的优先级。如果不知道漏洞是否可被利用，就不可能准确预测其可能性。

VEX: 添加上下文和清晰度

那么，VEX 究竟是如何解决这一难题的呢？它授权软件供应商发布 VEX，即关于特定产品中漏洞状态的声明。VEX 支持以下四种主要状态选项：

  • 未受影响：不需要针对此漏洞进行补救措施。
  • 受影响：建议采取行动来修复或解决此漏洞。
  • 已修复：这些产品版本已包含对漏洞的修复。
  • 正在调查：尚不清楚这些产品版本是否受漏洞影响。将在后续发布中提供更新。

以SBOM本身为例，我们看到了朝着机器可读的工件和文档推进，这使得自动化、准确性和速度得到了提升。在合规领域，我们也看到了类似的趋势，如NIST的开放安全控制评估语言（OSCAL; http://pages.nist.gov/OSCAL），它将传统的基于纸张的安全控制和授权文件转换为机器可读格式。

VEX 采取了类似的做法，它不需要通过电子邮件发送安全公告或有关漏洞和建议的详细信息，而是将这些信息转化为机器可读的格式，以促进自动化和现代化安全工具的使用。这些工具能更快地响应当前的威胁态势，而不是依赖人力和手动活动。随着对软件供应链透明度和安全性的推动，我们不难想象这样一个世界：企业软件库存能够在仪表盘和工具中可视化，同时还能显示其相关漏洞和漏洞的实际可利用性，所有这些都由 SBOM 和随附的 VEX 数据支持。这与现代生态系统形成了鲜明对比，在现代生态系统中，大多数组织都没有准确的库存，不知道他们所使用和部署的软件组件，也不知道与之相关的漏洞。尽管现代软件主要由开源软件组件（OSS）组成，据估计，开源软件组件占据了软件的80-90%。

指南还指出，虽然VEX可以由软件供应商撰写，但也可以由第三方撰写，这使得用户可以自行决定如何使用数据。这使得很容易想象到，安全研究人员和漏洞供应商可能会尝试为其产品提供VEX，作为其产品提供的一部分。

VEX和VDR对比

除了VEX概念外，漏洞通告或漏洞披露报告（VDR）的主题增加了一些混淆，但实际上这是一个非常简单的主题。VDR 会在出现漏洞时通知您，其中既包括已知漏洞，也包括未知漏洞。此外，VDR提供有关漏洞的附加元数据，包括谁发现了漏洞、有关公开利用的信息以及其他附加信息。ISO 29147标准和NIST 800-161r1文档概述了VDR的以下要素，如下所示：

VDR要素概述

  1. 一般信息：有助于目标受众了解此安全公告是否适用于他们。

  2. 标识符：此安全公告的唯一标识符，如供应商使用的唯一编号方案，漏洞标识符（例如CVE）、产品标识符（如CPE或PURL）。在与SBOM对比时，此属性可能是连接断言的较好属性之一。

  3. 日期和时间：初始安全公告的日期和时间以及任何更新。将VDR的时间戳与其他断言进行比较时，可以帮助确定VDR是先于还是后于其他处理的断言，并且是否包含比其他产品更为更新的信息。

  4. 真实性-签名：虽然不包括在ISO标准中，但NIST已指出签名的需求，签名可能是用于将多个断言与任何信任级别链接在一起的最佳方式之一。

  5. 标题：简要标题应足够唯一，清楚地说明安全公告的内容，包括产品名称和版本或CWE类别。

  6. 概述：扩展标题，提供足够的细节，使读者能够了解安全公告对其产品的适用性。

  7. 受影响产品：清楚说明受VDR影响的产品，并提供足够信息，使读者能够了解其产品是否受影响。这可能包括用于测试的在线脚本的链接，或特定的元数据，如文件哈希、字符字符串或唯一版本指示符。

  8. 受影响组件：虽然 ISO 标准中没有包括这一点，但 NIST 的文件中却有详细说明，这也是我们理想的捕获组件级详细信息的地方，这些信息可以与 SBOM 相结合，并以与受影响产品相同的方式使用--例如，说明组件需要如何实施或使用才能成为易受攻击的组件。仅仅存在易受攻击的组件可能不足以满足易受攻击的条件。

  9. 预期受众：此安全公告的预期受众是谁？开发人员？最终用户？虽然这是VDR中的可选字段，但可用于传达使用 VDR 的其他背景信息。

  10. 本地化：可能针对特定地区和特定语言发布安全公告。此部分允许传达任何需要传达的区域特定信息或上下文，即使只是翻译也可以。

  11. 描述：描述应传达其他信息，如软件弱点类别及其可以在什么条件下被利用的信息，可能包括外部参考，如CWE分类器。

  12. 影响：通常与技术影响相关，例如机密性、完整性或可用性的损失，这些信息可能在CVE或CVSS子分数中找到。

  13. 严重性：使用标准的严重性评分，如CVSS，或供应商使用的严重性评分，如果使用，提供漏洞的严重性的可量化度量。不管您对CVSS评分有何看法，这是整个行业衡量严重性的方式，并且是最可能使用的指标。

  14. 修复措施：VDR应指示如何修复漏洞、打补丁或重新配置，或者至少应提供一个允许减轻漏洞风险的解决方法。在许多情况下，初始VDR可能不包括修复指南，但应尽快进行更新，一旦了解如何减少利用风险。

  15. 参考资料：可能存在许多外部参考资料，例如CVE、供应商知识库、产品页面、研究人员博客或其他有用的支持信息，这些信息在VDR内引用。

  16. 信誉：应该给予参与检测、研究、减轻漏洞及其他漏洞报告生命周期阶段的研究人员和组织适当的信誉。这是完全自愿的。

  17. 联系信息：为产品用户提供足够的信息，以便联系供应商获取更多信息。

  18. 修订历史：应非常清楚地说明这是否是原始安全公告还是更新。如果是更新，则应保持版本历史，并与VDR内的日期和时间信息一致。

  19. 使用条款：最后，安全公告是有许可的文章，应包含版权信息和使用条款。例如，在许多情况下，只允许许可产品所有者使用，或者可能完全禁止重新分发。

你会注意到，虽然漏洞披露报告（VDR）通知用户存在问题，但它并不告知用户某事并非问题。这是一个重要的区别，因为与VDR类似，SBOM的分析报告可能会产生大量误报。通过在现有的VDR格式中加入VEX语句（例如CycloneDX构建漏洞报告数据模型的方式），可以简洁而一致地确定漏洞的存在，并告知用户该漏洞是否构成问题。

漏洞未构成问题的原因有很多。根据Contrast Security的行业报告（www.contrastsecurity.com/security-influencers/2021-state-of-open-source-security-report-findings），软件中使用的80%开源组件实际上从未在产品的执行流程中调用。因此，我们可以认为，在开源组件中发现的后续漏洞中，有 80% 可能同样不存在风险，因为它们从未被使用过。这显然是一个卫生问题，也可能是代码膨胀和效率问题，并且很可能增加了攻击面，但这可能并不代表软件真正存在漏洞。

其次，许多供应商会“回溯”安全修复，即在代码库中插入其他的代码或其他形式的措施防止漏洞利用，但是组件的版本号却从未更新。这意味着，任何针对 NVD 的分析，如果要查找特定版本来告知漏洞，可能会查找不同的组件。目前，NVD中没有唯一标识软件文件的概念，只有通用平台枚举 (CPE)，即供应商、产品、版本、架构和类似元数据的描述。

最后，配置也很重要。在许多情况下，软件只有在以非常特定的方式进行配置时，或者在使用软件默认情况下不附带的特定共享库时，才会出现漏洞。当出现这些情况时，VEX可以提供额外的上下文信息，告知用户这些情况并不会转化为实际的可利用风险。

虽然 VEX 被认为是机器可读的文档，但我们认为它比 SBOM 更具有动态性。SBOM 大多是静态文档，与特定的软件版本相关联，而其漏洞状态会随着时间的推移而改变，如发现新漏洞、发现无法利用的漏洞、通过缓解措施修复的漏洞等。我们认为这可能更适合基于应用程序接口（API）的发布模式，在这种模式下，漏洞状态更新不仅是机器可读的，而且还能随着有关漏洞状态的新信息被发现而通过自动化方式持续发布。

No Comments
Back to top