软件供应链安全社区 标准规范组｜软件物料清单（SBOM）在供应链中的角色定义及作用

2021 年 10 月，美国国家电信和信息管理局（NTIA）发布《构建软件组件透明度：建立通用软件物料清单（SBOM）》。该文件旨在建立一个通用的、格式化的、可操作的方法，以便列出软件组件成分及组件信息和依赖关系，从而实现对软件的组成成分、安全和许可等方面的有效管理。本文通过以软件生产者、软件选型/采购者、软件运维人员的身份进行阐述，建立软件物料清单所带来的优势和作用。

软件已无处不在，就像钢筋和混凝土一样，在互联网社会的今天，软件已非常普及。就像建筑行业，大家对使用什么建筑材料，怎么用都非常重视。软件已渗透到银行、医疗、公用事业、紧急服务、国防、政府系统。软件形式包括小工具、固件、操作系统、设备和其他机器。如同实物，软件也需要对它的成分、来源进行有效的管理。组件嵌套组件是常见现象，当某一个或几个组件因开发新功能、优化性能、修复 BUG等操作，就会影响其他调用的软件系统，所以供应商需要不断的对自己的软件进行更新和评估。评估对象包括使用的第三方组件是否发生变化，如何在整个软件供应链中管理这些组件，如何给出清晰的调用链关系？在复杂的软件供应链中，角色的定义已经变得模糊，为了简单起见，我们先从三个维度来描述软件供应链：

我是软件生产者：软件开发者，代码编写人员/组织，供他人使用的软件[编写/创建/组装/打包] 

我是软件选型/采购者：决定软件/产品/供应商的人/组织，使用[购买/获取/来源/选择/批准] 

我是软件运行者（运维人员）：操作软件组件的人/组织[使用/监控/维护/防御/响应]下表并可能并不是一个完整的观点列表，但是从通用的 3 个角色描述建立软件物料清单给他们带来的益处：

在软件普及之前，组织就已经考虑到软件存在多个生产阶段过程，每个阶段都是从前一阶段获取输入，经过自己的加工、研发，输出给下一阶段。初始阶段是软件的基本成分，末端是软件产品，是最终的用户或消费者。在整个供应链中，存在一个关键的问题：“给我输入的成分是否符合质量标准。我的输入是否正确，还是错误的？”

▪将现在软件开发视为供应链是很有用的 

▪软件开发人员编写满足需求的代码，然后免费提供或商用

▪ 其他有类似需求的开发人员找到该代码并将其包含在他们自己的软件中 

▪在某些时候，产品制造商将软件组件组集成到自己的产品中 

▪最终用户获取并操作产品

供应链的产生是产品制造方式变得简单，但它并不能回答所有可能的问题：当链条中的某个环节出现问题时会发生什么？在实物商品的世界中，“上游”部件可能会被召回或升级，供应链中的关系足够牢固，可及时通知“下游”进行相应的改变。在软件世界中，依赖关系之间的联系较弱。有些组件之间没有直接的商业关系。与大多数物理部件不同，软件组件不断变化，软件供应链中的每个成员都需要不断更新，应对软件新版本所带来的变化。由于软件供应链中复杂的依赖关系网，任何变化都会产生较大的影响。

本文档由用例工作组起草，作为 NTIA 软件组件透明度多利益相关方流程的一部分。该小组最初是由几个研究员组成。首先，类似 SBOM 这样机制已经在使用，因此应该将实例整理成文档。其次，参与者认为缺乏透明度的供应链是有问题的，软件透明度方案适用于整个软件供应链系统中，并不是仅仅是单个部门。第三，商业利益相关者认为，供应链的透明度的优势是明显的，因此需要整体规划。NTIA 倡议更多的生态合作伙伴一起参与 SBOM 的建设。该小组有两个目标：收集当前的 SBOM 用例，找出有效的方法和需要改进的地方，通过更广泛地收集 SBOM 的实践案例来改进用例。在大家意识到 SBOM 的重要性时，希望越来越多的人和组织都能加入进来了。这项工作的一部分灵感来自现有的工业供应链工作。我们调整了早期工作的框架，以更好地匹配当今软件行业的结构，并使所吸取的之前的经验。该小组每周举行一次电话会议，以提取重点和讨论用例。通过对供应链中不同参与者的交流，补充了工作组成员的专业知识。每次交流至少持续半个时，并详细记录问题，及时了解受访者对软件透明度的风险、成本和潜在价值的看法。该工组决定专注于三个角色（如上所述），并收集更多的软件透明度可以提供好处。

2.角色一：软件生产者

在现代软件编写中，代码复用是一个非常普遍的现象。代码开发者除了自己编写代码之外，还经常使用第三方代码和组件集成到自己的软件中。软件开发者会不断从社区和其他地方引入组件，为了保障软件持续迭代开发，组件的引入是由代码编写者和所在团队决策的，可见，组件的质量是整个产品高质量保障的关键。很多开源组织在审查开源软件时发现，很多产品和服务中使用了带许可限制的开源软件，但却没有遵守开源软件许可的要求。很快他们就意识到了使用这些带许可要求的软件是会引起安全问题的。软件物料清单对于软件供应链是必不可少的，如果产品缺少对软件成分的了解，就很难评估供应链的安全风险。

建立软件物料清单（SBOM），可以给软件开发者代理如下优势 ：

▪工作量减少

▪减少冗余代码 

▪充分了解组件的依赖关系 

▪明确组件开源许可 

▪监控组件安全漏洞问题 

▪组件全生命周期管理 

▪使代码更容易审查 

▪组件黑名单管理 

▪向用户提供 SBOM

SBOM 可以通过提供更好的代码库可以减少计划外、计划外的工作，通过代码层级关系，可以更快地对交付代码进行更新。例如，当出现新的安全漏洞时，如果没有 SBOM，软件开发人员将不得不审查他们所有的代码，以确定软件是否问题。如果软件建立了软件物料清单（SBOM），那么任何漏洞的组件都可以快速识别，同步提供所需修复方案，风险等级等，还可以节省大量的排查修复时间。

对开源组件进行统一管理，可以更好的减少代码冗余问题。业务系统在引用开源组件时，经常出现多版本的问题，这些版本的功能类似，但是却有不同的安全问题存在，同时增加了系统的代码量。而 SBOM 建立的是一套标准化通用的管理方式，首先解决的是一个组件多个版本的问题，将组件统一化。并且在漏洞出现时，只需要修复一个组件，其他相同组件均得到修复。

广义的说，软件物料清单（SBOM）的建立让开发人员更加了解自身系统组件的多层次的依赖关系，有助于提升软件开发者在组件优选和质量。更进一步来讲，SBOM 的建立可以帮助公司或产品团队更好的对业务系统组件的维护支撑，同时可有效支撑下游客户的安全评估。

SBOM 的建立可以让软件开发者充分了解组件许可，履行组件许可的义务。

SBOM 的建立可以帮助厂商开展关于组件漏洞的监控，给开发团队提供风险评估依据。例如，当安全研究人员发现新告警时，传统的漏洞排查过程比较漫长，但是使用 SBOM 模式下，可以更高效识别漏洞组件，同时也可以给用户展示我们的软件成分，对组件实现透明化管理。

当组件的生命周期结束 (EOL)，如社区或供应商声明不在维护或供应商消失了，软件开发者需要第一时间获知，并在突发事件到来之前做好替换计划。当建立 SBOM 之后，可主动、精准识别告警组件，并提供修复方案。

SBOM 建立组件和依赖组件的层次关系，便于研发人员快速完成代码审计，降低代码安全风险。大部分安全问题可以通过联系上下文在测试早期发现，因为代码编写会比组件的替换方案会早几周/几个月完成。此外，当底层依赖发生变化时，这种同步技术可以实现态势感知，更好的支撑代码修改工作和减少修改代码时间。

组件使用过程中支持黑、白名单的策略设置：黑名单提示公司规避使用；白名单虽然不常见，但可以作为公司受信任的组件推荐使用。通过 SBOM 中的信息反馈，可以选出更好的供应商、更安全的组件。

组织可以向客户或下游合作伙伴提供 SBOM，向他们说明公司提供的产品是满足安全需求和法律许可的。随着 SBOM 采用率的提高，积极主动提供 SBOM 信息，可以提升产品竞争优势，最终将会成为软件产品市场的必须交付件。SBOM 还可以向下游消费者阐明产品当前的安全状态，增加可信度。

3.角色二：软件选型/采购者

一旦选择并获取了任何软件包或组件，就必须对其进行安装、配置、维护和管理。我们将这些职责归为“运营”。它们因不同的组织而异，可能涵盖一系列潜在角色，从管理员到网络运营中心(NOC)或安全运营中心(SOC)，再到负责风险或合规性的高管，例如首席信息安全官(CISO)）。这些角色也可能适用于非 IT 软件包的运营，例如工业或运营技术(OT)环境中的嵌入式软件。

SBOM 可以通过以下方式帮助组织配置、维护和管理其软件：

▪组织可以快速评估它是否在使用该组件 

▪推动独立的缓解措施 

▪做出更明智的基于风险的决策 

▪对寿命终止的软件或组件进行告警 

▪更好地支持合规性和报告要求 

▪通过更精简和高效的管理降低成本

组织可以快速评估是否正在使用该组件

组件列表因为当前环境中被使用，使得其可以发现和关联新漏洞。SBOM 使得组织了解哪些组件在其系统和网络上处于活动状态。当发现特定组件中的任何新缺陷时，组织可以快速评估该组件是否正在使用，从而评估它是否存在风险

推动独立的缓解措施

在组织等待其供应商评估实际风险并根据需要提供软件更新时，对潜在风险组件的认识可以推动独立的缓解措施。一些组织可能决定自行采取防御措施，以尽量减少已知易受攻击软件的风险。比如补偿程序控制、对受影响系统进行技术隔离或加强对系统活动的审查。如果供应商没有积极支持有缺陷的软件组件，或者供应商不再存在，这些措施可能是仅有的缓解措施

做出更明智的基于风险的决策

广义上说，SBOM 允许运营商在他们自己的安全和风险方法的驱动下，就其网络上的内容以及如何确定响应的优先级做出更明智的基于风险的决策。正如几位参与者所说，SBOM提供了“防御者路线图”，尤其是发现的漏洞可能被广泛利用并被自动化工具（如 Metasploit）攻击时。

对寿命终止的软件或组件进行告警

仔细了解第三方组件可以对潜在寿命终止(EOL)情况进行告警。通过将来自 SBOM 的数据与其他数据源相结合，组织可以了解何时某个组件可能不再受到其供应商的支持。这将使该组织能够了解使用这些组件的软件的潜在连锁反应，并做出积极的决定，与他们的供应商合作或寻找替代方案。

更好地支持合规性和报告要求

有关组件的更多信息可以更好地支持合规性和报告要求。除了作为更详细的资产清单之外，SBOM 还支持监控已部署系统的安全风险（例如“上市后监控”）或跟踪安全告警。

通过更精简、更高效的管理降低成本

软件组件清单可以通过更加精简和高效的管理来降低成本。负责人可以快速确定关注点，当他们通过 SBOM 确定软件不包含缺陷组件时，他们无需花时间联系供应商。

软件选择包括软件产品的选择和采购。这些过程因组织机构的不同而不同，但是选择软件的方法有很多，其中有一些众所周知的通用步骤。

几乎所有的软件选择都是一项长期的投入，因此，在决定购买一个软件产品或组件时，必须经过仔细的思考和计划。这个采购过程可以是正式的或非正式的，并且可能包括诸如需求评审、市场调查、评估供应商和产品以及购买和验收软件等步骤。在一个常规的组织中，可能涉及多个职能团队，包括用户、财务、法务和技术支持。没有 SBOM 的软件消费者知道代码中可能有软件供应商没有公开的开源组件。这些成分可能包括不受支持（“孤立”）的库或具有已知漏洞的组件。恶意供应商可以将恶意软件隐藏在执行有用功能的组件中。

 SBOM 可以通过以下方式帮助组织选择他们的软件：

▪识别潜在易受攻击的组件 

▪更有针对性的安全分析 

▪采购验收 

▪遵守政策 

▪关注停止维护的组件 

▪验证声明·了解软件集成 

▪预购和预安装计划 

▪市场信号

4.1 识别潜在易受攻击的组件 

明确底层组件有助于识别潜在易受攻击的组件。在购买之前，组织可以进行基本的风险分析，以了解他们将要在其系统上安装什么。 

4.2 更有针对性的安全分析 

具有更成熟风险流程的组织可以通过确定哪些代码组件可能会引发危险信号（例如，提供不合标准保护的加密库）以及哪些组件可能已经通过可信来源的审查，从而参与更有针对性的安全分析流程。

4.3 验证来源 

如果 SBOM 包含组件的哈希签名，组织可以验证第三方组件的来源，以防止假冒或后门组件进入供应链的风险。（虽然 SBOM 可能不会直接阻止对手干扰合法来源，但一旦检测到攻击，它可以大大简化补救措施）“软件组件透明度”和“现有SBOM 格式和标准的调查  https://www.ntia.gov/files/ntia/publications/sbom_formats_survey-version-2021.pdf”中更详细地讨论 SBOM 的完整性和真实性。 

4.4 遵守 

组织可能面临有关供应链来源的法规或其他规则，而 SBOM 可以使其遵守在组织中必须使用或不可使用的政策。 

4.5 关注停止维护的组件 

组织需要了解未来将无法获得支持的停止维护组件。虽然这些组件在首次引入时可能没有风险，但后来在组件中发现的任何问题很可能无法修复。

4.6 验证声明

采购方将能够更好地验证供应商关于代码库及其质量的一些声明。虽然知道哪些组件和版本不会解决有关软件质量和安全性的所有问题，但它可以提供一些去洞察供应商的提示。 

4.7 了解软件集成 

组织可以更好地了解软件与现有资产和漏洞管理系统的集成，从而降低总体引入成本并最大限度地减少因集成恶意软件而出现风险的可能性。

4.8 预购和预安装计划 

组织可以为其仍坚持打算购买的易受攻击或过时的软件制定预购买和预安装计划。做出购买决定的原因很多，购买和使用的好处可能超过安全风险。在这种情况下，安全团队可以做出决定去区别对待更多有风险的系统，包括设计分段网络或列入白名单，并为安装和维护系统的运营团队准备检查清单。 

4.9 市场信号

最后，SBOM 提供了一个市场信号，表明供应商正在考虑其包含的组件可能带来的风险，表明供应商正在实施良好的软件开发流程并遵守一些最佳实践。通过奖励那些投入到安全和质量流程的供应商，这可以对供应商产生最显着的影响。选择软件就意味着选择供应商，而选择供应商也意味着选择该供应商作为后续选择。SBOM 确保这种透明度是可行的，因此买方可以做出更明智的选择。