什么是软件物料清单（SBOM）？

A 软件物料清单（SBOM）是一份详细列出软件项目所用组件及依赖项的文档，其中还会列出软件使用的所有库、框架及其各自版本。对于开源软件（OSS），SBOM有助于确保透明度、安全性和合规性。

贵组织为何应使用软件物料清单（SBOM）

使用SBOM（尤其是在开源软件中）可帮助组织了解组件及其依赖关系，改进风险管理，并获得更多益处。下面将概述这些益处。

组件可见性

开源软件（OSS）通常包含各种第三方组件和依赖项。软件物料清单（SBOM）可让开发人员和用户清楚了解软件使用的所有组件，包括开源库和框架及其具体版本。这种可见性有助于了解软件的组成、识别潜在漏洞，并跟踪与开源组件相关的许可义务。

漏洞管理

与其他软件一样，开源软件（OSS）也可能存在安全漏洞。借助软件物料清单（SBOM），组织可以跟踪开源组件的版本，并及时了解与这些版本相关的任何已知漏洞。这样，组织便可及时应用补丁或更新，以缓解并报告安全问题，从而主动管理漏洞（参见RFC8615）。通过维护最新的SBOM，组织可以评估漏洞的影响，并采取适当措施保护其软件。

供应链安全

近年来，软件供应链安全已成为备受关注的问题。软件物料清单（SBOM）可提高软件所用组件及其来源的透明度，从而帮助增强供应链安全。组织还可借此评估所依赖组件的可信度和安全状况。通过SBOM，组织可以识别并缓解因组件遭入侵或含有恶意代码而产生的风险，降低软件供应链遭受攻击的可能性。

协作与补丁管理

OSS鼓励协作和社区参与。SBOM让不同贡献者和利益相关方对软件组件形成共同认识，从而促进有效协作。它可以明确指出需要更新或修复的组件，帮助协调补丁管理工作。当所有参与者都能参考共享的SBOM来处理安全漏洞和其他问题时，开源社区内的协作会更加高效。

法规合规

在某些行业，监管框架要求组织证明其对应用或系统中所用软件组件的透明度和管控能力。软件物料清单（SBOM）可提供满足这些合规要求所需的文档，帮助组织证明其已履行尽职调查义务，并具备可追溯性且遵守相关法规，尤其是在开源软件（OSS）的安全和许可方面。

许可证合规

OSS通常受特定许可证约束，这些许可证规定了软件的使用、修改和分发方式。SBOM全面列出了所有开源组件及其对应的许可证，有助于组织确保遵守所用OSS的许可条款。了解许可义务后，组织可以就软件的分发和使用做出明智决策，同时避免法律或合规问题。

高度监管行业的SBOM要求

多个政府以及银行、医疗保健等高度监管行业的组织正在倡导使用SBOM，或考虑要求其内部或供应商使用SBOM。

使用SBOM的行业示例

公共部门：美国、欧盟、英国和日本等许多国家/地区正在使用、监管或建议使用SBOM。
技术领域：Google、Microsoft和IBM等大型科技公司率先在自身的软件开发流程中实施SBOM，并为以下项目作出贡献：软件包数据交换（SPDX）、OWASP，以及将SBOM生成工具开源。
汽车行业：多家大型汽车公司，例如Ford和General Motors，正在实施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未能发挥作用的7种情况

SBOM可能会因多种原因失效或无法达到预期目的。应对这些挑战，并确保SBOM准确、完整且及时更新，有助于降低失效风险。

以下是一些常见的失败原因，与构建SBOM的最佳实践相对应：

清单不完整或不准确：如果SBOM未准确涵盖项目中使用的所有软件组件，或包含的信息不完整，可能会导致对软件供应链的了解存在盲区和缺口。清单缺失或不准确可能导致忽略漏洞或依赖项，从而削弱SBOM的有效性。
组件可见性不足：如果SBOM无法清晰呈现软件组件的来源、版本和依赖关系，就难以有效评估和管理相关风险。缺乏全面的可见性，会给漏洞跟踪、补丁更新识别以及许可证要求合规保障带来困难。
手动且过时的流程：依靠手动流程创建和维护SBOM可能导致效率低下和错误。如果未定期更新SBOM以反映软件项目的变化，SBOM很快就会过时，无法再作为安全与合规方面的可靠参考。
元数据和上下文不足：SBOM不应只提供软件组件列表，还应包含许可信息、已知漏洞和发布日期等相关元数据。如果缺少这些额外的上下文或信息不完整，将难以准确评估风险并做出明智决策。
利益相关方缺乏协作：软件供应链中各利益相关方之间的协作和信息共享对于有效利用SBOM至关重要。如果各方缺乏合作或不愿共享SBOM信息，就难以共同识别和解决漏洞，从而削弱软件的整体安全性。
工具和自动化能力有限：手动创建和维护SBOM可能既耗时又容易出错。如果缺少适当的工具和自动化支持，就难以高效生成、更新和管理SBOM。自动化不足还可能导致无法及时发现新的漏洞或依赖项。
漏洞监控不足：SBOM应辅以健全的漏洞监控流程。如果未定期监控软件组件相关的新漏洞和安全更新，潜在风险可能无法被发现，导致软件暴露于已知漏洞之下。

总结

总体而言，SBOM是管理开源软件（OSS）复杂性的实用工具，有助于提升开源生态系统的透明度、安全性、合规性和协作水平。SBOM提供软件组件、组件版本及相关许可信息的详细清单，帮助组织做出明智决策、管理风险，并确保软件项目的完整性和安全性。