美国国家安全局（NSA）发布《软件物料清单（SBOM）管理建议》

美国国家安全局（NSA）发布了最新的《软件物料清单（SBOM）管理建议》。以下是该报告的关键内容和摘要：

执行摘要

• 过去五年中，软件供应链的网络妥协事件显著增加，这促使对加强政府和关键基础设施使用的软件供应链的弹性措施进行了深入审查。

• 本文档的重点是软件物料清单（SBOM）及其管理工具，这些工具作为网络安全供应链风险管理（C-SCRM）策略的一部分。

• 本指南包括从对不同SBOM管理工具的研究和评估中得出的重要SBOM管理工具功能推荐。

主要内容

• 风险管理、脆弱性管理和事件管理： 强调利用SBOM进行软件风险管理、脆弱性管理和事件管理的重要性。

• 软件供应商和消费者的一般建议： 包括改进SBOM交换模式、扩大SBOM研究、以及软件开发人员需要对客户安全产生的结果负责等建议。

• 特定于国家安全系统（NSS）的指导： 提供了更具体的建议，包括在软件中包含SBOM组件信息、识别运行时依赖项、使用数字签名或验证哈希来确保组件（和SBOM）的完整性等。

最佳实践和工具功能

• 最佳实践： 包括建立软件供应商和消费者之间的安全共享点、获取SBOM和相关的脆弱性和代码质量信息等。

• 推荐工具功能： 涵盖SBOM输入、输出、生成SBOM、SBOM组件处理、SBOM及其组件完整性验证、脆弱性跟踪和分析、区分已识别与可利用脆弱性、用户界面等方面的功能。

结论

• 该文件强调了SBOM在管理软件供应链风险中的重要性，并提供了详细的最佳实践和工具功能建议，以支持国家安全系统和其他组织的C-SCRM努力。

详细目录

1. 软件物料清单（SBOM）管理建议

• 执行摘要

• 引言

• 目的和背景

2. 建议

• 针对软件供应商的一般建议

• 针对软件消费者的一般建议

• 针对国家安全系统（NSS）的特定指导

3. 最佳实践

4. 推荐的工具功能

• SBOM输入

• SBOM输出

• 生成SBOMs

• SBOM组件处理

• 验证SBOM和SBOM组件的完整性

• 脆弱性跟踪和分析

• 区分已识别与可利用脆弱性

• 用户界面

• 输出形式和方法

• SBOM版本管理和配置管理支持

• 与其他系统的集成和工作流

• 支持访问数据源

• 可伸缩架构

• SBOM工具设置和配置

5. 引用文献

重点内容节选：

  建议

NSA 提出以下行动建议，以增强 SBOM 使用的“最新技术”水平。这些建议分为针对软件供应商和消费者的一般指导，以及针对国家安全系统（NSS）用户的特定指导。

针对软件供应商的一般建议

• 软件提供商社区及其消费者应完善 SBOM 交换模式，保护软件供应商的知识产权和产品安全，同时确保 SBOM 信息传递的真实性、准确性、及时性和效率。

• 行业和政府实体应扩大 SBOM 研究，以更好地理解 SBOM 的最低要求，并分享最佳实践，以标准化对网络供应链攻击易受攻击的其他技术平台的解决方案。

• 软件开发者必须对客户的安全成果负责，而不是将每个产品视为隐含的“买方自负”。EO 14028 和 NSM-8 为国家安全系统和其他关键系统的用户提供了要求软件技术供应商“设计和默认安全”的基础。

针对软件消费者的一般建议

• 软件消费者应利用以下资源，确保其供应商设计、开发和交付安全软件：

• 美国国家标准与技术研究院（NIST）特别出版物（SP）800-218：安全软件开发框架（SSDF）或替代安全软件开发框架。

• 管理和预算办公室（OMB）备忘录 M-23-16 更新了 OMB 备忘录 M-22-18，要求所有联邦机构仅使用符合 NIST SP 800-218 的软件供应商。

• 软件组件验证标准（SCVS）提供额外资源，帮助 NSS 用户驱动 SBOM 数据向上游软件供应商来源的要求。

针对 NSS 的特定指导

• 针对 NSS 的建议基于 NTIA Formats 和 Tooling 工作组在其软件消费者手册中提供的信息。建议 NSS 所有者制定并要求合同语言包括以下内容：

• 包含软件组件信息，至少包括 NTIA 所需的每个组件的字段。

• 识别软件运行所需的非 SBOM 列出的软件组件的其他依赖项。

• 所有具有容器组件的软件都应要求包含容器清单。

• 使用数字签名或经过认证的哈希来验证组件（及 SBOM）的完整性。

SBOM输入

支持和管理所有SBOM格式版本（例如最新的Cyclone DX（CDX）版本是v1.4，最新的SPDX版本是2.1）。理想情况下应该导入并支持这两种格式。

以JSON或XML文件类型导入SBOM。理想情况下应该导入JSON、XML和CSV文件类型。

导入SBOM时，检查SBOM结构和语法是否符合相应格式规范（包括特定版本）。

显示SBOM符合适用结构和语法规则的信息，针对SBOM格式和版本。理想情况下，应通过显示评估的质量级别来提醒用户，同时提供是否继续导入的选项。

包括一个自动纠正选项，帮助用户规范和纠正正在导入的SBOM文件。

SBOM输出

使用CDX或SPDX格式导出SBOM。理想情况下，应该包括导出这两种格式的能力。

以JSON或XML文件类型导出SBOM。理想情况下，应该包括导出JSON、XML和CSV文件类型的能力。

将一种SBOM格式转换为另一种。

将一种SBOM文件类型转换为另一种。

从SBOM工具的存储库中聚合多个SBOM为一个SBOM。

生成SBOMs

从各种类型的软件开发过程输出中生成SBOM（例如来自软件构建环境、二进制文件分析、系统注册表查询等）。

SBOM组件处理

显示NTIA最低SBOM字段（供应商名称、组件名称、组件唯一标识符（CPE PURL）/哈希、组件版本、组件依赖关系、组件作者）。

使用额外的参考来源丰富SBOM信息。理想情况下，应提供视觉提示，表明用于丰富SBOM数据的外部信息，并引用丰富数据的来源站点。

包括图形化表示组件依赖关系的机制。

显示组件出处信息，包括外部丰富内容。

验证SBOM及其组件完整性

捕获并显示每个组件的哈希信息。理想情况下，这种验证应提供SBOM的数字签名和每个组件的出处信息，以及组件哈希和PURL或CPE指针。

包含从中收集出处数据的信息来源链接（支持验证完整性和评估风险能力）。

脆弱性跟踪和分析

从国家脆弱性数据库（NVD）和其他脆弱性数据中提供每日更新。理想情况下，这些更新应提供持续提取和分析，结合相关网络威胁情报（CTI）和SBOM数据增强服务。

通知用户新的脆弱性和更新，包括新出现的关键脆弱性及其严重性的警报。理想情况下，这些通知应清楚区分新脆弱性和现有脆弱性的更新，并提供额外信息以优先处理脆弱性响应和风险缓解指导。

区分已识别与可利用脆弱性

指出脆弱性是否真的可利用，并支持非可利用声明的证据和理由。理想情况下，应注明并更新组件脆弱性的可利用性信息，使用脆弱性利用性交换（VEX）格式。

用户界面

遵循人机界面（HCI）标准。

包含辅助功能。

提供使信息易于评估的机制，如果需要，使用户能够轻松深入了解（通常通过将光标悬停在图标上或点击带有链接的图标）以查看更多细节。

提供易于理解的图形表示方法和格式，以传达关于软件组件、脆弱性、许可证、供应商组织、用户和用户组织的信息属性。

提供多种方法来“深入挖掘”并获取软件组件出处、脆弱性、许可证和风险状态的额外信息。

输出形式和方法

输出关于组件属性、脆弱性信息、许可证信息和组件供应商信息的标准化报告。

以图形和/或文本格式导出依赖信息。

输出分析结果的图形表示。

理想情况下，提供模块化的方式来导出特定文本和图形（无论是来自SBOM本身还是来自分析和增强过程），以用于外部沟通。

SBOM版本管理和配置管理支持

包括可扩展的SBOM配置管理能力。至少应包括组织SBOM、维护版本历史和跟踪SBOM/软件更改的机制。

包括基于多个信息属性（如按组织、软件供应商、软件类型、BOM类型、许可证类型等）组织SBOM的用户可定制机制。

包括趋势图表，显示每个组件版本的各个严重性级别的脆弱性数量，并报告每个版本发布时组件脆弱性的增减情况。

比较同一软件的不同SBOM版本，并突出显示差异（如不同组件或不同组件版本、不同来源等）。

与其他系统的集成和工作流

采用“API优先”设计，便于与其他系统导入和导出信息。理想情况下，工具内的信息元素应能够单独导出/下载。

与多种类型的SBOM来源和其他可结合分析的数据集成。

利用格式不可知、独立、无状态且可扩展的API功能（如REST）自动化流程/工作流。

支持安全集成的生产者/消费者交换生态系统。

支持访问数据源

集成AI/ML引擎和相关“数据湖”，分析SBOM组件信息与各种类型的威胁签名和模式。

包括一个可更新的开源软件许可证库，SBOM管理工具识别并跟踪适用的地方。

可伸缩架构

包括机制以支持企业内不同子组织，这些子组织可能有不同的风险容忍规则或政策。

处理其他类型的BOM。

成为或支持一套协同工作以完成风险管理、脆弱性管理和事件管理活动的工具。

SBOM工具设置和配置

提供机制和支持材料，以便于在Linux或Microsoft环境中轻松下载、设置和集成。理想情况下，应支持两者。

原文始发于微信公众号（开源安全研究院）：美国国家安全局（NSA）发布《软件物料清单（SBOM）管理建议》