📚 课程目录第2章 SBOM标准与格式

SBOM 标准与格式：SPDX、CycloneDX 与 SWID 详解

说到 SBOM 的格式，很多人第一反应就是「到底该用哪个？」。我刚开始接触这个领域时也懵过——SPDX、CycloneDX、SWID，三个名字摆在那，每个都说自己是标准。其实没那么复杂。你想想看，它们就像三种不同的语言，都能描述软件成分，但侧重点和适用场景不一样。

今天我就把这三种格式掰开揉碎了讲清楚。我会结合自己实际踩过的坑，帮你理清什么时候该用哪个。

SPDX 格式详解

SPDX（Software Package Data Exchange）是 Linux 基金会旗下的项目。它诞生得最早，2011 年就出了第一个版本。说实话，SPDX 在合规和许可证管理这块做得最扎实。

核心定位：许可证合规 + 软件溯源。如果你需要向客户证明「我的软件里每个组件的许可证都合规」，SPDX 是首选。

SPDX 文档的核心结构包含以下几个部分：

文档头信息——创建者、创建时间、文档命名空间
包信息——包名、版本、下载位置、校验和
文件信息——每个文件的路径、类型、许可证
片段信息——文件内特定代码片段的许可证声明
关系——包与包、文件与包之间的依赖关系

来看一个实际的 SPDX 2.3 示例：

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: my-app-1.0.0
DocumentNamespace: http://example.com/spdx/my-app-1.0.0

## Package Information
PackageName: log4j-core
SPDXID: SPDXRef-Package-log4j-core
PackageVersion: 2.17.1
PackageDownloadLocation: https://repo1.maven.org/...
PackageChecksum: SHA1: 123abc...
PackageLicenseConcluded: Apache-2.0

## Relationship
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-Package-log4j-core
Relationship: SPDXRef-Package-my-app DEPENDS_ON SPDXRef-Package-log4j-core

我个人习惯用 SPDX 来处理合规审计。有一次客户要求提供所有依赖的许可证清单，我直接导出了 SPDX 格式的 SBOM，对方的安全团队一看就认——省了很多沟通成本。

小技巧：SPDX 支持用标签/值格式（就像上面那样）和 JSON、YAML、RDF/XML 多种序列化方式。标签/值格式可读性最好，适合人工审查；JSON 格式适合程序处理。

CycloneDX 格式详解

CycloneDX 是 OWASP 社区推出的标准。它比 SPDX 年轻，但发展特别快。为什么？因为它更贴近现代应用安全的需求。

CycloneDX 的设计哲学是「安全优先」。它原生支持：

漏洞引用——直接关联 CVE、NVD、OSS Index 等漏洞库
组件元数据——作者、发布者、组件类型（库/框架/容器）
服务依赖——能描述微服务架构中的服务调用关系
签名与验证——支持数字签名，防止 SBOM 被篡改

来看一个 CycloneDX JSON 示例：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "metadata": {
    "timestamp": "2024-01-15T10:00:00Z",
    "tools": [{"vendor": "my-org", "name": "sbom-generator"}]
  },
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.17.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
      "licenses": [{"license": {"id": "Apache-2.0"}}],
      "properties": [
        {"name": "my-org:severity", "value": "critical"}
      ]
    }
  ],
  "vulnerabilities": [
    {
      "id": "CVE-2021-44228",
      "source": {"name": "NVD", "url": "https://nvd.nist.gov/..."},
      "ratings": [{"severity": "critical", "score": 10.0}]
    }
  ]
}

我在做 DevSecOps 流水线时，最喜欢用 CycloneDX。因为它能直接把漏洞信息嵌在 SBOM 里。有一次我扫描到一个高危漏洞，CycloneDX 的 SBOM 直接告诉我「这个组件有 CVE-2021-44228，评分 10.0」，省去了我再去查漏洞库的步骤。

注意：CycloneDX 的漏洞字段是 1.4 版本才正式引入的。如果你还在用 1.3 或更早版本，需要升级工具链。我曾经因为没注意版本，生成的 SBOM 里漏洞字段全为空，排查了半天才发现是工具版本太旧。

SWID 标签介绍

SWID（Software Identification）标签是 ISO/IEC 19770-2 标准。它跟 SPDX 和 CycloneDX 不太一样——它更关注「软件安装后的识别」。

SWID 标签通常由软件厂商自己生成，随安装包一起发布。它的核心字段包括：

标签创建者——通常是软件厂商
软件名称与版本
唯一标识符——regid 格式，比如 regid.2024-01.example.com
实体信息——发布者、授权者等
签名——确保标签未被篡改

SWID 的典型应用场景是软件资产管理。比如企业 IT 部门需要统计所有终端上安装了哪些软件，SWID 标签就能派上用场。

不过说实话，SWID 在开源社区用得不多。我接触过的项目中，只有一些大型商业软件（比如 Oracle、SAP）会提供 SWID 标签。如果你做的是开源项目或内部工具，SWID 可能不是首选。

三种格式对比与选型

好了，三种格式都讲完了。你可能会问：「那我到底该用哪个？」

别急，我整理了一张对比表，看完你就清楚了。

维度	SPDX	CycloneDX	SWID
维护组织	Linux Foundation	OWASP	ISO/IEC
核心用途	许可证合规、溯源	安全扫描、漏洞管理	软件资产管理
漏洞关联	需外部映射	原生支持	不支持
许可证描述	最详细（支持片段级）	支持（组件级）	有限
依赖关系	支持（包/文件级）	支持（组件/服务级）	有限
序列化格式	标签/值、JSON、YAML、RDF/XML	JSON、XML	XML
签名支持	可选	原生支持	原生支持
社区活跃度	高	非常高	低

选型建议其实很简单：

做合规审计、许可证管理 → 选 SPDX。它的许可证描述最细，能精确到文件甚至代码片段。
做安全扫描、漏洞管理 → 选 CycloneDX。它原生支持漏洞关联，省去很多集成工作。
做软件资产管理、终端管控 → 选 SWID。但前提是你的软件供应商支持生成 SWID 标签。

我个人在实际项目中，通常两种格式都生成。SPDX 给法务和合规团队看，CycloneDX 给安全团队用。互不冲突，反而互补。

避坑指南：我曾经在一个项目中只用了 SPDX，结果安全团队抱怨「漏洞信息还得自己去 NVD 查」。后来我加上了 CycloneDX 格式，两边都满意了。所以我的建议是——别纠结「二选一」，可以「两者都要」。

三种格式的知识体系图

下面这张图帮你快速理清三种格式的定位和关系：

嗯，看到这里你应该对三种格式有了清晰的认识。记住一点：没有「最好」的格式，只有「最合适」的格式。根据你的场景选，或者像我一样，两种都生成。