本文主要是介绍Gartner发布SBOM软件物料清单创新洞察：SBOM的三种标准、五个应用场景及实施成功的四个关键，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
软件物料清单可提高软件供应链中专有代码和开源代码的可见性、透明度、安全性和完整性。为了实现这些优势，软件工程领导者应在整个软件交付生命周期中集成 SBOM。
主要发现
-
软件供应链中专有和开源依赖关系缺乏可见性和透明度，加剧了安全和合规风险。
-
软件工程团队通常缺乏工具、实践和标准来系统地发现和共享整个组织内易受攻击的软件包的详细信息。
-
保持软件物料清单 (SBOM) 数据与相应的软件工件同步是一个关键挑战。
-
软件供应链安全攻击暴露了与商业采购工具和平台相关的风险。
建议
负责构建软件应用程序的软件工程领导者应该：
-
使用 SBOM 跟踪软件开发生命周期 (SDLC) 中开源组件之间的依赖关系，增强完整软件供应链的可见性。
-
通过使用 SBOM 标准交换有关组件及其关系的信息，发现受影响的组件并共享漏洞数据。
-
通过在软件构建过程中生成 SBOM（而不是依赖预生成的 SBOM 数据），确保 SBOM 与软件工件一起重建。使用软件组成分析工具为第三方开源组件生成和验证 SBOM。
-
通过要求商业软件供应商在采购过程中提供基于标准（例如软件包数据交换[SPDX]、软件标识[SWID]、CycloneDX）的SBOM，降低软件供应链安全风险。
战略规划假设
到 2025 年，60% 构建或采购关键基础设施软件的组织将在其软件工程实践中强制使用和标准化 SBOM ，而 2022 年这一比例还不到 20% 。
到 2024 年，90% 的软件组成分析工具将能够生成和验证 SBOM，以帮助安全地使用开源软件，这一数字高于 2022 年的 30%。
介绍
开源是现代软件开发的基础。一份报告发现，所有接受审计的代码库中有 75% 是由具有已知安全漏洞的开源组件组成的。此外，91% 的代码库包含开源依赖项，在过去两年中没有功能升级、代码改进和安全问题修复。
虽然可重用组件和开源软件简化了软件开发，但这种简单性也暴露了一个关键的可见性差距：组织无法准确记录和总结他们生产、使用和操作的大量软件。如果没有这种可见性，软件供应链就很容易受到与软件组件相关的安全和许可合规风险的影响。
软件工程领导者如何降低安全和许可合规风险，以实现大规模供应链安全？他们必须将 SBOM 集成到他们的 DevSecOps 管道中，以执行三项任务：
-
自动为所有生产的软件生成 SBOM
-
自动验证所使用软件的 SBOM（开源和专有）
-
使用 SBOM 数据持续评估安全性和合规性风险（部署前后）
图 1 说明了软件工程领导者如何在 SDLC 中集成 SBOM 工作流。
图 1：将 SBOM 工作流集成为软件开发生命周期的一部分
描述
软件物料清单 (SBOM) 是一种正式结构化、机器可读的元数据，可唯一标识软件包及其用于构建的组件，这些组件可以是开源的，也可以是专有的。SBOM 旨在跟踪和共享软件组件的详细信息及其跨组织的供应链关系。这可以提高整个软件供应链的透明度、可审计性和可追溯性，从而加快解决安全性和合规性问题。
SBOM可帮助组织确定其是否容易受到先前在软件组件中发现的安全漏洞的影响。这些组件可以是内部开发的、商业采购的或开源软件库。SBOM 可生成并验证有关代码来源和组件之间关系的信息，这有助于软件工程团队在开发（例如代码注入）和部署（例如二进制篡改）期间检测恶意攻击。
SBOM 是安全和合规工具箱中必不可少的工具。它们有助于持续验证软件完整性，并提醒利益相关者注意安全漏洞和违规行为。
所有软件包都存在供应链依赖关系。图 2 突出显示了浏览器软件供应链（例如 Chromium 浏览器项目）中一小部分组件之间的复杂关系网和间接依赖关系。为了增加这种复杂性，图中的每个高级组件本身都由多个传递依赖关系组成。SBOM 揭示并强调了现代软件开发中看似无穷无尽的依赖链所带来的挑战。
图 2：真实开源项目中的软件供应链关系示例
为了处理这些关系和依赖关系，软件工程领导者应采用一种通用的 SBOM 格式行业标准。这种标准化将帮助软件工程团队轻松共享软件包组件的元数据。通用的数据交换格式还将使团队更容易自动生成和验证 SBOM，并确保整个供应链中来源数据的互操作性和共享性。
SBOM 标准有三种：SPDX、SWID 和 CycloneDX。从市场吸引力和社区支持来看，SPDX 和 CycloneDX 是被广泛支持的格式：
1. 软件包数据交换 ( SPDX) —由 Linux 基金会支持创建的 SPDX 规范现已成为 ISO 标准 (ISO/IEC 5962:2021)。丰富的开源工具和商业提供商生态系统支持 SPDX。创建和使用 SPDX 格式的 SBOM 的开发人员和打包人员可以参考GitHub 存储库中的示例。
2. 软件标识 (SWID) — SWID 项目由美国国家标准与技术研究所 (NIST) 支持，其规范由 ISO/IEC 19770-2:2015 标准定义。NIST 正在努力将 SWID 标签数据纳入国家漏洞数据库 (NVD) 提供的漏洞数据集，并已将 SWID 标签数据纳入安全内容自动化协议 (SCAP)。NIST GitHub 存储库提供了用于生成和验证 SWID 标签的示例工具。
3. CycloneDX — CycloneDX 是一种轻量级 SBOM 标准，旨在用于应用程序安全环境和供应链组件分析。CycloneDX 起源于开放 Web 应用程序安全项目 (OWASP) 社区，该社区负责管理该规范的战略方向和维护。CycloneDX GitHub 存储库包含用于以各种编程语言创建和使用 SBOM 的工具。
美国 SBOM 的最低要求
美国商务部与国家电信和信息管理局 (NTIA) 联合发布了 SBOM 所需的最低要素。最低要素支持基本 SBOM 功能，分类如下：
-
数据字段——应跟踪的每个组件的基线信息
-
自动化支持——使用标准数据格式（SPDX、SWID 和 CycloneDX）自动生成 SBOM 并实现机器可读性
-
实践和流程——频率（每次构建或发布新版本时生成 SBOM）、深度（具有传递依赖关系的顶级组件）和分布（可供需要的人使用）
好处和用途
好处
提高安全性和合规性
美国（例如食品药品监督管理局 [FDA] 和联邦能源管理委员会[FERC]）和欧洲（例如欧盟网络安全局 [ENISA]）的监管机构要求所有与政府机构和受监管组织进行交易的组织都必须提供 SBOM 作为先决条件。这些法规的目标是提高对软件组件和依赖关系的可视性，以准确确定组织面临的安全风险和漏洞。
示例： 2021 年 12 月，在广泛使用的开源 Java 日志库 Apache Log4j 中发现了一个零日远程代码执行漏洞（代号为 Log4Shell）。缓解此类风险的第一步是发现使用受影响版本的库的应用程序。SBOM 可以成为一种有用的工具，用于清点和映射应用程序到易受攻击的依赖项，从而缩短响应时间。
—来源：网络安全和基础设施安全局
SBOM 将为最终用户提供所需的透明度，以了解他们的产品是否依赖于易受攻击的软件库。（-美国网络安全和基础设施局）
提高软件的可见性和可追溯性
SBOM 可以让软件工程团队更加透明地了解软件的构建方式、软件的组件组成以及安全漏洞的识别和修复速度。当团队发现组件中的缺陷或漏洞时，他们可以使用 SBOM 快速识别受漏洞组件影响的所有软件。SBOM 还为他们提供信息，以评估漏洞组件带来的潜在影响和风险。
SBOM 提供了一种系统的、可扩展的方法来提高跨越组织边界、产品线、供应商、合作伙伴和国家的软件供应链的信任和安全性。
改进数据共享
SBOM 旨在解决共享开源和第三方软件的一个根本问题：虽然每个组织都使用相同的组件，但每个组织都会重复扫描漏洞和分析合规性违规行为。SPDX、SWID 和 CycloneDX 建立了一个通用基础设施和数据交换格式，以共享有关软件包的详细信息。这种标准化促进了组织之间的更大协作，并通过减少重复工作节省了时间。
用途
常见的 SBOM 用例包括：
-
许可证合规性
-
监控软件组件的安全漏洞
-
出口/进口控制——允许创建组件的“拒绝名单”和“允许名单”
-
在并购过程中确保整个软件组合的可见性
-
主动寻找已达到使用寿命的部件的替代品
风险
SBOM 的成功取决于四个关键因素——数据共享、工作流自动化、数据交换标准化和对新应用程序架构的适应性。缺乏标准化的数据交换格式阻碍了团队、合作伙伴、供应商和客户之间共享 SBOM。
当供应链中的每个参与者都遵守共同商定的标准时，SBOM 才能发挥最大价值。由于大量软件和工具已投入使用或刚刚出现，达成这一共识可能需要一段时间。
建议：为了更好地促进数据共享并自动化 SBOM 的验证和处理，软件工程领导者必须使用基于标准的 SBOM 格式。
SBOM 不是静态文档。每次发布新组件时都应包含新的 SBOM。如果发布和使用新组件时未对 SBOM 进行相应更改，则存在巨大风险。SBOM 生成和管理工具的可用性对于其广泛采用至关重要。组织需要将 SBOM 功能集成到软件开发、打包和发布活动中；并将 SBOM 作为资产管理系统不可或缺的一部分。
SBOM 生成工具依赖于发现可通过包管理器 (PIP/DPKG) 查询的依赖项。这有时会提供一种虚假的“完整性”感，因为开发人员可以将预编译的二进制文件 (wget) 或原始代码 (tar.gz) 拉入其代码库。此外，使用 SBOM 的团队不得将“单层深度”SBOM 与“完整”SBOM 混为一谈。
建议：为了使软件供应链完全透明，SBOM 必须在依赖关系图中尽可能深入地枚举组件。SBOM 可以提供层次结构信息，其中 SBOM 中包含的每个组件都可以拥有自己的 SBOM。
采用率
在三种 SBOM 标准中，SPDX获得了业界最大的关注。它得到了软件组合分析 (SCA) 供应商的支持，例如 Snyk ( FossID )、Sonatype、Synopsys 和 WhiteSource。SPDX 规范现已成为 ISO 标准。SPDX 2.2 版包含一个“SPDX Lite”配置文件，该配置文件定义了规范的一个子集，以使其适合特定于垂直行业的用例。SPDX Lite 由先锋、索尼、日立、瑞萨和富士通等公司开发。
SPDX 规范成为 ISO/IEC 5962:2021
“SPDX 在软件在整个供应链中的创建、分发和使用过程中建立更多的信任和透明度方面发挥着重要作用。从事实上的行业标准到正式的 ISO/IEC JTC 1 标准的转变使 SPDX 在全球范围内的采用率大幅提高。”
——Linux 基金会执行董事 Jim Zemlin
SBOM 将在涉及关键基础设施和人类生活的垂直领域得到更广泛的应用，例如能源、公用事业、医疗保健、制造业、电信和政府。最直接的影响将是公共部门。对于美国联邦部门和机构来说尤其如此，因为 NIST 指南要求软件产品和服务供应商使用标准数据格式支持 SBOM。
建议
-
通过使用、验证和共享所有软件组件和依赖项的来源数据来加快解决软件供应链中的漏洞。
-
使用基于标准的格式，例如 SPDX、SWID 和 CycloneDX，在组织内部和外部共享出处数据。
-
自动系统地生成 SBOM，以便 SBOM 随着工件的每个新版本进行更新。
-
通过维护包含经过验证的开源和第三方组件及其 SBOM 的存储库，实现软件模块和服务的安全重用。
代表性供应商
SBOM 标准由用于生成和使用 SBOM 的工具生态系统支持。表 1 列出了三种主要 SBOM 标准的工具。
表1 ：自动化 SBOM 处理的工具（基于 SBOM 格式）
| SBOM 格式 | 工具 |
| CycloneDX | CycloneDX 工具中心 |
| SPDX |
|
| SWID | NIST 软件识别 (SWID) 工具 |
来源：Gartner（2022 年 2 月）
表 2 和表 3分别包含开源和商业 SBOM 工具的代表性列表。这些 SBOM 工具支持以下一项或多项功能：
-
生成——能够在构建过程中创建 SBOM；分析源代码和二进制文件（例如，容器映像、zip 文件、动态链接库 [DLL]）以为这些工件生成 SBOM；并编辑 SBOM。
-
使用——能够以人类可读的格式查看、比较、导入和验证 SBOM。
-
转换——能够将 SBOM 内容从一种格式或文件类型合并并转换为另一种格式或文件类型。支持通过 API 和库在其他工具中使用 SBOM 操作。
表2 ：开源 SBOM 工具
| 工具 |
| Augur |
| Bom |
| Cosign |
| Dependency-Track |
| FOSSology |
| GitHub OSS 审查工具包 (ORT) |
| Orion |
| SwiftBOM |
| GitHub ScanCode 工具包 |
| SPDX SBOM 生成器 |
| Syft |
| Tern |
| Yocto （Linux 专用） |
来源：Gartner（2022 年 2 月）
表3 ：商业 SBOM 工具
| 提供者（工具） |
| Anchore（Syft） |
| Aqua Security （Argon） |
| Codenotary |
| Contrast Security |
| Cybeats （Cybeats SBOM 工作室） |
| NowSecure |
| Spectra Assure (ReversingLabs) |
| Snyk （FossID） |
| Sonatype （Nexus） |
| SOOS |
| Synopsys （Black Duck） |
| Tidelift |
| WhiteSource |
来源：Gartner（2022 年 2 月）
这篇关于Gartner发布SBOM软件物料清单创新洞察：SBOM的三种标准、五个应用场景及实施成功的四个关键的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
