软件供应链的基础:SBOM

软件作为一种强大的工具，可以简化复杂的技术概念，但随着软件不可思议的力量而来的是一个相互关联的软件依赖迷宫，这些依赖常常构成软件开发的基础。这些依赖关系并非没有缺陷，正如我们从 Log4Shell 这样的事件中所了解到的那样。当我们试图驾驭不断变化的软件供应链安全时，我们需要确保我们的应用程序建立在坚实的基础之上。

在这篇博文中，我们将深入探讨软件物料清单(Software Bill of Materials，SBOM)的概念，它是安全软件供应链的基本需求。正如物理供应链需要仔细检查以确保产品的质量和安全一样，软件供应链也需要严格的评估。危在旦夕的不仅仅是应用程序的功能，还有应用程序可以访问的信息的安全性。让我们深入到软件供应链的世界中，探索 SBOM 如何作为软件开发和安全中更具弹性的未来的基石。

什么是软件供应链攻击？

供应链攻击是针对应用程序组件的供应商而不是应用程序本身的恶意攻击。软件供应链类似于物理供应链。当你购买 iPhone 时，你看到的只是成品。在最终产品的背后，是一个由零部件供应商组成的复杂网络，这些供应商随后被组装在一起，生产 iPhone。来自日本公司的显示器和相机镜头，来自亚利桑那州的 CPU，来自圣地亚哥的调制解调器，来自加拿大矿山的锂离子电池; 所有这些部件在深圳组装工厂组装成最终产品，然后直接运到你的家门口。

同样，攻击者可以在 iPhone 组装之前针对 iPhone 供应商之一修改组件，软件供应链威胁参与者也可以这样做，但是目标是随后内置到商业应用程序中的开源软件包。当70-90% 的现代应用程序是使用开源软件组件构建时，这就是一个问题。有鉴于此，供应链的安全性取决于其最薄弱的环节。

所有这些依赖关系都赋予了软件开发人员构建极其复杂的应用程序的超能力，这些应用程序可以非常快速地构建，但会产生无意识的副作用，即他们不可能理解所有组成要素。这给予了攻击者机会。一个受到攻击的包允许攻击者操纵其入口点“下游”的所有包。

在 Log4j 事件中，软件行业(以及所有依赖软件行业的行业，也就是所有行业)深切地感受到了这一现实。

Log4Shell 冲击

Log4Shell 是软件供应链安全重要性的典型代表。我们不打算在这篇文章中深入探讨这起事件。事实上，我们已经在之前的博文中做到了这一点。相反，我们将关注事件对在应用程序中有 Log4j 实例的组织的影响，以及他们为了修复这个漏洞而必须经历的事情。

首先让我们回顾一下时间线:

Log4j中的漏洞最初是在11月24日私下披露的。五天后，发布了一个pull请求来关闭该漏洞，一周后，新的软件包发布了。官方的公开披露发生在12月10日。这就是混乱开始的时候，公司开始确定他们是否是脆弱的，并找出如何补救漏洞的工作。

平均而言，受影响的个人花费约90小时处理 Log4j事件。大约20%的时间用于确定 log4j 包部署到应用程序的位置。

从与我们的客户和潜在客户的对话中可以看出，为什么这占用了如此多的时间，主要的罪魁祸首是一个组织是否拥有一个关于软件依赖关系的元数据的中央存储库，这些元数据已经被用于构建他们的应用程序。对于拥有中央存储库和查询数据库的客户来说，识别哪些应用程序存在 log4j 漏洞的步骤需要1-2个小时，而不是像其他组织那样需要20多个小时。这就是为所有软件准备好 SBOM 的力量，也是帮助进行SBOM管理的工具。

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

与您购买的食品背面的营养标签类似，SBOM 是一个成分列表，这些成分进入您的应用程序使用的软件。我们通常认为 SBOM 是开发过程的产物。作为一个开发人员，他们使用不同的依赖关系来制造他们的应用程序，同时他们也在构建一个基于成分的配方。实际上，可以(也应该)在构建管道的所有步骤中生成 SBOM。源代码、构建、映像和生产软件都可以用来生成 SBOM。

通过使用 SBOM 作为金字塔的基础，组织可以确保它们层叠到这个基础上的所有附加安全特性将经得起时间的考验。只有当我们对用于生成“成分”标签的过程有信心时，我们才能知道我们的软件没有已知的漏洞。签署软件以证明软件包没有被篡改，只有当签署的软件都没有已知的漏洞时才有效。签署一个易受攻击的软件包或图像只能证明从那时起软件没有被篡改过。它不能回顾过去并验证之前出现的软件包在没有 SBOM 或漏洞扫描器帮助的情况下是安全的。

利用软件物料清单(SBOM)作为软件供应链安全的基本要素有以下优势:

透明性: SBOM 提供了应用程序中使用的所有组件的全面视图。它们揭示了构成软件的“成分”，使团队能够理解他们的应用程序的整个组成，包括所有的依赖关系。不再有黑盒依赖关系和随之而来的相关风险。
风险管理: 借助 SBOM 提供的透明度，组织可以识别其软件组件中潜在的安全风险，并主动解决这些风险。这包括检测依赖项或第三方组件中的漏洞。SBOM 允许组织标准化其软件供应链，从而允许对脆弱性管理和影响风险管理采取自动化方法。
快速响应漏洞: 当在软件中使用的组件中发现新的漏洞时，SBOM 可以帮助快速识别所有受影响的应用程序。这大大减少了响应和补救这些漏洞所需的时间，最大限度地减少了潜在的损害。当一个事件发生，而不是如果，一个组织能够迅速反应的缺口和限制的影响。
守规: 法规和标准越来越要求 SBOM 展示软件的完整性。通过合并 SBOM，组织可以确保它们满足这些遵从性需求。尤其是在与联邦政府、金融服务业和医疗保健等受到高度监管的行业合作时。
信任和验证: SBOM 通过允许用户验证所使用的组件来促进对软件产品的信任和信心。它们作为客户、合作伙伴和监管机构的“诚信证明”，展示了该组织对安全的承诺。它们还支持更高级别的安全抽象，如签名映像或源代码，以继承 SBOM 提供的底层基础安全保证。

通过将 SBOM 放在软件供应链安全的基础上，组织可以建立一个安全、有弹性和高效的健壮结构。使用软件材料清单(sBOMs)作为安全软件供应链的基石，提供了一个根本性的转变，即提高透明度、改善风险管理、更快地应对脆弱性、提高守规和加强对软件产品的信任。通过解开软件应用程序中复杂的依赖关系迷宫，SBOM 提供了识别和处理潜在弱点的必要见解，从而创建了一个能够抵御潜在安全威胁的弹性结构。面对 Log4Shell 这样的事件，业界需要采取积极主动的战略方针，强调建立一个经得起时间考验的安全基础。通过提升 SBOM 的作用，我们正朝着软件开发和安全的未来迈出关键的一步，这种未来不仅是创新的，而且是安全、可信和高效的。SBOM 提供了这方面的知识，因此是全面安全战略不可或缺的基石。