如果我们可以枚举我们使用和生产的所有软件组件，并且我们可以轻松地分发和使用它会怎样？这就是 SBOM 试图解决的问题。
在最近的许多安全事件中，我们听到很多关于缺乏代码依赖知识、软件供应链攻击、软件物料清单 (SBOM)、数字签名、出处、证明等方面的信息。
事实是，每当环境中出现新的漏洞时，我们通常需要花费大量时间和精力来检测对我们环境中运行的应用程序和服务的真正影响。
如果我们有办法枚举我们使用和生产的所有软件组件，并且我们能够轻松地分发和使用它会怎样？
这就是 SBOM 试图解决的问题，我们想解释一下。 让我们深入了解SBOM的细节！
什么是 SBOM？
软件物料清单只是一个工件，其中包含组成软件的软件包依赖项、文件、许可证和其他资产的综合列表。
根据 NTIA SBOM 常见问题解答：
软件物料清单 (SBOM) 是一份正式记录，其中包含用于构建软件的各种组件的详细信息和供应链关系。这些组件（包括库和模块）可以是开源的或专有的、免费的或付费的，并且数据可以广泛使用或限制访问。
这个概念并不是什么新鲜事物，BOM（材料清单，没有“软件”）一直是工业流程的一部分。它们与“成分列表”非常相似，尽管 BOM 通常包含“层次结构”的概念，因此每个组件都被分解为子组件列表，其中又包含每个组件的 BOM。
在软件物料清单中，“片段”通常是抽象库、模块、二进制文件、编译器、文件等，它们通常包括许可信息（Apache 2.0、GNU、BSD ……）和其他元数据。
SBOM 是最近的事吗？
并不真地。它可能看起来很新，但开源社区在 10 多年前就注意到创建 SBOM 的必要性，SPDX 开放标准于 2010 年开始作为解决该问题的初步努力。
事实是，由于与供应链相关的攻击增加，近年来事情开始快速发展：
所以，尤其是2021年以来，大家似乎都在关注和谈论它。而这仅仅是个开始。2022 年将成为行业如何应对 SBOM 和软件供应链安全挑战的转折点。
SBOM 适用于何处？
SBOM适用于构建软件产品时使用的任何软件组件，无论是外部的还是内部的、开源的或专有的（如文件、包、模块、共享库等）。这也包括固件和嵌入式软件。硬件可能参与软件的分发或执行（例如，网络设备、加密设备、芯片……），但它不被视为 SBOM 的一部分，尽管 CycloneDX 等标准也支持将设备作为一种组件。
在理想的世界中，每个软件公司都会将 SBOM 附加到每个可交付成果，并且每个人都可以完全了解软件中使用的组件，并确切地知道哪些漏洞正在影响该软件。
但并不是花园里的一切都是玫瑰色的。
有哪些典型的资产可以有一个伴随的 SBOM？
在任何情况下，SBOM 都应该捕获多级依赖关系。因此，例如，如果包libfoobar-1.5.3-r3-u8 是 SBOM 的一部分，它还应该包括用于组装libfoobar-1.5.3-r3-u8 的每个包名称、版本、许可证等，以及每个节点的组件，从而形成一个多级树，其中每个节点都分解为其依赖项。
同样重要的是要指出，每次资产发生变化时，例如在产品的每个版本甚至每次构建时，都应该创建一个新的 SBOM 以匹配该版本的更改。
为什么我需要 SBOM？
首先，因为没有 SBOM，您就没有可见性。就组装它的包和库而言，一个软件是一个黑盒子。
我们需要 SBOM 的原因与我们需要食品成分清单的原因基本相同。您可以检查是否存在过敏原、素食主义者的动物物质、化学防腐剂等。当然，你可以在不检查配料表的情况下吃食物，但你要承担一些风险。这同样适用于软件：在沙盒环境中使用对快速测试的任何依赖可能是正确的，但在将关键服务部署到生产或在具有严格合规性法规的环境中交付软件时，您肯定想知道里面有什么。
第三方依赖项的 SBOM 的可用性还使您可以更轻松地构建软件的 SBOM，只需从依赖项中组合列表并添加您自己的成分。请注意，您的软件也可以是更复杂产品的输入或依赖项，并且消费者可能要求将 SBOM 的存在作为其供应商最低要求的一部分。
了解不同软件的许可证也非常重要。否则，分发在多种许可下使用第三方库的软件可能会违反使用条款或迫使您公开源代码，这可能会带来不便，甚至会给您的公司带来麻烦。
最后，SBOM 是漏洞扫描过程中的关键部分。如果您拥有准确的 SBOM 以及来自不同供应商和来源的可靠且更新的漏洞源，那么查找软件中存在哪些漏洞非常简单。
如果没有 SBOM，漏洞扫描软件需要计算和猜测 SBOM，这对于一些不透明的组件来说可能非常棘手甚至是不可能的。
一个好的 SBOM 还应该允许回答问题，例如“我是否容易受到 CVE-2022-22965 ( Spring4Shell ) 漏洞的攻击？” 如链接文章中所述，利用此漏洞需要在运行可利用 Java 包的主机或容器中同时发生一组条件：
大多数这些情况都可以在综合 SBOM 的内容中进行检查，通过首先专注于修复可利用的应用程序，可以更轻松地评估环境中的风险。
如何创建 SBOM？
生成 SBOM 是一个复杂的话题，具有多个相互竞争的标准、分布等，使得采用速度比预期的要慢。
存在许多可以帮助您为软件创建 SBOM 的工具。但即使在考虑生成 SBOM 之前，构建过程完全自动化（这是SLSA 框架中的第 1 级）并且 SBOM 创建被集成为构建管道的一部分是至关重要的。
接下来，这些是开源工具的一些示例执行和输出以及相应的 SPDX 或 CycloneDX（截断）SBOM，这是两个最常见的标准。
Syft
Syft可以从文件系统或容器映像生成 SPDX 或 CycloneDX 格式的 SBOM，默认情况下，它使用docker sbom 命令嵌入到 Docker 中。
当使用-o标志将输出设置为spdx-json 格式时，它将生成如下文档：
$ syft -o spdx-json neo4j:latest
? Parsed image
? Cataloged packages [376 packages]
{ “SPDXID”: “SPDXRef-DOCUMENT”, “name”: “neo4j-latest”, “spdxVersion”: “SPDX-2.2”, “creationInfo”: { “created”: “2022-06-23T10:09:26.751733Z”, “creators”: [ “Organization: Anchore, Inc”, “Tool: syft-0.48.1” ], “licenseListVersion”: “3.17” },
…
“packages”:
[ {
“SPDXID”: “SPDXRef-fd9f083cc189cf0c”,
“name”: “CodePointIM”,
“licenseConcluded”: “NONE”,
“checksums”: [ { “algorithm”: “SHA1”, “checksumValue”: “50a6f2c46702b14cb129aac653d9abfcdc324363” } ],
“downloadLocation”: “NOASSERTION”, “externalRefs”: [ { “referenceCategory”: “SECURITY”, “referenceLocator”: “cpe:2.3:a:oracle-corporation:CodePointIM:11.0.15:*:*:*:*:*:*:*”, “referenceType”: “cpe23Type” },
…
{ “referenceCategory”: “PACKAGE_MANAGER”, “referenceLocator”: “pkg:maven/CodePointIM/CodePointIM@11.0.15”, “referenceType”: “purl” } ], “filesAnalyzed”: true,
“licenseDeclared”: “NONE”,
“sourceInfo”: “acquired package info from installed java archive: /usr/local/openjdk-11/demo/jfc/CodePointIM/CodePointIM.jar”,
“versionInfo”: “11.0.15” },
{ “SPDXID”: “SPDXRef-80979ce84b1617b2”,
“name”: “FastInfoset”,
“licenseConcluded”: “NONE”,
… },
… ],
“files”: [ {
“SPDXID”: “SPDXRef-9e950849d3fbc974”,
“comment”: “layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be”,
“licenseConcluded”: “NOASSERTION”,
“fileName”: “/bin/bash” },
{ “SPDXID”: “SPDXRef-d1fd1bc48eedeaba”,
“comment”: “layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be”,
“licenseConcluded”: “NOASSERTION”,
“fileName”: “/bin/cat” }, … ],
“relationships”: [ { “spdxElementId”: “SPDXRef-a124711c55c5b5ec”, “relationshipType”: “CONTAINS”, “relatedSpdxElement”: “SPDXRef-9f73084aac22b0b3” }, { “spdxElementId”: “SPDXRef-a124711c55c5b5ec”, “relationshipType”: “CONTAINS”, “relatedSpdxElement”: “SPDXRef-23989aa2a193ea3d” }, … ]}
这不仅包括包，还包括图像中的文件、元素之间的关系、许可信息等。
cyclonedx/bom
nodeJS 包cyclonedx/bom允许从 Node 项目生成 CycloneDX 格式的 SBOM。从
github.com/fastify/fastify 生成 SBOM 时的示例输出如下所示：
$ cyclonedx-bom
$ cat bom.xml
<?xml version=”1.0″ encoding=”utf-8″?><bom serialNumber=”urn:uuid:be53de33-6897-49ca-855d-926383866c21″ version=”1″> <metadata> <timestamp>2022-06-23T10:03:17.018Z</timestamp> <tools> <tool> <vendor>CycloneDX</vendor> <name>Node.js module</name> <version>3.10.1</version> </tool> </tools> <component type=”library” bom-ref=”pkg:npm/fastify@4.1.0″> <author>Matteo Collina</author> <name>fastify</name> <version>4.1.0</version> <description> <![CDATA[Fast and low overhead web framework, for Node.js]]> </description> … </component> </metadata> <components> <component type=”library” bom-ref=”pkg:npm/%40fastify/ajv-compiler@3.1.0″> <author>Manuel Spigolon</author> <group>@fastify</group> <name>ajv-compiler</name> <version>3.1.0</version> <description> <![CDATA[Build and manage the AJV instances for the fastify framework]]> </description> <licenses> <license> <id>MIT</id> </license> </licenses> <purl>pkg:npm/%40fastify/ajv-compiler@3.1.0</purl> <externalReferences> <reference type=”website”> <url>https://github.com/fastify/ajv-compiler#readme</url> </reference> <reference type=”issue-tracker”> <url>https://github.com/fastify/ajv-compiler/issues</url> </reference> <reference type=”vcs”> <url>git+https://github.com/fastify/ajv-compiler.git</url> </reference> </externalReferences> </component>… </components> <dependencies> <dependency ref=”pkg:npm/fast-deep-equal@3.1.3″/> <dependency ref=”pkg:npm/json-schema-traverse@1.0.0″/> <dependency ref=”pkg:npm/require-from-string@2.0.2″/> <dependency ref=”pkg:npm/punycode@2.1.1″/> <dependency ref=”pkg:npm/uri-js@4.4.1″> <dependency ref=”pkg:npm/punycode@2.1.1″/> </dependency> <dependency ref=”pkg:npm/ajv@8.11.0″> <dependency ref=”pkg:npm/fast-deep-equal@3.1.3″/> <dependency ref=”pkg:npm/json-schema-traverse@1.0.0″/> <dependency ref=”pkg:npm/require-from-string@2.0.2″/> <dependency ref=”pkg:npm/uri-js@4.4.1″/> </dependency>
… </dependencies>
</bom>
snyk2spdx
snyk2spdx工具利用Snyk开源API 从您的代码存储库创建 SBOM。不幸的是，在撰写本文时，此存储库已过时且未维护。
其他
还有一些在线工具，例如
https://sbom.democert.org/sbom/，允许导入不同的格式或手动将组件添加到 SBOM 定义中然后下载。
NTIA还发布了“如何生成 SBOM 指南”作为关于如何生成 SBOM 的简单说明和指南的集合。有趣的是，该指南包含了“完整性断言”的概念，用于某些组件的依赖关系缺失的情况。
供应商提供的 SBOM 还是猜测的 SBOM？
理想情况下，产品的供应商应该告诉我们每个组件，并以数字签名文档的形式提供，以防止篡改或修改。但我们离那里还很远，而且生产和提供 SBOM 的供应商并不多。这是一个复杂的过程，涉及多个工具和部件，并且 SBOM 分发有多种标准。
在 Dreamland 中，每个供应商都将提供 100% 准确和全面的材料清单，采用通用标准，并进行数字签名。但在现实世界中，我们通常需要能够生成“猜测”的物料清单的扫描工具。这更难，因为许多组件是不透明的，并且很难发现构建期间使用的依赖项或库。
尽管如此，扫描仍然是必要的，因为来自供应商的 SBOM 可能是错误的。供应商的构建过程可能会受到影响，因此供应商 SBOM 可能会故意省略某些组件，这使我们想到以下问题……
SBOM 会出错或不准确吗？
是的。SBOM 的质量取决于构建 SBOM 的过程的质量和自动化程度。
生成根级别很容易，例如您直接构建的软件的版本和详细信息，以及第一级依赖项（包和第三方库）。当您在树中更深入地导航时，传递依赖关系变得更加困难，因为许多组件可能不提供自己的 SBOM，并且检测依赖关系可能很复杂或根本不可能，例如在带有剥离信息的静态链接二进制文件中。
即使在构建阶段拥有完美的工具链和完美的 SBOM 信息，攻击者也可以篡改 SBOM 的内容（即修改伴随文件或静止的工件）以隐藏它包含易受攻击或恶意组件的事实。然后，消费者将检索 SBOM 的修改版本并错过这些危险组件。
一种常见的推荐做法是向 SBOM 工件添加数字签名，以确保消费者可以验证其真实性和完整性。
更糟糕的是，攻击者可能会破坏构建管道，从而能够修改创建 SBOM 的过程，这将导致经过数字签名但更改的组件列表。
那是在建筑方面。从“扫描”工具的角度来看，软件组件通常是一个黑匣子，或者可以从分析中获得的信息量可能非常有限，因为其中大部分（如 pom.xml 或 go.mod 文件）是在构建期间可用，但在最终交付中删除。
为了进行比较，分析或扫描仪将产生定量数据与提供的 SBOM 可以包含定性数据，并且可能会丢失或对分析不可见。
为了最大限度地降低质量低劣的 SBOM 或攻击的风险，即使存在供应商提供的 SBOM，也建议使用扫描解决方案。
SBOM 与漏洞有何关联？
漏洞是攻击者可以利用来绕过安全边界、访问系统等的弱点或缺陷。它们是攻击或破坏软件供应链的典型方式。
要查找软件（或正在运行的主机、容器映像等）中的漏洞，您需要将“已知”漏洞与软件中的组件集相匹配的东西。这称为漏洞扫描。这就是 SBOM 发挥作用的地方，因为它包含构成您的软件的软件包和版本的完整列表。
那么，另一个大问题出现了：“已知”漏洞从何而来？注意漏洞需要提前知道；您无法检测到未知缺陷！
研究人员和黑客发现了它们，它们最终进入了可供人类或计算机使用的漏洞数据库中。漏洞的主要来源有两个：
供应商可以为其产品中的漏洞提供源，例如主要的 Linux 发行版，或 Go、NPM 等软件包存储库。供应商对漏洞如何影响产品有很好的了解。然而，他们也可能在严重性方面存在偏见。
NIST、Mitre、开源漏洞数据库等独立提供商以及 Snyk 和 VulnDB 等商业产品收集、分析和提供漏洞信息。缺点是评分是客观的，没有具体说明漏洞如何应用于不同产品的上下文。在某些情况下，漏洞甚至可能不会影响供应商特定的产品版本，因为它是分叉的，或者补丁是反向移植的。
使用漏洞源可能具有挑战性，因为漏洞信息交换存在不同的格式和标准，例如：
VEX 很有趣，因为它允许供应商提供一种“负面”安全建议，例如某个漏洞不适用于组件，因为包中的子模块甚至没有在产品中使用。
另一个可以帮助确定漏洞优先级的来源是CISA 的 KEV（已知被利用漏洞目录），这是一个更新的漏洞列表，带有分配的 CVE ID、在野外被积极利用的可靠证据以及明确的补救措施（例如供应商更新） .
下图描述了完整的漏洞管理流程：
一个典型的流程包括一个扫描工具，该工具能够通过分析容器映像、主机或工作负载，或直接通过使用预先计算的 SBOM（或两者兼而有之！）来创建 SBOM。然后，扫描工具会匹配来自不同来源的已知漏洞（通常是供应商为相应的 Linux 发行版提供来源，以及 NVD 等通用来源），以报告影响软件的漏洞列表。
您可以看到使用 spdx-to-osv 工具将 Kubernetes SBOM（每个版本都公开可用）与来自 OSV 的已知漏洞进行匹配的示例。
检测到的漏洞列表可以使用附加信息进行管理和优先级排序，例如来自供应商的 VEX（不可利用的漏洞）、KEV 列表（已知已利用的漏洞）或来自 Sysdig 的风险聚焦信息，这些信息可以检测在执行期间有效加载的包的工作量。这会过滤掉容器镜像中的包，但从未执行过，因此它们是不可利用的。
有什么陷阱？
尽管有很多关于供应链安全的文献以及不断增长的工具和产品集，但其中许多工具通过分析组件和猜测依赖关系来生成 SBOM。
在大多数情况下，在上游每个组件上生成 SBOM 的最佳方法仍然需要量身定制的解决方案。这会导致 SBOM 不完整或不准确。更不用说不同的现有格式（CycloneDX、SPDX、SWID）和缺乏标准化的分发机制，使得 SBOM 的消费变得相当困难。
另一个需要考虑的问题是 SBOM 中的限制会传播到漏洞扫描程序。
例如，SBOM 中缺少的软件包可能会导致误报（未报告现有漏洞），并且在自定义软件包版本上应用补丁可能会导致误报。通常，任何未在漏洞数据库中反映版本的包自定义都可能导致 FP/FN 问题。并且没有单一的漏洞信息提供商，也没有单一的交换标准。理想情况下，每个供应商都将提供自己的安全建议来源，并提供 VEX（可利用性）以完美识别现有弱点。
结论
SBOM 是保护软件供应链的关键部分，也是漏洞匹配和管理的基础。随着软件消费者和政府为其提供商提高安全要求和软件质量的集体标准，这一点变得越来越重要。
在当时或写作时，仍有不同的竞争标准、过多的工具和很多不确定性，大多数演员仍在努力实现目标。但普遍的共识是，我们需要保护供应链，统一标准，并使 SBOM 成为构建过程的重要组成部分。
开始保护供应链的一个有趣举措是“Salsa”框架，它在软件供应链中引入了不同级别的成熟度，因此您可以从无到有，逐步实施不同的机制，以尽可能具有弹性，在链中的任何环节。
来源：科技狠活与软件技术
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！