面向非技术利益相关者的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也应随之变更。

对于以受控方式构建软件的团队而言，这与安全开发实践自然契合。我们关于面向SaaS创始人的安全SDLC原则说明的文章涵盖了从一开始就将安全融入交付的更广泛理念。

典型SBOM的样子

SBOM通常以机器可读文件的形式提供，这意味着它是为系统处理而设计的，而非像报告那样供人阅读；这听起来可能很技术，但实际效果很简单：它可以被搜索、比较，并用于跟踪漏洞的工具中。

常见格式及总体阅读方法

两种常见格式是CycloneDX和SPDX，你无需记住这些名称，但了解它们是呈现同类信息的标准方式会有帮助；一份好的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看起来像一份结构化文件或报告，包含产品名称、版本、组件列表及供应商详情；它通常是机器可读的，因此乍一看可能很技术，但重要信息是相同的：软件中的内容及包含的版本。