开源软件很容易受到恶意行为者的攻击，但软件材料清单可以帮助减轻威胁。美国国家安全局的指导为管理生态系统奠定了坚实的基础。

软件供应链安全仍然是网络安全和软件行业的一个关键话题，并且有充分的理由，从针对大型软件供应商的持续攻击到攻击者对开源软件生态系统的恶意关注，它是大多数人的前沿和IT安全主管与安全从业者。幸运的是，组织继续提供可靠的指导来帮助从业者减轻软件供应链风险。最新出版物《保护软件供应链：管理开源软件和软件物料清单的建议做法》来自美国国家安全局 (NSA)。

它还以之前的出版物（例如白宫网络安全行政命令 (EO)和备忘录）以及即将对联邦机构提出的要求为基础，例如管理和预算办公室 (OMB) 的备忘录22-18和23-16，其中要求软件供应商向美国联邦政府出售产品，以自我证明与美国国家标准与技术研究所 (NIST) 的安全软件开发框架 (SSDF) 等出版物保持一致，甚至在某些情况下提供 SBOM。

虽然 NSA 指南引用了白宫、NIST 和 OMB 之前的出版物，但本出版物与所有生产和使用软件、利用 OSS 以及寻求采用 SBOM 等工件的组织相关。

以下是该指南的一些关键领域，包括该文件的建议和要点。

NSA SBOM 指南的结构

NSA 指南重点关注四个关键领域，如下表所示，并与其各自的 SSDF 活动保持一致。（区域1仅作介绍，因此省略）：

开源软件管理

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

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

该指南建议采用 SBOM 作为 OSS 组件库存管理的一种手段，同时也为下游消费者提供透明度，并了解通过开发到产品中的组件的漏洞状况。SBOM 是软件组件的嵌套清单，主要格式是 Linux 基金会的SPDX和 OWASP 的CycloneDX。NSA 建议生成的 SBOM 满足 NTIA 的“ SBOM 的最低元素”中记录的最低元素要求。

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

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

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

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

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

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

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

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

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

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

强调的另一个关键活动是安全代码签名要求，例如执行代码签名、使用经过验证的加密技术以及保护代码签名基础设施本身。美国国家安全局还建议在 NIST 的事件处理指南等指南的基础上制定危机管理计划。它包括定义危机、构建组织应对方式以及参与人员等活动。如果 OSS 组件在野外被主动利用，这一点至关重要。这还涉及创建和完善危机管理团队 (CMT) 以及角色和职责。该团队将调查与主动利用相关的潜在事件，确定组件位于执行路径内时系统或应用程序是否受到影响，并确定是否可以修补漏洞或是否需要补偿控制。

SBOM 创建、验证和工件

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

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

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

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

这解决了软件供应商和消费者之间长期缺乏透明度的问题，并为加强整个生态系统的软件供应链安全提供了机会。

有关供应商 SBOM 流程的更多详细信息，NSA 指南推荐 NTIA 的“软件供应商手册：SBOM 生产和提供”。