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

使用 SBOM（尤其是在 OSS 中）使组织能够了解组件和依赖关系、改善风险管理等等。 下面我们概述了这些好处。

组件可见性

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

漏洞管理

与任何其他软件类似，OSS 也容易受到安全漏洞的影响。 通过 SBOM，组织可以跟踪开源组件的版本并随时了解与这些版本相关的任何已知漏洞。 这样可以通过及时应用补丁或更新来缓解和报告任何安全问题，从而实现主动漏洞管理（参见RFC8615 ）。 通过拥有最新的 SBOM，组织可以评估漏洞的影响并采取适当措施来保护其软件。

供应链安全

近年来，软件供应链安全已成为人们关注的焦点。 SBOM 通过提供软件中使用的组件及其来源的透明度，有助于增强供应链安全性。 它还允许组织评估他们所依赖的组件的可信度和安全态势。 通过 SBOM，组织可以识别和减轻与受损或恶意组件相关的风险，从而降低软件供应链攻击的可能性。

协作和补丁管理

OSS 鼓励合作和社区参与。 SBOM 通过为不同贡献者和利益相关者提供对软件组件的共同理解来促进有效协作。 它通过清楚地识别需要更新或修复的组件来帮助协调补丁管理工作。 当所有参与者都可以参考共享的 SBOM 来解决安全漏洞和其他问题时，开源社区内的协作会变得更加高效。

监管合规性

在某些行业，监管框架要求组织展示其applications或系统中使用的软件组件的透明度和控制力。 SBOM 提供满足这些合规性要求所需的文档。 它允许组织证明尽职调查、可追溯性和对相关法规的遵守，特别是在 OSS 的安全和许可方面。

许可证合规性

OSS 通常受特定许可证的管辖，这些许可证规定了如何使用、修改和分发软件。 SBOM 提供了所有开源组件及其相应许可证的全面概述。 这有助于组织确保遵守他们所使用的 OSS 的许可条款。 通过了解许可义务，组织可以就其软件的分发和使用做出明智的决定，同时避免任何法律或合规问题。

一些政府和银行业和医疗保健业等受到严格监管的行业的组织正在倡导使用 SBOM，或考虑将使用 SBOM 作为一项要求（无论是在内部还是对其供应商）。

使用 SBOM 的行业示例

• 公共部门 –美国、欧盟、英国和日本是众多利用、监管或推荐使用 SBOM 的国家之一。
• 技术——谷歌、微软和 IBM 等大型科技公司正在引领潮流，在自己的软件开发流程中实施 SBOM，为软件包数据交换 (SPDX) 、 OWASP和开源 SBOM 生成工具等项目做出贡献。
• 汽车 –福特和通用汽车等几家大型汽车公司正在实施 SBOM，并鼓励其供应商为汽车系统中使用的组件和软件提供 SBOM。
• 医疗保健——美国市场的医疗器械制造商目前正在使用 SBOM 来遵守 2022 年食品和药物管理局的规定。

构建 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 是管理 OSS 复杂性的有价值的工具。 它促进开源生态系统内的透明度、安全性、合规性和协作。 通过提供软件组件、其版本和相关许可信息的详细清单，SBOM 使组织能够做出明智的决策、管理风险并确保其软件项目的完整性和安全性。