第四章 软件物料清单的兴起

本章讨论了 SBOM 概念的起源，包括早期的失败和成功，以及为其成熟做出贡献的美国联邦和行业组织。我们还将深入探讨 SBOM 格式、特定字段以及漏洞利用交换 （VEX） 出现的一些细节

• 4.1 法规中的SBOM:失败和成功
• 4.2 行业努力：国家实验室
• 4.3 SBOM格式
• 4.4 行动建议
• 4.5 将 SBOM 与其他证明结合使用
• 4.6 总结

4.1 法规中的SBOM:失败和成功

尽管行业内可能存在一系列与软件物料清单 (SBOM) 相关的动态，但达到当前这一点是经过了多年的努力，涉及了各种政府和行业组织的参与。最值得注意的是，最近的 SBOM 动态发生在国家电信和信息管理局 (NTIA) 的推动下。

也就是说，虽然NTIA以及Log4j和SolarWinds等事件可能在最近围绕SBOM的发展势头中发挥了关键作用，但早期涉及Apache Struts 2和openssl2相关漏洞的事件是由于引入了立法，如2014年网络供应链管理和透明度法案(www.congress.gov/bill/113th-congress/house-bill/5793/text)。

该法案侧重于使用第三方和开源软件(OSS)代码为美国政府开发或购买的软件、固件和产品的完整性，并要求在联邦政府的软件、固件或产品合同中包含组件清单或物料清单。在这一努力中，早期的重要先驱之一是行业领袖 Joshua Corman，他曾在多家行业领先的私营公司和 CISA 工作，他还创立了“I am The Cavalry,”该团体关注数字安全、公共安全和人类生命的交集。

《2014 年网络供应链管理和透明度法案》因行业对其呼吁增加产品中软件组件透明度的抵制而未能完全实现。然而，这表明，尽管在撰写本文时 SBOM 受到广泛讨论，但这一话题实际上已经被讨论和期望了近十年之久。

其他值得注意的例子包括2017年6月发布的《医疗保健行业网络安全任务组报告》，该报告呼吁制造商和开发人员创建一个“物料清单”以描述医疗设备中的组件（www.phe.gov/Preparedness/planning/CyberTF/Documents/report2017.pdf）。

NTIA:宣传SBOM的必要性

近期在联邦领域的软件物料清单（SBOM）工作的推广由NTIA（国家电信和信息管理局）主导。自2018年起，NTIA一直致力于推动软件组件透明度。2018年7月，NTIA召开了多方利益相关者会议（http://ntia.doc.gov/federal-register-notice/2018/notice-071918-meeting-multistakeholder-process-promoting-software），讨论了软件组件透明度、挑战及潜在解决方案。

这些早期会议由当时担任NTIA网络安全倡议主任的Allan Friedman博士参与。Friedman自早期以来一直是围绕SBOM和软件透明度行业对话中的重要人物，与上文提到的Joshua Corman一样，现在他在网络安全和基础设施安全局（CISA）担任高级顾问和策略师，依然在帮助推动软件透明度和SBOM进程。

NTIA认识到现代软件是由许多来自开源和商业行业的组件和库构成的（http://ntia.gov/blog/2018/ntia-launches-initiative-improve-software-component-transparency）。它也承认创建和维护这些组件及其相关漏洞的清单非常具有挑战性。该组织及其多方利益相关者社区一直致力于理解改进软件组件清单、实践以及相关政策和市场挑战的方法。

在推动软件透明度和软件物料清单（SBOM）的过程中，NTIA（国家电信和信息管理局）发布了大量相关文件和指导（可在http://ntia.gov/SBOM找到）。这些文件涵盖了介绍SBOM、提高对SBOM的理解、SBOM实施以及相关技术资源等内容。

根据《网络安全行政命令》中的第4节“加强软件供应链安全”，子节(F)要求NTIA在《网络安全行政命令》发布60天内公布SBOM的最低要素。随后，NTIA在2021年7月发布了《软件物料清单（SBOM）最低要素》（http://ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf）。该指导文件确立了SBOM的最低要素，定义了如何思考这些最低要素的范围，并描述了软件供应链透明度的SBOM用例。NTIA的指导文件论证了系统共享和组件元数据的跟踪有助于支持软件供应链的透明度。

在本节中，我们将分解NTIA的最低要素指导。他们的指导包括并详细说明了三类要素:

■数据字段
■自动化的支持
■实践和流程

NTIA的指导意见指出，每个软件都可以表示为一个层级树结构，其中包含组件和子组件。这些组件包括从其他来源获取的第三方组件，以及作为独立软件单元存在的一方组件。三个元素类别中，第一个是数据字段，包含了应跟踪和维护的每个组件的基本信息。这些数据字段的主要目的是帮助组织在整个软件供应链中跟踪这些组件。NTIA定义了一组基准数据字段集合，如表4.1所示。

组织可以使用这些数据字段将组件与其他数据源进行映射，这一过程被称为“富集（enrichment）”。从表4.1可以看出，目的是提供诸如组件供应商、组件名称和版本等基本信息，然后将组件与相关的上游组件关联起来。这通常被称为依赖关系，因为大多数软件包括第三方代码，导致一方和第三方代码在组件和应用程序中形成依赖关系。值得注意的是，NTIA的指南讨论了一些挑战，如供应商和软件供应商之间的不同版本管理方法。

除了数据字段，NTIA为SBOM确定的另一个核心组成部分是自动化支持的需求。SBOM普及和采用的怀疑者指出，需要强大的工具和自动化支持来使SBOM的采用在大规模情况下准确且成功。自动化支持将使组织能够将SBOM集成到其现有的漏洞管理、供应链风险管理和网络安全计划中。NTIA的SBOM指导讨论了三种主要的SBOM格式，将在“SBOM格式”部分中涵盖。

最后，NTIA的SBOM指导涵盖了实践和流程，重点是SBOM在组织操作和采用中的使用机制。主要讨论的实践和流程包括以下内容：

■频率
■深度
■已知的未知
■分发和交付
■访问控制
■错误纠正

频率（Frequency）与新SBOM的创建频率有关。NTIA的指导意见强调，每次新建或发布软件时，必须创建新的SBOM。如果软件供应商了解到组件的附加细节，包括纠正之前传输的错误，也需要创建新的SBOM。

深度（Depth）指的是SBOM在依赖树中应该深入到的层次。NTIA的指导意见指出，SBOM至少应包含所有顶级组件，并列出传递依赖项。传递依赖项可以定义为软件运行、编译或测试所必需的组件。虽然列出所有传递依赖项并不总是实际可行，但指导意见确实指出，如果必要，应该提供足够的信息以查找这些传递依赖项。在深度方面，不同的组织和行业可能有不同的要求，甚至由于内部政策或法规要求而有所不同。SBOM的消费者会试图为其软件产品指定深度，特别是在涉及专有软件供应商和合同、法律方面的问题时。

已知的未知（Known Unknowns）的概念围绕着SBOM作者在进一步依赖关系的沟通中的清晰性。有些情况下并非所有依赖项都是已知的，这在指导意见中被称为已知未知。SBOM作者可以传达数据已知是不完整的，告知软件消费者在其软件使用中可能存在未解决和未知的风险。

分发和交付（Distribution and Delivery）涉及确保需要知晓SBOM的实体能够及时获取，并具备适当的权限和访问控制。SBOM采用的这一领域仍在发展中，无疑会采用多种方法。分发和交付的方法也会因所涉及的软件和系统的性质而异，例如嵌入式系统或在线服务，每种方式的分发和部署给终端消费者的方式都不同。对于美国政府，《网络安全行政命令》规定要求，即“为每个产品提供给购买者一个软件物料清单（SBOM），直接提供或发布在公共网站上”。

访问控制是SBOM采用和使用中至关重要的一部分。在软件生产商之间持续标准化SBOM交付实践的过程中，对于数据共享的容忍度会有所不同。一些可能希望将信息公开和开放，例如开源维护者或一些私人软件公司，如JupiterOne（http://jupiterone.com），他们已经将其SBOM发布在http://jupiterone.com/sbom。然而，一些软件供应商，特别是那些认为其SBOM敏感或具有特定客户需求的供应商，如国防或国家安全社区中的供应商，可能希望只在特定条款和条件下并在特定的访问控制下提供此信息。这是一个将继续发展和成熟的SBOM和软件透明度领域。

最后，指南中提到了容错实践。这意味着允许遗漏或错误的存在。整个行业的软件供应链安全内部实践仍在成熟中，错误和疏忽肯定会发生。这是一条双向的路，软件生产者在适当的时候可以提供额外的见解或澄清，软件消费者也理解初期可能不完美。通过这种相互合作，可以改善整个软件供应链的卫生状况。

NTIA对SBOM的对话和采用的贡献远远超出了最低元素指南，如前所述，包括澄清一些误解（http://ntia.gov/files/ntia/publications/sbom_myths_vs_facts_nov2021.pdf）、解释视频和常见问题解答（http://ntia.gov/files/ntia/publications/sbom_faq_-_20201116.pdf）。他们最常被引用的出版物之一是SBOM框架文件（http://ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf），该文件涵盖了从软件透明性和系统风险相关的问题声明、什么是SBOM、SBOM流程和使用案例、以及NTIA用来制定其指南的多利益相关者过程概述。

尽管NTIA作为促进SBOM采用和更广泛的软件供应链透明性的基本催化剂发挥了作用，这一努力已经继续发展，现在由CISA支持（http://cisa.gov/sbom）。毫无疑问，这一部分是由于Allan Friedman从NTIA转移到CISA，鉴于他一直是SBOM采用和使用的最积极的倡导者之一。CISA努力通过其社区参与、开发和进展活动，将NTIA的早期努力推进到更远的地方，最终目标是实现SBOM在行业中的规模化和运营化。

截至撰写本文时，CISA最重要的SBOM活动和社区参与是2021年12月举办的SBOM-a-Rama。这是为期两天的活动，第一天重点讨论了SBOM能力的现状，第二天则重点讨论了使SBOM的采用和使用更加可扩展和有效。参与者包括一系列公共和私人部门的领导者，如国会议员James Langevin、长期SBOM和软件透明性倡导者Josh Corman，以及来自开放世界应用安全项目（OWASP）、Linux基金会等行业组织的代表。

讨论包括基础性话题，如什么是SBOM及其重要性、领先的SBOM格式如SPDX和CycloneDX、以及在医疗保健、能源和汽车工业中的早期概念验证（PoC）努力。两个活动日的录音和演示文稿可在http://cisa.gov/cisa-sbom-rama上获得。在后续章节中，我们还将深入探讨如领先的SBOM格式等话题。

4.2 行业努力：国家实验室

为应对特定行业的需求，几个概念验证（PoC）小组作为NTIA SBOM研讨会的一部分被建立。医疗PoC至少经历了三次迭代，此外还成立了汽车PoC和其他几个小组。这些小组中有些对公众开放，有些仅限邀请。在许多情况下，即使是公共工作组也对解决方案提供商如何支持这些工作有限制。爱达荷国家实验室 (INL; http://inl.gov/sbom-poc) 成立了一个以能源用例为重点的 PoC，最初由 INL 的 Virginia Wright 和 Tom Alrich 组成，Tom Alrich 是著名的供应链和北美电力可靠性公司关键基础设施保护 (NERC CIP) 合规顾问和行业博客作者，现在被许多人视为 SBOM 专家。Tom的角色现已被Allan Friedman取代，但该工作组对关键基础设施相关问题的教育和讨论的开放性值得一提。

能源计划委员会整理的资料是仅次于 NTIA 官方网站（www.ntia.gov/SBOM），可供公众使用的保存最完好的资料。过去会议的完整录音以及许多其他参考资料、链接和与SBOM相关的主题均可获取。虽然重点是能源使用案例，但这项工作的基础教育方面为任何希望熟悉这些主题的人提供了一个丰富的起点。

在能源部（DoE）的支持下，国家实验室从研究和思想领导的角度发挥着宝贵的作用，重点关注从气候变化到绿色能源进步，再到网络安全的方方面面。例如，一个名为“优化安全与能源管理的区块链”（http://netl.doe.gov/BLOSEM）的研究计划重点关注区块链技术的多种使用案例，其中许多案例都与供应链安全有关。一些值得注意的的例子如使用区块链识别交付给公用事业的设备是否是预期设备，配置和设定值的完整性检查，以及 SBOM 和硬件物料清单（HBOM）的安全分发和区块链互操作性。

这项工作由 "电网现代化计划 "发起，该计划是能源部的一项合作计划，由电力输送和能源可靠性办公室以及能源效率和可再生能源办公室共同资助，并由国家可再生能源实验室（NREL）和国家能源技术实验室（NETL）负责执行。除了这两个实验室，还有许多其他行业合作伙伴，包括太平洋西北国家实验室（PNNL）等。PNNL正在利用他们在电网网络安全和运行联邦资助的电力区块链方面的专业知识和经验共同领导区块链用例的开发。

此外，通过 "弹性工业控制系统网络测试"（CyTRICS）计划 (http://cytrics.inl.gov)，我们致力于确定如何最好地表示系统的各个组成部分，包括硬件和软件。这些努力在某种程度上是封闭的，只对产品供应商开放，但这里创建的生态系统为作为系统描述符的 SBOM 主题提供了一个基础用例。此外，CyTRICS为关键基础设施的产品安全和供应链信息创建了一个通用框架和存储库，虽然尚未过渡到商业使用，但它是公私合作如何为软件透明度主题的创新创造机会的一个范例。

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）的发布模式，在这种模式下，漏洞状态更新不仅是机器可读的，而且还能随着有关漏洞状态的新信息被发现而通过自动化方式持续发布。

4.4 行动建议

正如我们所讨论的，SBOM 计划从 NTIA 转移到网络安全基础设施安全局 (CISA)，与此同时 SBOM 的倡导者和领导者 Allan Friedman 也转移到了 CISA。自此之后，CISA 在 2022 年发布了另外两份 VEX 文档。一份是 VEX 用例文档，另一份是漏洞可利用性交换 (VEX) 状态说明 (http://cisa.gov/sites/default/files/publications/VEX_Status_Justification_Jun22.pdf)。

VEX 用例文档提供了 VEX 文档的最小数据元素，就像 NTIA 为 SBOM（与网络 EO 相关）定义的最小元素（参见表 4.1）一样。在本指南中，它指出 VEX 文档必须包含 VEX 元数据、产品详细信息、漏洞详细信息和产品状态。这些产品状态详细信息包括有关产品漏洞的状态信息，可以是“未受影响”、“受影响”、“已修复”或“正在调查中”。

VEX 状态说明随后侧重于 VEX 文档的要求，即包含说明 VEX 文档创建者为何选择断言产品状态为“未受影响”（如果他们确实做出了选择）的说明。这允许供应商提供产品未受漏洞影响的理由。选项包括组件或易受攻击的代码不存在、易受攻击的代码无法被对手控制或代码不在执行路径中，最后，产品中已经存在内联缓解措施。

VEX 是帮助 SBOM 采取行动的关键下一步，它提供了产品供应商关于其产品中存在的漏洞可利用性的背景见解和断言。通过使用 VEX 文档定义的最小元素及其相关的“不受影响”理由字段（如果适用），软件生产商能够让软件消费者做出风险知情决策，以推动他们的漏洞管理活动，作为更广泛的网络安全计划的一部分。

4.5 将 SBOM 与其他证明结合使用

SBOM 只是一种证明；它是一份包含其内部声明证据的文件。它通过附加到这些声明上的加密验证的质量和真实性得以强化。因此，通过数字签名将 SBOM 连接在一起的概念变得可行，这使得即使是不完整的 SBOM 也能提供价值，因为它们可以与其他 SBOM 结合，每个额外的证明为第一个 SBOM 增加保证信息。然而，我们希望探索其他一些可以与 SBOM 一起包含的证明类型，以构建完整的证据包。

来源真实性

来源真实性是 NERC CIP 合规性要求（CIP 010 和 013）重点关注的一个概念，其理念是您可以使用文件哈希或代码签名材料验证文件本身，但同样重要的是验证对文件来源的信任。它试图回答诸如文件来自哪里？它是受信任的实体吗？它是我们认为的同一个实体吗？该实体是否以某种意想不到的方式受到损害或修改？

解决方案提供商开始解决此问题的一些常见方法是查看与检索软件文件的 Web 域相关联的传输层安全性 (TLS) 证书信息，并确保证书有效，同时确保证书受信任。它是否有合理的有效期？它最近是否以不寻常的方式发生变化？公司名称是否符合预期？也许昨天是 Microsoft Corp.，但今天是 Microsoft, Inc.。这可能是需要调查的事情。最重要的是，创建正常基线和识别异常有助于组织识别来源的真实性或试图破坏它的行为。

DNS 信息是可能需要验证的其他信息。域名是否已更改为一组新的 IP 地址或地理定位到世界不同地区？对于可能根据互联网健康状况或请求者位置为来自世界各地的流量提供服务的内容交付网络 (CDN)，很难以高度的信心进行探索。有些人甚至提出，互联网路由劫持（例如多年来发生的 BGP 劫持）可用于提供恶意文件。这也变得非常难以验证，但这些场景对于威胁模型来说相当有趣。

通过根据这些标准进行检查并生成可以加密绑定到正在生成的 SBOM 的证明文件，我们可以进一步丰富 SBOM 中已经包含的出处数据。

构建证明

关于构建环境的证明对于增强软件工件的保证也非常有用。这些可以包括有关构建系统本身的信息，甚至可以验证构建活动中使用的流程或控制。

考虑一下，在软件工件供应链级别 (SLSA) 框架中，攻击目标之一是构建系统。如果攻击者可以破坏构建系统，您如何信任在该服务器上构建的任何东西？理想情况下，构建服务器与生产服务器正确隔离，并作为极其敏感的资产进行适当强化。验证服务器是否符合强化指南，例如安全技术实施指南 (STIG)，它们是安全模板，可提供额外的保证，确保构建服务器不太可能成为入侵源。有些供应链供应商（例如 TestifySec）将这些证明用作其自动化的一部分，甚至可以应用构建策略，要求通过 STIG 检查才能成功构建。

同样，您可能已经实施了一些流程，例如需要多个开发人员同意代码签入，然后才能继续构建。这些构建证明可以捕获上游流程所需的任意数量的安全要求，以用作构建流程的安全门，以及可用于验证高保证软件构建的证明。支持这一点的工具的一个例子是 OSS 项目“Witness”，它有助于创建证明并执行策略以确保软件供应链的完整性。（www.testifysec.com/blog/attestations-with-witness）

依赖管理和验证

随着开发人员对来自外部来源的软件组件的使用不断增加，管理这些库、包、组件或依赖项（通常称为依赖项）的需求也随之增加。正如我们所讨论的，依赖项通常被集成以节省开发人员和组织的时间和资源，并加快上市/任务的时间并加速创新。不可避免的现实是，您使用的依赖项越多，您必须管理的依赖项就越多。

依赖项通常在两种情况下讨论，即直接依赖项或传递依赖项。顾名思义，直接依赖项是您的应用程序直接引用和使用的组件。传递依赖项是您的依赖项本身使用的组件，从而创建了对依赖项的依赖关系。这两种类型的依赖项都有其相关的风险和注意事项。虽然好处很多，但随着直接或传递依赖项数量的增加，潜在风险也在增加。当然，其中包括许可问题，但从安全角度来看，它们还包括漏洞、恶意代码和攻击媒介的可能性。

Endor Labs 的《依赖管理现状》等报告指出了这一点。报告发现，95% 的漏洞存在于传递依赖项中，这增加了开发人员评估和解决的难度。此外，还有一项发现，50% 的最受欢迎的软件包在 2022 年没有发布，30% 的软件包的最新版本在 2018 年之前，导致代码陈旧且可能存在漏洞 (www.endorlabs.com/blog/introducing-the-state-of-dependency-management-report)。

使用许多依赖项还存在管理开销方面的挑战。开发社区本身使用了一个可爱的术语“依赖地狱”，因为安装依赖于其他特定版本软件包的软件包会带来挫败感。问题是由于多个软件包依赖于相同的共享组件但版本不同或存在兼容性问题的情况而发生的。

每个依赖项或组件都有其问题。包括库被废弃且未被维护、代码编写不当、没有文档，当然还有易受攻击的代码，如果维护人员仍然存在或目前是项目的积极参与者，他们可能会或可能不会修复这些代码。

话虽如此，组织可以采取一些最佳实践来减轻与依赖项管理相关的一些挑战和风险。这些建议包括确定哪些依赖项必须先于其他依赖项更新，使用诸如对项目的关键性或安全风险等因素。另一个建议，当然，说起来容易做起来难，是通过完全删除来最小化未使用的依赖项，只保留代码中需要的依赖项。不这样做会导致代码臃肿、攻击面增加和管理开销挑战。在许多情况下，您还可以自动更新软件依赖项，从而最大限度地减少与依赖项管理相关的手动工作量。在这种情况下，最受欢迎的示例之一是 Dependabot，它有助于自动更新各种编程语言（如 Ruby、JavaScript、Python 和其他几种语言）的依赖项。 Dependabot 得到了 GitHub 和 GitLab 等最大的持续集成平台的支持。

除了自动化之外，组织还应制定软件依赖关系管理策略。为组织的开发人员制定依赖关系管理指南可以确保整个组织遵循标准化方法，并可以实施治理，如 Microsoft 的 S2C2F 或 NIST 的软件供应链指南等框架中所述，我们将在第 6 章“云和容器化”中介绍。制定标准化的政策和流程有助于监控安全问题、提高应用程序性能和确保许可合规性。

软件依赖关系不会消失，而且整个行业对软件包、库和组件的大规模重用只会加速。这不可避免地导致需要适当的软件依赖关系管理和验证流程。未能实施结构化方法将导致安全风险得不到解决，从而给开发团队带来负担，这可能会阻碍交付并为许可违规敞开大门。

Sigstore

软件供应链安全的一个基本方面涉及对完整性、透明度和保证的需求。这就是 Sigstore 发挥作用的地方。正如本书中提到的那样，我们看到了对软件供应链的极大关注，尤其是在 SolarWinds 和 Log4j 等重大事件之后。NIST 在其网络安全供应链风险管理 (C-SCRM) 800-161 文档以及 CISA 中发布了网络安全 EO 和更新指南。我们还看到了白宫的关注，白宫于 2022 年初主办了软件供应链安全峰会。在那次峰会之后，Linux 基金会和 OpenSSF 发布了 OSS 安全动员计划，该计划的重点是使用数字签名来增强对软件供应链的信任。这项任务主要集中在采用和发展一种名为 Sigstore 的技术上。

Sigstore 是用于签名、验证和保护软件的标准。正如我们所讨论的，软件的使用在每个垂直行业和业务类别中都无处不在。然而，尽管我们使用软件的方式已经并正在改变世界，但确保我们在整个生态系统中使用的软件具有通常所需的完整性水平的方法却很少。软件供应链通常缺乏数字签名的使用，而当它没有使用数字签名时，它通常使用传统的数字签名技术，而这些技术在自动化、扩展和审计方面可能具有挑战性。

Sigstore 最初于 2021 年 3 月由 Red Hat 和 Google 合作发布，并作为 Linux 基金会的一个项目发布，旨在解决软件来源或构建方式的问题。Sigstore 特别致力于改善软件供应链的完整性和验证活动。

正如 Sigstore 联合创始人 Dan Lorenc 所说，Sigstore 是“为软件开发人员提供的免费签名服务，通过轻松采用由透明日志技术支持的加密软件签名来提高软件供应链的安全性。”正如 Sigstore 项目创始人、Red Hat 的 Luke Hinds 在博客“Sigstore 介绍”(https://next.redhat.com/2021/03/09/introducing-sigstore-software-signing-for-the-masses) 中所写，该项目基于一些真实的假设，例如很少有项目实施代码签名，以及密钥管理是一项困难的活动。从那时起，该小组问了自己一系列“如果”问题，例如“如果密钥不需要撤销或存储会怎样？”以及“如果所有签名事件都在安全媒介上公开，会怎样？”

采用

自推出以来，Sigstore 的行业采用率和兴趣度不断提高。尽管 Sigstore 是在 2021 年初才发布的，但它已经引起了一些最大的 OSS 项目的关注，其中之一就是 Kubernetes 项目。Kubernetes 是市场上规模最大、采用最广泛的容器编排平台。它宣布将以 Sigstore 为标准，并在其 1.24 版本中使用 Sigstore (https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73)。这使 Kubernetes 的消费者能够确保他们使用的发行版是用于消费的。除了这一认可之外，如前所述，OpenSSF 的 OSS 安全动员计划有一个专门用于数字签名的部分，重点关注采用和使用 Sigstore 作为软件供应链完整性缺口的解决方案。 2022 年初，Sonatype 宣布 Maven Central 将采用 Sigstore 作为解决软件供应链中出处问题的解决方案 (https://blog.sonatype.com/maven-central-and-sigstore)

Sigstore 组件

那么，Sigstore 到底是什么？它是如何工作的？为什么它很重要？Sigstore 的成立是为了帮助解决 OSS 供应链中现有的一些空白，以及我们如何处理完整性、数字签名和 OSS 组件的真实性验证。这至关重要，因为据估计，90% 的 IT 领导者都在使用 OSS（请参阅 www.soocial.com/open-source-adoption-statistics），组织优先考虑聘用 OSS 人才，而且我们已经看到了几起值得注意的软件供应链事件。Sigstore 汇集了多种 OSS 工具，如 Fulcio、Cosign 和 Rekor，以协助进行数字签名、验证和代码来源检查。代码来源是指拥有一条保管链的能力，显示代码的来源和来源。 Uber 隐私和安全团队在 https://medium.com/uber-security-privacy/code-provenance-application-security-77ebfa4b6bc5 上发表了一篇精彩的博客，讨论了他们如何处理代码来源路径。

要解压一些核心 Sigstore 组件，让我们从 Fulcio (https://github.com/sigstore/fulcio) 开始。Fulcio 是一个专注于代码签名的根证书颁发机构 (CA)。它是免费的，颁发与 OpenID Connect (OIDC) 相关的认证，并且经常使用开发人员已经关联的现有标识符。随着云原生架构和容器部署的快速采用和增长，对容器进行签名已成为一项关键的安全最佳实践 (www.csoonline.com/article/3656702/managing-container-vulnerability-risks-tools-and-best-practices.html)。密钥管理是一项繁琐的活动，通常由 CSP 或第三方提供商在云空间中作为托管服务提供。 Sigstore 通过支持 Cosign 的方式帮助缓解部分复杂性，并通过使用“无密钥签名”或使用临时密钥或临时密钥缓解部分密钥管理挑战（www.chainguard.dev/unchained/zero-friction-keyless-signing-with-kubernetes#:~:text=Keyless%20enables%20this%20signing%20process,Let's%20Encrypt%20did%20for%20TLS）。尽管使用了临时密钥，您仍然可以通过 Fulcio 的时间戳服务确保签名的有效性（www.chainguar.dev/unchained/busting-5-sigstore- myths）。

这就是 Cosign 的作用所在，因为它支持各种签名选项，并且可以无缝支持生成密钥对和签名容器工件以存储在容器注册表中。它使云原生环境能够根据公钥验证容器，并确保容器由受信任的来源签名。在构建期间对映像工件进行数字签名并验证这些签名是云原生计算基金会 (CNCF) 云原生安全白皮书 (https://github.com/cncf/tag-security/blob/main/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) 中强调的一项关键安全最佳实践。

接下来是 Rekor (https://docs.sigstore.dev/rekor/overview)，它是一个不可变且防篡改的账本，是软件维护和构建活动的一部分。它使软件消费者能够检查元数据并对他们正在使用的软件及其整个生命周期中涉及的活动做出风险知情决策。回到我们之前关于软件来源的观点，开发人员可以使用 Rekor 通过透明日志为软件来源做出贡献。

另一个值得注意的方向是新兴的指南，例如软件制品的供应链等级（SLSA；https://slsa.dev/spec/v0.1/levels）和 NIST 安全软件开发框架（SSDF）（https://csrc.nist.gov/publications/detail/sp/800-218/final）。SLSA 第 3 级强调需要审计软件来源和完整性，这一点 Sigstore 支持，如前所述。SSDF 中提到的具体实践也指出了提供来源和验证机制的必要性。这很重要，因为联邦政府正逐步要求向政府销售软件的生产商按照 SSDF 中的实践进行证明（www.nextgov.com/cybersecurity/2022/02/nist-suggests-agencies-accept-word-software-producers-executive-order/361644）。通过采用 Sigstore，您可以使您的组织与这里讨论的新兴标准和最佳实践保持一致，并减轻可能导致安全事件及相关影响的关键软件供应链风险。

提交签名

在现代源代码管理中，Git 通常是事实上的选择系统。Git 允许各种实体（如作者和提交者）提交提议的更改。通常，这些实体是同一个人，但并非总是如此。也就是说，在许多情况下，通过设置用户名或电子邮件，冒充另一个提交者可能很简单。因此，特别是在敏感环境中，签署 Git 提交已成为一种最佳实践，这确保了你可以证明你是某段代码及其元数据（如时间戳）的作者。签名的提交虽然不能解决所有问题，但可以减轻一些潜在风险，例如前雇员试图通过冒充同事引入恶意代码或创建恶意拉取请求，而假身份有良好声誉。

签名提交不能阻止恶意行为者冒充他人，因为他们仍然可以尝试假冒身份，但没有数字签名将迅速引起那些足够关注的人的怀疑。

Git 通常使用 GNU Privacy Guard（GPG）等方法来促进签名提交。GPG 在 Git 中的工作原理是允许你将公钥上传到流行的 Git 平台（如 GitHub 和 GitLab），然后使用你的私钥签署提交。GitHub 提供了管理提交签名和签名提交的文档（https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits）。

SBOM 的批评和关注

如果我们不讨论一些在整个行业中 SBOM 采用过程中的常见批评、关注和挑战，我们将是不负责任的。

这些关注中最集中的来源之一是 NTIA 发布的 SBOM FAQ(www.ntia.doc.gov/files/ntia/publications/sbom_faq_-_fork_for_october_22_meeting.pdf)中的“常见误解与关注”部分，但其他行业的其他人也通过各种渠道提出了此类关注。

让我们来看看 NTIA 文件中列出的常见误解和担忧，以及其他一些误解和担忧.

攻击者的可见性

围绕 SBOM 的一个担忧是它们可能作为“攻击者的路线图”，这是它们常被提及的。这可以更广泛地描绘为围绕通过模糊性提供安全的辩论，这在网络安全行业已经持续了一段时间，双方都有合理的观点。通过模糊性提供安全通常总结为通过保密作为提供系统或组件安全的主要方法，而不是具体的安全控制和合理的安全工程。我们可以引用长期行业思想领袖 Daniel Miessler 的观点，他区分了良好的模糊性与糟糕的模糊性，指出“判断模糊性是好是坏的关键在于它是作为良好安全的层次使用，还是作为其替代品使用。前者是好的，后者是坏的。”（https://danielmiessler.com/study/security-by-obscurity）
  Miessler 的观点是，保密在某些情况下肯定是有益的，但它不是合理安全工程的替代品。行业中的其他人认为 SBOM 可用于攻击 API，例如 Dan Epp 在其博客中所讨论的“Can SBOM Help You Attack APIs?”（https://danaepp.com/can-sbom-help-you-attack-apis）但即便如此，该文章也指出 SBOM 帮助防御者了解它们是否易受攻击以及在何处，这比进攻方面的担忧更重要，因为攻击者无论有无 SBOM 都会不可避免地寻找这些弱点。
  针对 SBOM 是否为“攻击者的路线图”的问题，NTIA 指出，恶意行为者不需要 SBOM，因为事先了解不是攻击的前提条件。NTIA 还指出，恶意行为者已经有工具来识别软件组件，不受法律约束，因此可以这样做，而不像守法的道德用户。NTIA 声明，SBOM 将“拉平竞争环境”，为防御者提供他们已经拥有的同样的见解和透明度。恶意行为者能够使用二进制分析工具来理解软件组成和组件组成。虽然这点没有争议，但拥有 SBOM 将使软件消费者更好地理解与其使用的软件相关的初始风险，以及现有和新出现的漏洞。通过这样做，SBOM 帮助防御者了解风险并采取适当行动。

知识产权

围绕 SBOM 讨论的另一个常见担忧是知识产权和源代码。NTIA 反驳了这一点，指出 SBOM 不要求组织披露源代码，源代码是否共享由软件提供商自行决定。SBOM 专注于构建软件的组件，而不是披露源代码本身。软件组件代表部分情况，但不是软件实际运行的完整路线图。NTIA 的指南指出，了解第三方成分和整个执行配方之间存在显著差异，此外第三方组件不属于使用它们的软件供应商的知识产权，而是属于创建这些组件的上游实体，并受其创建时分配的任何适当许可证的约束。值得指出的是，尽管推动增加 SBOM 采用，但所有相关来源都建议适当保护 SBOM 本身，符合最低特权访问控制和知情即需的最佳实践。像 OMB 的 22-18 备忘录这样的来源，要求联邦机构可能需要从软件供应商获取像 SBOM 这样的工件，也要求机构在这些工件未公开发布时安全地存储它们。

工具和运营化

围绕广泛采用 SBOM 最有效的担忧之一是缺乏广泛可用的工具来促进创建、分发、摄取、丰富、分析和运营化 SBOM。现在许多人同意有足够的工具来帮助创建 SBOM，并且我们在整本书中多次提到它们。然而，撰写本文时，用于处理附加活动（如分发、摄取、丰富和分析）的工具仍在成熟中。如前所述，国土安全部（DHS）和网络安全基础设施安全局（CISA）等组织正在努力创新这一领域，以及商业领域，我们看到一系列商业公司正在进行研发投资和产品以填补这一空白。值得注意的例子包括 ChainGuard，该公司由前 Google 工程师创立，在 2022 年筹集了 5000 万美元。其他值得注意的例子包括 Endor Labs、TestifySec 和其他几家公司，包括行业领导者 Google，他们正在为组织提供帮助管理其 OSS 摄取和使用的创新软件供应链重点管理服务。再次引用美国联邦领域，OMB 的 22-18 备忘录还要求政府“建立一个集中存储库，用于软件证明和工件”，其中将包括 SBOM。
  虽然围绕 SBOM 的担忧（如对攻击者的可见性、知识产权、工具和能力的成熟度）可能是有效的，但作为一个行业，我们普遍同意，透明度的推动及其带来的好处超过了这些担忧。这并不是说这些担忧完全没有价值，不应该被解决，但继续走不透明的软件生态系统的道路，无法了解底层软件组件及其相关风险和漏洞已不再可行。

4.6 总结

在本章中，我们讲述了 SBOM 的兴起，以及其从 NTIA 等机构开始的早期努力，现阶段则转移至美国联邦的 CISA。我么讨论了不同的 SBOM 格式，还提到了 VEX 概念的出现，这有助于减少因 SBOM 漏洞带来的一些问题。我们还探讨了一些常见的 SBOM 批评和关注点，并指出随着行业对 SBOM 的采纳和实施，这些领域将继续发展。