专家解读： NSA 关于管理 OSS 和 SBOM 的最新指南

原创网站：csoonline.com

原创作者：克里斯·休斯（Chris Hughes）

Chris Hughes目前担任Aquia的联合创始人兼首席信息安全官。Chris 拥有近 20 年的 IT/网络安全经验。这包括在美国空军的现役时间、美国海军和总务管理局（GSA）/FedRAMP 的公务员以及在私营部门担任顾问的时间。此外，他还是国会科技大学和马里兰大学全球校区网络安全硕士项目的兼职教授。Chris 还参与了云安全联盟事件响应工作组等行业工作组，并担任云安全联盟 DC 的成员主席。Chris 还共同主持了 Resilient Cyber Podcast。他拥有各种行业认证，例如 ISC2 的 CISSP/CCSP，同时持有 AWS 和 Azure 安全认证。他定期与各行各业的 IT 和网络安全领导者进行咨询，以协助他们的组织完成云迁移之旅，同时将安全性作为转型的核心组成部分。

图片来源：Luke Southern / Unsplash

开源软件很容易受到恶意行为者的攻击，但软件物料清单可以帮助减轻威胁。NSA指南为管理生态系统奠定了坚实的基础。软件供应链安全仍然是网络安全和软件行业的一个关键话题，这是有充分理由的——从对大型软件供应商的持续攻击到攻击者对开源软件生态系统的恶意关注，它是大多数首席信息安全官和安全从业者的前沿和中心。幸运的是，组织继续提供可靠的指导，以帮助从业者降低软件供应链风险。最新出版物《保护软件供应链：管理开源软件和软件物料清单的推荐做法》来自美国国家安全局（NSA）。它还建立在以前的出版物（如白宫网络安全行政命令（EO）和备忘录）以及即将出台的联邦机构要求的基础上，例如管理和预算办公室（OMB）的备忘录 22-18 和 23-16，这些要求向美国联邦政府销售产品的软件供应商自我证明与美国国家标准与技术研究院（NIST）的安全软件开发框架（SSDF）等出版物保持一致在某些情况下甚至提供 SBOM。虽然 NSA 指南指出了白宫、NIST 和 OMB 以前的出版物，但该出版物与所有生产和使用软件、利用 OSS 并希望采用 SBOM 等工件的组织相关。以下是该指南的一些关键领域，包括建议和文件中的要点。

NSA 关于 SBOM 的指南的结构

NSA 指南侧重于四个关键领域，如下表所示，并与其各自的 SSDF 活动保持一致。（省略了区域 1，因为它只是一个介绍）：

图片由美国国家安全局提供

开源软件管理

NSA 指南的这一部分定义了开发人员和供应商等的关键角色和责任。它指出，开发人员有责任确定要使用的潜在开放源码软件解决方案，并将开放源码软件解决方案集成到产品软件中，以及跟踪这些组件的更新。供应商是指生产产品或服务并执行诸如监控产品中包含的 OSS 组件的许可证更改或漏洞等活动的供应商，因为它们可能会将风险传递给下游消费者。

NSA 列出了使用 OSS 的主要考虑因素，例如评估 OSS 组件是否存在 NVD 和其他漏洞数据库等来源中的漏洞，并确保产品中不包含易受攻击的组件。它还建议组织继续注意许可方面的考虑因素，例如许可证合规性，以及出口管制，例如可能影响将开放源码软件纳入产品的不断发展的欧盟法规。

该指南建议将 SBOM 作为 OSS 组件库存管理的一种手段，以及下游消费者的透明度和对通过开发产品所包含的组件的漏洞态势的可见性。SBOM 是软件组件的嵌套清单，主要格式是 Linux 基金会的 SPDX 和 OWASP 的 CycloneDX。NSA 建议生成的 SBOM 满足 NTIA 的“SBOM 的最低元素”中记录的最低元素要求。

创建和维护公司内部的安全开源存储库

鉴于组织使用开放源码软件的广泛程度，一些研究引用了70-90%的现代代码库是开放源码软件，大约90%的代码库包含一些开放源码软件组件，NSA指南中的另一个突出建议是创建和维护公司内部安全的开放源码软件存储库。此存储库有助于审查 OSS 组件，以确保它们在提供给产品和开发团队之前满足组织风险和合规性要求。

NSA 建议使用软件组件分析等工具来识别漏洞和许可问题，然后再通过安全存储库向开发人员提供 OSS 组件，如下图所示：

图片由美国国家安全局提供

这当然意味着组织需要定义添加包以供使用的流程，以及允许将包添加到安全存储库所需的安全分析和文档。它还指出，与生产版本相比，开发等环境可能有不同的政策，并建议与安全供应链消费（S2C2F）等行业框架保持一致，该框架侧重于为开发人员提供安全的 OSS 消费和使用。

开放源码软件的采用过程应包括软件组成分析、病毒扫描和模糊测试等活动，这些活动发生在隔离的安全环境中。此外，还建议开发人员考虑其他因素，例如许可、漏洞历史记录以及采用组件在时间和降低内部开发成本方面的好处。美国国家安全局还建议使用OpenSSF记分卡等工具来分析组件，或者OpenSSF记分卡当然不局限于已知漏洞等滞后风险指标，还要考虑项目代码审查、贡献者密度、维护维护等方面。

值得注意的是，小型组织可能有一个单一的安全存储库，并让开发人员实施治理，而大型组织可能会利用开源审查委员会来审查采用请求，并涉及许多利益相关者，如开发、管理和安全。建议包括监视授权组件的存储库以查找新漏洞，并随时了解哪些开发人员组和产品团队采用了某个组件，以便在组件随后变得易受攻击或受到损害时，他们可以成为任何必要的事件响应活动的一部分。

为了向下游产品和软件使用者提供背景信息和优先级，该指南建议供应商和开发人员采用漏洞利用交换（VEX）文档，以帮助消费者和客户了解哪些组件实际受到漏洞的影响，哪些组件已得到解决，以及应通过补偿控制解决哪些问题。

NSA 还建议供应商和供应商采用认证流程，以证明产品在产品开发和分销的整个构建、扫描和包装过程中的安全开发。当然，这是由行业努力主导的，例如in-toto和SSDF，以及在不生成和使用机器可读工件时的自我证明。这不仅有助于保证最终产品的组件，还有助于确保开发过程的安全性。

为了解决漏洞，NSA 建议不仅使用 CVE 和 NVD，还建议使用 OSV 等其他漏洞数据库，以及 CISA 已知利用漏洞（KEV）目录和漏洞预测评分系统（EPSS）等漏洞情报来源。这不仅可以深入了解漏洞基础评分和严重性，还可以深入了解已知或可能的利用。

开源软件维护、支持和危机管理

强调的另一项关键活动是安全代码签名要求，例如执行代码签名、使用经过验证的加密以及保护代码签名基础结构本身。美国国家安全局还建议制定危机管理计划，以NIST的《事件处理指南》等指南为基础。它包括定义危机、构建组织将如何应对以及谁将参与其中等活动。在对开放源码软件组件进行积极利用的情况下，这一点至关重要。这还涉及创建和完善危机管理团队（CMT）以及角色和职责。该团队将调查与主动利用相关的潜在事件，确定系统或应用程序是否受到影响，如果组件在执行路径内，并确定是否可以修补漏洞或是否需要补偿控制。

SBOM 创建、验证和项目

本指南的这一部分重点介绍创建和利用 SBOM 的工具、流程和注意事项。为了有效地使用 SBOM，供应商需要了解产品的构建方式以及它们包含哪些组件。NSA 指南将 SBOM 工具分为源、二进制、包和运行时提取器四类，因为 SBOM 可以在 SDLC 的各个阶段创建。

NSA 建议组织在签名之前验证 SBOM 内容的准确性。它还重申，SBOM 可以随附 VEX 等文件，以明确易受攻击的组件、供应商为解决漏洞而采取的活动以及可能仍然易受攻击或可利用的组件。由于 SBOM 是一个新兴且不断发展的主题，因此 NSA 指出了来自 SPDX、CycloneDX 和 Linux 基金会的各种资源，组织可以在其中了解有关 SBOM 的更多信息、它们的作用以及如何使用它们来降低组织风险。

该指南强调了恶意攻击的速度，在发现和披露漏洞后平均发生 5.5 天，并建议在自动化管道（如 CI/CD）中使用 SBOM 来自动生成 SBOM。它还建议查看 CISA 的 SBOM 和 VEX 资源。有关 VEX 文档和 SBOM 如何协同工作的详细可视化，请参见下图：

图片由美国国家安全局提供

这展示了 SBOM 如何提供软件组件的透明度，而 VEX 可以伴随着软件供应商的透明度，以传达哪些组件受漏洞影响或不受漏洞影响，并且可能需要客户和消费者采取行动和缓解控制。可以向消费者提供 SBOM 和随附的 VEX 文档，以清楚地传达产品或应用程序中的 OSS 组件，VEX 可以帮助最大限度地利用资源，以关注产品的哪些方面实际上容易受到攻击，以及供应商或供应商采取的潜在行动的细节。

这解决了软件供应商和消费者之间长期缺乏透明度的问题，并为加强整个生态系统的软件供应链安全提供了机会。有关供应商 SBOM 流程的更多详细信息，NSA 指南推荐 NTIA 的“软件供应商手册：SBOM 生产和供应”。