SBOM: 过度炒作的概念并不能保护供应链安全

了解SBOM

SBOM就像是商店里食物包装背面的营养成分清单一样，记录着该商品包含的所有成分。尽管目前官方还未出台SBOM的统一标准，但一些非官方的格式标准已经成为了最佳的候选格式。迄今为止，市面上最受欢迎的标准是由Linux基金会赞助的软件数据包交换标准(SPDX)。

同大多数格式一样，SPDX试图提供一种通用的方法，来表示软件生产中有关成分的基本信息，包括：名称、版本、哈希、软件生态、已知漏洞和许可证信息等辅助性数据以及相关的外部资产。然而，软件并不像食品那样简单，也没有像美国食品药物管理局那样的机构来强制执行一些推荐指南。

所有东西都是可选的，因此不需要任何东西

SPDX与其他标准之间最大且最明显的差异之一就是，它同整个开源生态系统一样，不是经过验证的标准，而是一套建立在通用指导方针之上的社区di。开源社区的范围十分广阔，其成员遍及世界各地。通常情况下，包管理器和托管环境都是由不同的委员会来设定，且这些委员会都是独立运营的。尽管SBOM的标准代表了将众多信息库统一起来的早期尝试，但是它们受到了追溯应用标准的一些基本限制。

首先，当我们思考到“SPDX实际提供了什么”时，差异就开始逐渐显现了。事实证明，在该标准中，几乎每个字段都是可选的。然而，这种字段的可选性显然是在试图消除不同软件生态系统之间差异。如果没有加密哈希或其他信息来帮助我们将库与SBOM文档所提供的信息进行主动联系的话，那么作为真相来源的SBOM就失去它的本质作用。

SBOMs 未能实现“来源”功能

除了不完整这一特点之外，许多输入的内容也无法以当前的格式正确表示，尤其是来自类似与版本控制系统存储库等地方的输入。虽然像SLSA这样的新兴框架正在尝试着应用“来源”的概念，然而目前并没有任何一种格式可以成功做到这一点。我们必须将准确的来源数据集成到SBOM格式中，以确保我们能够对自己所使用软件的内部构成有一个清晰的了解。至少也应该了解以下内容：

● 作者身份信息: 无论是维护者，还是创作者，两者都是供应链的重要组成部分。它们掌握着进入“王国”的钥匙，并决定着我们在下游所使用的软件会如何发布。即使不能获取完整的数据，但至少我们绝对会做得比现在更好。

● 开发工具: 这包括构建工具、CI/CD基础设施以及在上游的软件开发过程中所使用的工具。想象一下，如果组织使用的库所携带的漏洞会被引入到组织内部的话，那么单纯地保护内部开发基础设施又有什么用呢?

● 控制和保护: 如果要进行第三方风险管理，那么我们必须要搞清楚几个问题：开发团队的安全态势是什么样子的?是否使用了分支机构保护装置?以及采用了什么样的审查流程?

● 工件证明: 对于SBOM文档中的每一个条目，都必须要有一个与之进行绑定的实际工件。这应该包括一个实际的构建工件，以及一个持续开发的工件，例如版本控制系统中的标记分支。

实际上，在考虑SBOM的操作方式之前，我们还必须要对上述的每一个元素都有一定的了解，这样才能更好地理解我们正在使用的软件中的内容构成。

我们不能依赖简单的快照

最后，SBOM普及过程中的最大挑战就是，静态格式的SBOM只能提供软件当时的情况相关信息，而无法时刻更新即时的相关内容。为了使数据更加有意义，SBOM必须具有连续交付和访问的能力。

如果一个企业将从云存储提供商那里接收到一个供应商SBOM。那么该SBOM文档中不仅会包含着成千上万的关于软件的片段，而且还会记录着这些软件包的多个版本。并且，由于大型企业每天都要发布数百甚至数千个版本，所以当该企业收到这些信息时，它很可能就已经过时了。也就是说，当你为任何一个大型企业创建出SBOM的时候，这些数据就已经了失去效用价值。

版本的迭代总是伴随着一些包的新增以及另一些包的删除。现代开发的最佳实践意味着软件的构建和交付是持续进行的，这也将会导致版本迭代的加快，以及发布周期的缩短。而这同时也意味着对于SBOM的交付几乎是毫无意义的。所以说，为了使SBOM发挥其真正的价值，那么围绕着SBOM的可扩展自动化就显得十分有必要的了。

SBOM背后最主要的目的只是提高软件内容和外部的可见性。所以，不要误以为它们会保护你的软件供应链。而我们需要仅仅是一个能够真正发挥作用的部分及时的信息而已。

来源：数世咨询