需要考虑的8种顶级SBOM工具

写在前面：在软件供应链攻击中，SBOM在监管要求和技术实现上，都是相对容易落地的方式。本文中介绍的SBOM程序，有的是耳熟能详，有的也是第一次看到。大家可以参考本文中推荐的软件，和现实工作相结合。

2022年7月25 

       要真正保证软件的安全，您需要知道代码里面有什么。这就是为什么软件物料清单（SBOM）在今天必不可少。过去，我们并不太担心代码的安全性。糟糕的二进制文件？好像是；源代码本身有问题？没那么严重。我们都太蠢了。

       随后，安全问题接踵而至：SolarWinds软件供应链攻击，Log4j漏洞持续存在，npm维护者抗议代码出错，这些都表明我们必须清理我们的软件供应链。对于专有软件来说，这是不可能的，因为它的创造者不会让你知道程序里面有什么。但对开源程序，这就可以通过软件物料清单(SBOM)实现，发音为“s-bomb”。

       事实上，SBOM不再仅仅是一个好主意；这是联邦政府的命令。根据乔·拜登总统于2021年7月12日发布的《关于提高国家网络安全的行政命令》，这是一项要求。该行政命令将SBOM定义为“包含构建软件中使用的各种组件的详细信息和供应链关系的正式记录”。对于开源软件来说，这是一个特别重要的问题，因为“软件开发者和供应商经常通过组装现有的开源和商业软件组件来创造产品。”

这是真的吗？噢,是的。我们都知道，开源软件无处不在，随处可见。但是你知道吗，据Tidelift统计，92%的应用程序包含开源组件。事实上，现代程序平均有70%是开源软件。

       显然，我们需要做些什么。根据Linux基金会、开源安全基金会(OpenSSF)和OpenChain的说法，答案是SBOM。Linux基金会研发副总裁Stephen Hendrick将SBOM定义为“正式的、机器可读的元数据，它唯一地标识一个软件包及其内容；它可能包括内容的其他信息，包括版权和许可数据。SBOM被设计为跨组织共享，特别有助于提高软件供应链参与者交付的组件的透明度。”

最佳SBOM实践

       SBOM应包括:

• 应用程序的开源库

• 程序的插件、扩展和其他附件

• 由开发人员内部编写的自定义源代码

• 这些组件的版本信息、软件许可状态和补丁状态

• 自动组件加密签名和验证

• 自动扫描生成SBOM，作为持续集成/持续部署(CI/CD)管道的一部分

       SBOM也应该使用一致的格式。当前最常见的SBOM格式包括软件包数据交换(SPDX)、软件标识(SWID)标签和OWASP CycloneDX。虽然这些都是标准，但2021年的行政命令并没有强制规定特定的SBOM格式。到目前为止，这三家公司都没有从其他公司中脱颖而出，形成事实上的行业标准。

       为了使SBOM更加实用，我们不仅要推动自动化创建SBOM，还要使其成为CI/CD管道的一部分。正如国家电信和信息管理局(NTIA)所言，最终目标是按照“机器速度”生成SBOM。

SBOM使用场景

SBOM有三个不同的使用场景：

1. 软件生产商使用SBOM来帮助构建和维护他们提供的软件。

2. 软件采购人员使用SBOM来告知购买前的保证，协商折扣，并计划实施策略。

3. 软件操作人员使用SBOM通知漏洞管理和资产管理，管理许可和合规，并快速识别软件和组件依赖关系和供应链风险。

       这之间区别很大。开发人员希望能有在他们的CI/CD管道上工作的工具，如CircleCI、Jenkins或Travis CI。运营人员或客户可能甚至不知道什么是CI/CD管道，但可能非常关心资产管理和安全补丁更新。

       Gartner估计，到2025年，60%的构建或采购关键基础设施软件的组织将强制执行SBOM并将其标准化。如今，这一比例不到20%。

顶级SBOM程序

       使用三种不同的SBOM格式和各种各样的元数据来跟踪一个SBOM，这并不奇怪，还没有超级的SBOM 程序，应该有一个，但现在还不存在。

       许多SBOM程序，但不是所有，和代码安全扫描器绑定在一起。其他的程序，是否你想要他们取决你的需要。Gartner推荐你的工具具有如下功能：

• 在构建过程中创建SBOM。

• 分析源代码和二进制文件(如容器镜像)。

• 为这些工件生成SBOM。

• 编辑SBOM。

• 以人类可读的格式查看、比较、导入和验证SBOM。

• 从一种格式或文件类型合并和转换SBOM内容到另一种格式或文件类型。

• 通过API和库支持在其他工具中使用SBOM操作。

       以下程序没有一个能实现所有这些建议。即使是这些项目中最成熟的Anchore、FOSSA和Rezillion，也还在发展中。

       我建议您尝试这些程序中的大部分(如果不是全部的话)，看看哪一个最适合您和您的特定情况。然后给供应商和开发人员你的反馈。如果我们在2025年前做到这一点，我们可能会有一个针对所有不同用途的明确的最佳方案。

       以下是值得你关注的8个SBOM程序:

Anchore

       Anchore已经在SBOM行业工作了6年。它的基础是两个开源项目：Syft是一个命令行接口(CLI)工具和库，用于从容器镜像和文件系统生成SBOM；Grype是一个易于集成的容器镜像和文件系统漏洞扫描工具。

       您可以在开发过程的每个阶段，从源代码存储库和CI/CD管道到容器注册中心和运行时，使用它们一起生成SBOM。这些SBOM保存在一个集中存储库中，以实现完全的可见性和持续的监视，甚至在部署后也是如此。它支持CycloneDX, SPDX和Syft自己的SBOM格式。

       Anchor将其SBOM功能捆绑到Anchor Enterprise 4.0软件SCM(供应链管理)平台中。Anchore的目标是成为您一体化的软件供应链和SBOM安全公司。他们做得很棒。

FOSSA

       FOSSA的旗舰程序是一个开源许可证管理器和一个开源漏洞扫描器。仔细想想，SBOM非常自然地适合这些程序。

       在FOSSA的方法中，你可以将它的SBOM工具与你喜欢的版本控制系统集成，如GitHub、BitBucket或GitLab。或者您可以使用它的命令行并在本地运行它，或者将它集成为CI/CD管道的一部分。

       无论哪种方式，当您扫描您的项目时，FOSSA将自动识别目标代码库的直接依赖项和深度依赖项。这些深度嵌入的代码问题，比如对Log4j的间接依赖调用，可能隐藏在程序中，黑客仍然会利用它们进行破坏。

Mend

       Mend就是曾经的WhiteSource，它提供了各种软件成分分析(SCA)工具。SBOM被合并到其Mend SCA工具中。因此，Mend与其说是一个开发人员程序或CI/CD工具，不如说是程序员的开源许可和安全机制。

       因此，可以使用Mend跟踪每个组件，包括直接和传递性依赖、识别漏洞、提供修复路径，并在组件更改时自动更新SBOM记录。该公司声称其专利的可达性路径分析可以告诉您哪些漏洞可以被安全忽略，因为您的应用程序没有使用这些库，或者这些库的使用方式没有暴露这些漏洞。

Rezilion

       DevSecOps公司Rezilion将SBOM作为其整体软件安全和漏洞系统的一部分。它的动态SBOM使用动态运行时分析来跟踪代码更改时的软件攻击面。因此，它会不断查找代码组件的已知弱点。换句话说，这是跟踪和保护代码的二合一方法。

       除了提供CI/CD、staging和生产环境中所有软件组件的实时清单外，它还会不断更新您的SBOM。您可以导出您的SBOM的CycloneDX和Excel电子格式。

SPDX SBOM Generator

       SPDX SBOM Generator是一个独立的开源工具，顾名思义：它从当前的包管理器或构建系统创建SPDX SBOM。您可以使用它的命令行从代码生成SBOM数据。它报告代码的组件、许可、版权和安全引用。该数据在SPDX v2.2规范中导出。如果你只需要基础信息，它会很适合你。

Tern Project

       另一个开源SBOM项目，Tern可能与SPDX SBOM Generator很好地配合。不使用包管理器或构建系统，这个SCA工具和Python库为容器镜像和Dockerfiles生成一个SBOM。它还生成SPDX格式的SBOM。

TauruSeer

       这个SBOM程序是以软件即服务(SaaS)的形式提供的。凭借以应用为中心的专利集成方法，Tauruser将认知引擎安全扫描与SBOM相结合。该包将帮助您为开发人员和客户保护和跟踪您的代码。

Vigilant Ops

       Vigilant Ops是一家医疗设备网络安全公司，其InSightPlatform已将注意力转向SBOM。它的SaaS平台产生、维护、验证共享的认证SBOM。它通过持续的漏洞监视和警报集成了安全性。其SBOM认证采用专利算法，确保所有组件都经过验证，漏洞都有对应链接。

       它的安全特性还可以用于其他程序生成的SBOM，它们在静止和传输过程中都被加密。

https://www.csoonline.com/article/3667483/8-top-sbom-tools-to-consider.html

（完）

原文始发于微信公众号（安全行者老霍）：需要考虑的8种顶级SBOM工具