软件物料清单:概述

您如何防范软件供应链安全风险——即源于您的业务使用或依赖的第三方软件资源的安全问题?2022世界杯阿根廷预选赛赛程

答案的关键部分是生成软件物料清单(SBOM)。通过系统地列出每个应用程序中存在的组件，以及应用程序运行所需的依赖关系，soms提供了企业检测和响应软件供应链安全风险所需的关键可见性。此外，在某些情况下，soms可以帮助解决遵从性需求，并向客户和合作伙伴保证您的企业认真对待供应链安全。

请继续阅读有关SBOM是什么、SBOM如何工作、它们为什么重要以及如何生成SBOM的解释。

什么是SBOM?

软件物料清单(Software Bill of Materials，简称SBOM)是应用程序使用的所有组件和依赖项(专有的和开放源码的)的列表。soms通常还包括每个组件和依赖项的版本详细信息，这很重要，因为安全问题通常只影响特定版本的软件。

soms通常以特定的方式格式化，它们通常可以表示为XML或JSON文件。也就是说，SBOM的确切性质取决于团队选择记录和构建SBOM信息的SBOM标准(如CycloneDX、SPDX或SWID)。但是，尽管存在细微的差异，所有SBOM格式的重点都是使一目了然地确定业务使用的每个应用程序中的内容。

为什么小企业很重要?

soms是系统地跟踪应用程序组件和依赖项的唯一方法。通过扩展，它们提供了必要的信息，以确定是否有任何组件或依赖关系受到安全风险的影响。

soms也很重要，因为在某些情况下，它们可能是监管机构或客户所要求的。例如，在2021年，美国联邦政府宣布计划要求供应商提供soms它们与政府机构有业务往来，这是确保政府机构能够了解它们所依赖的软件的努力的一部分。

最重要的是，即使您的客户、合作伙伴或监管机构没有严格要求soms，生成它们也是显示您认真对待软件供应链安全性的好方法。soms让外部涉众安心，因为它可以看到软件组件和依赖关系，并能够确定第三方软件是否将它们置于风险之中。

soms vs.手工软件组件管理

当然，您可以尝试手动跟踪组件和依赖项，方法是要求开发人员根据请求列出它们，或者尝试在文档中非正式地跟踪这些信息。然而，这种方法的问题在于:

• 这不是系统性的:当您缺乏定义和格式化这些信息的系统过程时，很容易忘记注意重要的依赖项或组件。
• 很难分享:关于软件组件的非正式信息很难与监管机构、审计机构、合作伙伴和客户共享，因为他们可能无法访问您存储信息的位置。他们可能也不确定如何解释它。

soms解决了这两个问题，它提供了一种系统的、标准化的方式来定义您的业务使用的每个应用程序的内容。当您将SBOM生成作为应用程序交付过程的一个标准部分时，您可以将忘记记录重要软件供应链信息的风险降至最低。您还可以使信息易于与任何需要访问它的涉众共享。

SBOM例子

SBOM由软件中存在的各种开放源代码和专有组件的列表组成。如上所述，列表通常使用XML或JSON进行结构化，这使得可以将SBOM分解为不同的部分，不仅定义应用程序组件，还定义与它们相关的元数据。

例如，下面是一个JSON格式的简单SBOM文件，符合CycloneDX SBOM标准:

{"$schema": "http://cyclonedx.org/schema/bom-1.2a.schema.json"， "bomFormat": "CycloneDX"， "specVersion": "1.2"， "version": 1， "metadata": {"tools": [{"vendor": "CycloneDX"， "name": "CycloneDX -php-composer"， "version": "dev-master"}]， "component": {" home -ref": "pkg:composer/ CycloneDX /cyclonedx-php-composer-demo@dev-master"， "type": "application"， "name": "CycloneDX -php-composer-demo"， "version": "dev-master"， "group": "CycloneDX"， "description":"演示cyclonedx/cyclonedx-php-composer与laravel/framework的绑定版本"，"purl": "pkg:composer/cyclonedx/cyclonedx-php-composer-demo@dev-master"}}， "components": [{" home -ref": "pkg:composer/asm89/stack-cors@1.3.0"， "type": "library"， "name": "stack-cors"， "version": "1.3.0"， "group": "asm89"， "description": "Cross-origin资源共享库和堆栈中间件"，"licenses": [{"license": {"id": "MIT"}}]， "purl":"pkg:composer/asm89/stack-cors@1.3.0"， "externalReferences": [{"type": "distribution"， "url": "https://github.com/asm89/stack-cors.git"， "comment": "由composer的' getSourceUrls() '检测到(type=git & reference=b9c31def6a83f84b4d4a40d35996d375755f0e08)"}， {"type": "distribution"， "url": "https://api.github.com/repos/asm89/stack-cors/zipball/b9c31def6a83f84b4d4a40d35996d375755f0e08"， "comment": "由composer的' getdisabls() '检测到(type=zip & reference=b9c31def6a83f84b4d4a40d35996d375755f0e08 & sha1=UNDEFINED)"}， {"type": "website"， "url": "https://github.com/asm89/stack-cors"， "comment": "通过composer包定义中的'主页'设置。"}， {"type": "issue-tracker"， "url": "https://github.com/asm89/stack-cors/issues"， "comment": "As set via ' support. "编写器包定义中的问题。}， {"type": "distribution"， "url": "https://github.com/asm89/stack-cors/tree/1.3.0"， "comment": "As set via ' support. "在编写器包定义中的源。”}]}，]}

这个SBOM的第一个主节定义了与SBOM本身相关的元数据，比如SBOM标准和正在使用的格式。然后，该SBOM包含一个“组件”:节，这是SBOM的“主体”所在。组件部分列出了所讨论的应用程序中包含的特定包，以及相关数据，如包url、网站、许可信息，甚至问题跟踪器的位置。

使用这些信息，开发人员、IT工程师、安全团队、DevOps团队和DevSecOps团队不仅能够确定SBOM应用的软件中存在哪些依赖关系和组件，还能够确定这些组件来自哪里，以及在哪里可以找到有关它们的更多信息。

SBOM工具

您可以手动读取SBOM以查找此信息。或者，您可以利用各种工具来帮助解析和可视化SBOM文件。但是请注意，大多数SBOM工具被设计为只能使用特定的SBOM标准，因此您需要确保选择与您的SBOM标准和格式兼容的工具。例如，如果您想要与cyclonedx兼容的工具，您可以在CycloneDX网站．

SBOM工具以及如何生成SBOM

生成SBOM的最有效方法是利用SBOM工具自动跟踪每个应用程序的组件和依赖关系，以及它们的版本，然后以标准化的SBOM格式(如CyloneDX、SPDX或SWID)报告这些信息。

使用SBOM工具，您可以使SBOM生成成为CI/CD过程的自动化部分。SBOM工具可以自动扫描每个新的应用程序构建或包，以确定应用程序的组件是否已更改，从而确保SBOM保持持续更新。

有关创建和使用soms的更多提示，请查看我们的文章物料清单管理最佳实践．