软件物料清单(SBOM)详解:构建安全透明软件供应链的基石

软件物料清单(SBOM)是应用程序开发与交付过程中所有组件及依赖项的详细清单,已成为提升软件供应链安全与透明度的关键工具。本文详细阐述了SBOM的内容、类型、益处、挑战及创建方法,为组织应对现代软件安全风险提供指导。

什么是SBOM(软件物料清单)?

软件物料清单(SBOM)是详细记录应用程序开发与交付过程中涉及的所有组件及软件依赖项的清单。它已成为软件开发生命周期和DevSecOps流程中日益普遍且关键的部分,帮助希望加强安全状况的组织识别和管理风险。

现代软件应用程序和服务通常由来自不同来源的多个组件和依赖项构建而成。它们可以包括开源软件项目、许可证、专有代码、应用程序编程接口、编程语言框架和软件库。构成现代软件的各种来源是软件供应链的一部分,是启用应用程序和服务的供应源。SBOM列出了所有这些组件,供组织用于改进安全和软件供应链风险管理流程。

SBOM类似于供应链和制造业中使用的物料清单(BOM)。BOM对产品中包含的所有项目进行盘点,并有助于将缺陷追溯到特定部件或供应商。同样,SBOM提供了对软件内部构成的可视性,帮助组织和用户更好地了解正在使用的内容以及潜在风险可能存在于何处。

软件物料清单包含什么内容?

从根本上说,SBOM是构成软件应用程序或在线服务的所有组件的清单。这包括任何源组件和依赖项。源组件可以包括以下列表:

  • 共享对象,例如动态链接库。
  • 用于不同功能的软件库。
  • 应用程序中使用的开源代码。
  • 应用程序运行所依赖的中间件、容器、云服务和编程框架。

SBOM与成分列表或简单清单的不同之处在于,它还应该提供有关组件来源的血统信息。现代软件开发通常遵循一个原则:一段应用程序代码依赖于另一段。因此,需要一个依赖关系树来帮助了解应用程序的核心基础组件。

2021年,美国国家电信和信息管理局(NTIA)在一份报告中发布了确定性指导,详细说明了SBOM的最低要素,包括以下三个基础领域:

  1. 数据字段。SBOM的数据字段部分是资产清单组件,概述了应用程序的依赖关系树。字段应包括组件名称、版本、许可证信息、供应商名称、作者身份以及生成SBOM数据的时间戳。
  2. 自动化支持。鉴于现代软件开发流程的复杂性,不建议手动开发SBOM。因此,NTIA建议SBOM生成和数据传输具备最低水平的自动化,以便其他系统能够理解和使用SBOM数据。
  3. 实践与流程。SBOM需要建立适当的流程,以实现数据的持续收集。还需要定义如何生成和访问SBOM。

2024年,美国网络安全和基础设施安全局(CISA)发布了一份题为《构建软件组件透明度:建立通用软件物料清单(SBOM)》的报告。该报告扩展了NTIA的基础领域。CISA的报告定义了SBOM的要素和属性,并包含如何实施SBOM的详细信息。

SBOM的类型

根据其深度、所需细节或用例,SBOM可以通过多种不同的方式进行分类。根据CISA的说法,SBOM可以分为以下六种类型:

  • 设计型。此类SBOM在开发开始前列出计划的组件来创建。通常根据设计规范和预期组件创建。
  • 源代码型。此类SBOM通过直接从开发环境、源文件和依赖项列出组件来创建。
  • 构建型。此类SBOM在构建过程中创建,反映了实际编译并放入最终软件中的组件。
  • 分析型。此类SBOM基于观察到的组件创建。通常在软件构建后,使用第三方工具扫描可执行文件、容器和虚拟机等部分。
  • 部署型。此类SBOM通过记录部署环境中的软件组件和配置信息来创建。旨在盘点什么可用以及什么已实际安装。
  • 运行时型。此类SBOM旨在仅记录在应用程序执行期间主动加载和使用的组件。

使用SBOM的好处

随着组织日益依赖软件来运行业务关键操作,拥有SBOM至关重要,原因如下:

  • 改善安全状况。SBOM帮助组织识别潜在安全风险,并使其能够更有效地应对这些风险。
  • 帮助评估依赖项和供应链风险。当发现软件漏洞时,它们通常存在于作为其他软件应用程序依赖项的组件中。了解组织是否因第三方组件而面临风险是一个通常被称为供应链风险的挑战。
  • 增强透明度。许多组织难以理解它们是否面临特定软件漏洞的风险。SBOM增加了对软件或服务中使用的确切组件的透明度和可视性。
  • 辅助开源许可证合规。除了帮助应对供应链风险外,SBOM还可以协助组织处理开源软件许可证合规问题。不同的开源许可证可能有使用限制或要求组织共享对源代码所做的任何更改。一个结构良好的SBOM不仅揭示了底层的开源软件依赖关系,还揭示了存在的许可证限制。
  • 支持法规和政策合规。继2020年和2021年发生一系列供应链攻击(包括2020年3月的SolarWinds漏洞和2021年7月的Colonial Pipeline黑客攻击)之后,美国联邦政府发布了第14028号行政命令,主张美国政府机构仅与提供SBOM的软件供应商合作(以及其他指令)。该行政命令还指示NTIA定义SBOM的最低要求,该机构在2021年7月发布的一份综合报告中对此进行了定义。

使用SBOM的挑战

尽管SBOM可以通过提供更好的可视性和安全状况使组织受益,但它们也带来以下挑战:

  • 与现有工作流程集成不一致。SBOM的实施应在团队和软件供应链中涉及的任何各方之间保持一致。它还应与现有的开发、合规和安全流程保持一致。
  • 维护SBOM的准确性。保持SBOM的最新状态可能很困难,因为它需要随着软件的任何更改而维护、扩展和更新。
  • 供应商支持不足。第三方供应商可能无法提供其组件的详细信息供组织在其SBOM中使用。

如何选择SBOM工具

在选择创建SBOM的工具时,组织应确保其能够满足以下要求:

  • 提供可扩展性。SBOM工具应能够适应不同规模的项目,从较小的应用程序到大型企业级系统。
  • 与现有工作流程和系统集成。正确的工具必须能够与组织的开发和运营系统正确集成。如果该工具将用于增强安全性,则应与现有的安全工具集成。
  • 满足组织的需求。所选工具必须符合组织创建SBOM的计划。
  • 提供自动化功能。一些SBOM工具具有自动生成和更新SBOM的功能。
  • 提供合规功能。该工具应支持相关标准,例如软件包数据交换(SPDX)或CycloneDX,并有助于满足任何监管SBOM要求。
  • 符合预算。SBOM工具可以是免费的、基于使用量的或基于订阅的。

如何创建软件物料清单

多种工具可以与持续集成/持续交付技术集成,以作为开发流水线的一部分构建SBOM。可以在软件开发过程之前、期间或之后使用以下步骤生成SBOM:

  1. 定义SBOM范围。组织必须决定为哪个软件创建SBOM,以及它是否依赖于任何内部、外部或第三方依赖项。
  2. 选择格式。对于希望或需要了解供应链风险的开发人员和最终用户组织而言,使用行业标准形式进行SBOM数据交换至关重要。无论组织是在开发过程中生成SBOM(使用软件组成分析工具或其他方式),SBOM数据都必须采用可移植且易于理解的格式,以便在其他应用程序中使用。
  3. 选择SBOM工具。组织应选择其想要使用的SBOM工具,例如CycloneDX命令行界面、Grype、Syft或Tern。它需要符合组织想要实施的SBOM类型。
  4. 生成SBOM。例如,如果生成SBOM发生在构建期间,SBOM工具可能使用软件组成分析软件来识别每个应用程序的组件。软件组成分析扫描可以在应用程序完成后或在应用程序开发过程中进行。
  5. 维护。每当软件更新或添加新的依赖项时,都应重新运行SBOM工具。
comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计