NGINX.COM
Web Server Load Balancing with NGINX Plus

软件物料清单(SBOM)是一份文档,不仅提供了软件项目所用组件和依赖项的详细清单,而且还列出了软件使用的所有库、框架及其相应的版本。就开源软件(OSS)而言,SBOM 可在确保透明度、安全性和合规性方面发挥关键作用。

 

为何企业应使用 SBOM?

使用 SBOM(尤其是在开源软件中)能够帮助企业获得对组件和依赖项的可见性,并改善风险管理等。下面我们概述了这些优势。

组件可见性

开源软件通常包含各种第三方组件和依赖项。SBOM 允许开发者和用户清晰地了解软件中使用的所有组件,其中包括开源库和框架及其具体版本。这种可见性有助于了解软件的组成,识别潜在的漏洞,并跟踪与开源组件相关的任何许可义务。

漏洞管理

类似于其他任何软件,开源软件也很容易面临安全漏洞风险。借助 SBOM,企业可以跟踪开源组件的版本,并随时了解与这些版本相关的任何已知漏洞。这便于企业及时应用补丁或更新,以减少和报告任何安全问题(请参见 RFC8615),从而实现主动式漏洞管理。有了最新的 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:与软件供应链中的相关利益相关者(如厂商、客户和审计员)共享您的 SBOM。这可提高透明度,改善风险评估,并有助于识别和处理漏洞。
  • 监控和管理漏洞:持续监控与 SBOM 中的组件相关的新漏洞和安全更新。随时了解最新的安全补丁,并及时处理任何漏洞,以维护您的软件安全。

 

SBOM 未能交付的七个原因

以下因素可能会导致 SBOM 未能交付或无法达到其预期目的。化解这些挑战并确保 SBOM 的准确性、完整性和时效性可帮助降低失败的风险。

以下是一些常见的失败原因,折射出了构建 SBOM 的最佳实践:

  • 清单不完整或不准确:如果您的 SBOM 未能准确地捕获项目使用的所有软件组件,或者包含的信息不完整,则可能会导致对软件供应链的理解出现盲点和差异。清单缺失或不准确会造成漏洞或依赖关系的遗漏,进而削弱 SBOM 的有效性。
  • 缺乏组件可见性:如果 SBOM 无法让您清晰了解软件组件的来源、版本和依赖关系,那么就很难有效地评估和管理相关风险。如果缺乏全面可见性,跟踪漏洞、识别补丁更新和确保遵守许可要求将变得具有挑战性。
  • 手动和过时的流程:依靠手动流程来创建和维护 SBOM 会导致低效和错误。若未定期更新 SBOM 以反映软件项目的变化,它将很快过时,并失去其作为安全性和合规性方面的可靠参考的价值。
  • 元数据和上下文信息不足:SBOM 不仅应提供软件组件的列表,还应包括相关的元数据,如许可信息、已知漏洞和发布日期。如果附加上下文信息缺失或不完整,便无法准确地评估风险和做出明智决策。
  • 利益相关者之间缺乏协作:软件供应链中利益相关者之间的密切协作和信息共享对于有效利用 SBOM 而言至关重要。如果他们之间缺乏合作或不愿意共享 SBOM 信息,则很难共同识别和处理漏洞,这会危及软件的整体安全性。
  • 有限的工具和自动化:手动创建和维护 SBOM 非常费时且容易出错。如果没有适当的工具和自动化,将很难高效生成、更新和管理 SBOM。缺乏自动化也可能会导致无法及时识别新漏洞或依赖关系。
  • 漏洞监控不力:SBOM 应辅以强大的漏洞监控流程。如果缺乏对新漏洞和软件组件相关安全更新的定期监控,则可能无法及时发现潜在风险,致使软件受到已知漏洞的影响。

 

总结

总体而言,SBOM 是管理开源软件复杂性的重要工具,可增强开源生态系统内的透明度、安全性、合规性和协作。通过提供软件组件及其版本和相关许可信息的详细清单,SBOM 能够帮助企业做出明智的决策,高效管理风险,并确保其软件项目的完整性和安全性。

 

资源

博文

Tags

No More Tags to display