Log4Shell风波后，为什么软件物料清单（SBOM）至关重要

【】

作者丨Josh Bressers

译者丨赵青窕

策划丨孙淑娟

在此次 Log4Shell 风波后，对于定位解决新出现的软件供应链中的漏洞和攻击来说，生成 SBOM 并快速地获取其信息已经变得至关重要。

同许多零日漏洞一样，相关的组织或者机构正在全力地识别修复 Log4j 中 Log4Shell 漏洞的影响。这种漏洞是极其危险的，因为该漏洞存于一个极其常用的库中，并且很容易被利用。目前的关键因素是，在具体的漏洞相关细节被公开之前，它已经被广泛地利用，从而迫切地需要尽快修复。

在 24 小时的修复工作之后，安全和应用程序团队喘了一口气，接下来他们将进行回顾和审查的工作，以便为下一个零日漏洞的定位做准备。在这种新环境下，软件物料清单 (SBOM) 正在成为一种至关重要的安全要求，它使软件在整个供应链中具有可见性。因此我们必须立即行动起来建立一个关键的新功能：SBOM 管理。

创建一个综合性的 SBOM

目前，行业领导者采用的最佳实践是为每个交付或部署的应用程序版本生成一个软件材料清单(SBOM)。事实上，最近美国关于国家网络安全的行政命令将要求软件供应商向联邦机构提供他们销售或交付的软件的 SBOM。

如果我们从广义的角度来看，生成 SBOM 只是第一步。正如 Log4Shell 向我们展示的那样，当新的零日漏洞发生时，我们需要能够轻松地利用和搜索 SBOM。生成 SBOM 很容易，但管理和跟踪数百或数千个 SBOM 是一项艰巨的任务，而且对于处理不断变化的威胁情况也是一项困难的任务。

虽然今天在交付应用程序之前扫描漏洞是很常见的，但这远远不够。扫描应用程序以识别组件和相关漏洞应该是一个持续的过程，不应该只运行一次，而应该定期运行。每次扫描应用程序时，都必须记录和分析结果。为了从一个点对点的系统转移到一个连续的系统，工具和自动化是很重要的。

一个组织或机构在开发应用程序时，通常包括大量的开源代码以及内部开发的代码和第三方的商业库。SBOM 生成工具可以检查编写的代码，包括其中使用的开源代码，但针对商业库，根据其打包方式的不同，可能会无法扫描到。鉴于这种情况下，需要商业库的供应商提供商业库对应的 SBOM。有了所有组件的 SBOM 之后，就需要将它们组合起来，生成覆盖整个应用程序的聚合 SBOM。

SBOM 管理所需的关键功能

使用 SBOM 作为确保软件供应链安全的基础，但随着时间的推移，越来越多的 SBOM 将被生成和包含。因此需要工具和自动化来管理复杂的 SBOM。查找的功能包括:

一个集中的存储库，用来存储跨产品团队和应用程序的 SBOM。

具备快速查找有问题组件的应用程序的搜索能力。

具备生成或导入由软件供应商或开源项目组提供的 SBOM 的能力。

可以整合所有组件级的 SBOM，从而为应用程序创建一个综合性的 SBOM。

支持复杂的 SBOM 标准以及 SPDX 之类的轻量级 SBOM 标准。

可以针对一个应用程序的多个释放的版本，多个构建版本，或者开发的不用阶段，分别存储其对应的 SBOM 的能力。

具备 SBOM 比较的能力，以便检测到异常后，对可能发生的纂改给予警告。

SBOM 事件响应速度

一旦您为一个已发布应用程序版本获得了一组明确而准确的 SBOM，您就需要将这些 SBOM 存储在一个集中的存储库中，以便快速扫描和搜索 SBOM 的内容。集中式方法意味着安全团队不必浪费时间来确定在他们的应用程序中部署了哪些组件。当下一个重大漏洞出现时，SBOM 管理工具应该立即返回结果。应用策略引擎和策略规则将会向所有受影响的应用程序团队生成通知和警报。这样应该在几分钟内就会知道哪些应用受到影响，以及如何进行补救，而不是花费几周的时间去定位问题。