美国商务部发布软件物料清单 (SBOM) 的最小元素（上）
聚焦源代码安全，网罗国内外最新资讯！
编译：代码卫士
数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。
随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。
为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。
注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。
美国总统在2021年5月份发布第14028号行政令，要求美国商务部在60天内协同美国国家通信和信息管理局 (NTIA) 发布软件物料清单 (SBOM) 的“最小元素”。如下是对美国商务部所发布报告的编译。
SBOM 是包含多个软件构建组件详情及供应链关系的正式记录。除了设置这些最小元素外，本报告还定义了如何思考最小元素的范围，描述了SBOM用例以便提高软件供应链中的透明度，另外提供了未来的SBOM发展。
SBOM 为生产、购买和运营软件的人员提供信息，有助于他们了解供应链并从中获得多重好处，其中最值得注意的好处就是追踪已知的和新出现的漏洞和风险。SBOM 虽然无法解决所有的软件安全问题，但将形成基础的数据层，是后续安全工具、实践和保证的构建基础。本文档中所述“最小元素“是指支持基础SBOM功能的重要信息且将成为实现更高软件透明度的基础。这些最小元素组成了三大宽泛且相互关联的分类。
最小元素 | |
数据字段 (Data Fields) | 应当予以追踪的每个组件的文档基准信息：供应商、组件名称、组件版本、其它唯一标识符、依赖关系、SBOM数据作者以及时间戳。 |
自动化支持 | 支持自动化，包括通过自动生成和机器可读性扩展至软件生态系统。生成并使用SBOM的数据格式包括 SPDX、CycloneDX 和 SWID 标记。 |
实践和流程 | 定义 SBOM 请求操作、生成和使用，包括频率、深度、已知的未知、分布式和交付、访问控制和错误缓解。 |
本文档识别将赋能基本用例的最小元素，如漏洞管理、软件清单和许可。同时，除了最小元素外，本文档还推荐一些可作为未来工作重点的 SBOM 特性和发展，包括关键的安全特性如 SBOM 完整性，并追踪更详细的供应链数据。随着更多 SBOM 元素变得可行、经过测试并构建到工具中，它们将赋能更广范围的用例。其中一些令人鼓舞的元素正在实现或者已经展示出巨大潜力。
美国政府将 SBOM 视为推动软件质量保证和供应链风险管理的优先任务。本报告发布后，下一步即是按照行政令要求为软件购买方提供 SBOM 的开发指南以及公私营合作，重新定义并投入SBOM工作。
文档指出，NTIA 从2018年起就关注 SBOM 事宜，非常重视软件组件的透明度。使供应链的组件和连接透明化对于发现并解决薄弱链条问题起着重要作用。SBOM 是保护软件供应链的重要一步。否则，系统贡献者、成分和功能缺乏透明度，将造成重大网络安全风险并增加开发、采购和维护成本。
达成透明度的最佳方法是使用行业支持的可理解模型。SBOM 模型通过追踪组件元数据、映射至其它信息来源，以及在元数据转移至供应链并部署时和软件捆绑的方式达成这种系统化分享。为将这一模型扩展到全球，就有必要解决全面识别并定义某些软件组件，使数据能被下游用户有效使用。
识别软件组件是SBOM 的核心所在。SBOM 数据适用于各种简单或复杂的目标，如映射到漏洞数据库、通过关联并分析多个数据来源的方式监控所包含开源软件包中的特定威胁等。在这两种情况中，可能仍然需要外部数据。SBOM 是使相关外部数据映射到软件产品中的必要粘合剂。
SBOM 对于软件厂商、需求方和运营方而言起着重要作用。它可使用户理解软件生态系统并为用户带来好处。例如软件厂商和运营方可将SBOM用于清单、漏洞和许可管理中，而需求方可将其用于风险评估（许可证和漏洞分析）中。
SBOM给软件厂商带来的好处包括，确保组件是最新版本并使其快速响应新漏洞。除此以外，SBOM 还提供除安全性以外的其它好处，如通过可见性提高效率、提升效果，从而赋能优先级处理和更好的管理。例如，SBOM 可协助软件厂商知晓并遵循许可义务。
在漏洞管理方面，SBOM 数据通过提供软件生态系统内依赖透明度，帮助软件厂商和运营方更快更准确地评估与和新漏洞相关的风险。因此，SBOM 提高了漏洞识别能力和响应速度。
了解软件供应链、获取软件组件中的综合 SBOM 数据、并将其用于识别和分析已知漏洞和潜在缓解措施对于管理风险而言至关重要。而只有通过机器可读的、支持自动化和工具一体化的 SBOM以及应用程序查询和处理该数据的能力才能实现上述目标。
本文档设立了SBOM的“最小元素“。这些最小元素将建立SBOM内容的基础技术和实践，对于实现总统行政令中提到的目标而言是必要的。本文档还审查了如何扩展这些基础并为平衡可预见的 SBOM 格式和灵活性需求提供了一些指南，具体取决于所需技术和客户需求。
SBOM 本身将无法解决软件生态系统当前面临的多种软件供应链和软件保证担忧。必须承认，世上并不存在关于网络安全的灵丹妙药，而SBOM也不例外。如上所述，SBOM有助于更好更快地对漏洞进行响应。给定软件中所含的已知漏洞数量由其安装基数、研究社区和供应商披露流程以及产品安全团队决定。漏洞披露得越多，可能意味着软件的使用风险越低，因为这说明研究人员正在关注软件，而供应商正在管理披露流程。
SBOM 是基于已识别漏洞的起始点。在当前环境被视作可行的最小元素不会捕捉元数据的全部范围，而这些元数据关乎可能源自现代软件流程中软件的来源、处理和使用。其中某些数据将被集成到 SBOM 数据的未来扩展中。同时，SBOM 将不会是供应链安全或软件保证的唯一资源或机制。其它数据对于很多用例而言非常有价值，不过也应被视作是独立的，是对SBOM的补充。SBOM 不应当成为所有软件质量保证和软件供应链数据的唯一模型，而应当鼓励通过可连接的模块化方法，使灵活性和应用的潜力发挥到最大。连接性使SBOM数据更容易被映射到其它重要的供应链数据中，而随着软件供应链的透明度和管理数据与工具变得成熟，使得模块化架构支持扩展至更多的用例中。
本文档并未讨论软件供应链的某些关键点，如法规和采购要求等。最小元素不应被解读为设立新的联邦要求。集中化或收集SBOM数据以便运营、为威胁情报服务或作研究之用的潜在好处尚未证实。“软件物料清单“名称本身将硬件排除在外。虽然硬件和设备中嵌入的软件肯定在范围之内，但与硬件相关的关键供应链和安全问题独特且复杂，本文档并未覆盖。
最后，不应将本文档视作对 SBOM 的使用或者对软件生态系统中创新和探索的限制。这些最小元素只是起始点。从更广范围来说，本文档只是说明了SBOM 进程中的关键的初始的步骤，而这些进程终将改进并成熟。
整体SBOM的最小组成部分即“元素“是三个宽泛的、相互关联的方面。这些元素将使我们对软件透明度采取不断变化的方法，同时捕获技术和功能操作。后续将重点关注集成更多的详情或技术提升。如上所述，这些目前只是最小元素；组织机构可能需要更多元素，而软件供应链中的透明度能力可能会随时间变化而得到改进和变化。
最小元素包括的三个类别是：
数据字段
自动化支持
实践和进程
软件可表示为由多个可拥有子组件的组件组成的层级树。组件通常是来自其它来源的 “第三方“，但可能也是”第一方“即来自同一个供应商但可被唯一识别为独立的可追踪软件单元。每个组件都应当拥有自己的SBOM，列出自身组件，构建层级树。数据字段适用于每个组件，这些组件按照定义的实践和进程，通过用于自动化支持的工具和格式进行编码。
数据字段
SBOM 的核心是一个连续的、统一的结构，捕获并展示用于理解软件组件的信息。数据字段包括应被追踪和维护的每个组件的基准信息。这些字段的目标是能够充分识别这些组件，在软件供应链中追踪并将这些组件映射到其它的有益数据源，如漏洞数据库或许可证数据库。该基准组件信息包括：
数据字段 | 描述 |
供应商名称 | 创建、定义和识别组件的实体名称 |
组件名称 | 分配给由原始供应商定义的软件单元的名称 |
组件版本 | 供应商使用的用于指定较之前版本软件变更的标识符 |
其它唯一标识符 | 用于识别组件或作为相关数据库查询密钥的其它标识符 |
依赖关系 | 上游组件X包含于软件Y中的关系描述 |
SBOM 数据作者 | 为组件创建SBOM数据的实体名称 |
时间戳 | SBOM 数据汇编日期和时间的记录 |
大部分字段协助识别组件直接映射到其它数据源。“供应商“是指软件组件的创始人或制造商。”组件名称“由供应商决定。如有可能，则支持对供应商和组件名称提醒多个名称或别名的能力。
软件缺少唯一、便于理解并广泛使用的名称空间带来很多挑战。最佳实践是尽可能使用现有的标识符。如不存在标识符，则使用现有的组件识别系统。“供应商名称“和”组件名称“是人类可读字符串以支持识别，尽管软件生态系统的某些特性如企业并购和开源分叉将导致不存在基于此的无处不在且永久性解决方案。
软件版本所带来的复杂性再次说明，软件生态系统中的多样性如何要求具有灵活的组件识别方法。类型不同的软件或软件供应商追踪版本和分发的方式也不同。SBOM的初次讨论内容中并未涵盖如何解决该问题。对于这些最小元素而言，版本是由供应商提供的，因为供应商最终负责追踪并维护软件，这与组件名称类似。所需的版本字符串功能是识别指定的代码交付。虽然存在版本控制的最佳实践，但目前尚未普遍。
“其它唯一标识符“支持自动化将数据映射到数据使用和生态系统中，且可增强不确定性实例中的确定性。常用的唯一标识符如CPE、SWID标志和PURL。这些其它标识符可能并非存在于每款软件中，但如存在则应使用。
“依赖关系“反映的是软件包含中的指向问题，他能够表示软件对组件和子组件的传递性。最后，SBOM指定元数据有助于追踪SBOM本身。”作者“反映的是元数据的来源，它可能源自SBOM中所描述软件的创始人、上游组件供应商，或某些第三方分析工具。需要注意的是，这并非软件本身的作者，而只是描述性数据的来源。”时间戳“记录数据的汇编时间即SBOM的创建时间。这些元素进一步支持数据来源，并有助于识别SBOM的更新版本。这些数据字段向SBOM数据源提供上下文，且可能被用于做出信任判断。
（未完待续）
https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
题图：Pixabay License
本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。
觉得不错，就点个 “在看” 或 "赞” 吧~