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

2、SBOM标准与格式：SPDX、CycloneDX、SWID三大标准对比与选型

聊到SBOM，第一个绕不开的问题就是：用哪个格式？

我刚开始接触SBOM时，也以为随便选一个就行。后来在给一家汽车零部件厂商做合规时，客户要求同时提交SPDX和CycloneDX两份清单，理由是他们下游OEM各自认不同的标准。那会儿我才意识到——选错格式，等于白干。

目前业界主流的SBOM标准有三个：SPDX、CycloneDX、SWID。它们各有来头，也各有短板。下面我带你逐个拆解。

2.1 SPDX：最老牌，最全面

SPDX（Software Package Data Exchange）由Linux基金会主导，最早是2011年发布的。它的核心目标就一个：把软件包的许可证信息说清楚。

核心特点：

支持RDF/XML、Tag:Value、JSON、YAML、XLSX等多种序列化格式
每个组件可以关联多个许可证，支持“许可证异常”声明
内置“文件级别”颗粒度，能精确到单个文件的版权信息
最新版本是SPDX 2.3（2022年发布），3.0正在草案阶段

举个例子，一个典型的SPDX片段长这样：

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
PackageName: log4j-core
PackageVersion: 2.17.1
PackageDownloadLocation: https://repo1.maven.org/...
PackageChecksum: SHA1: d7c9e9a8...
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: Apache-2.0
PackageCopyrightText: <text>Copyright 2021 The Apache Software Foundation</text>

嗯，这里要注意：SPDX的字段名比较长，手写容易出错。我在项目中都是直接用工具生成，很少手动编辑。

2.2 CycloneDX：轻量，现代，安全友好

CycloneDX由OWASP社区维护，2017年才推出。它的设计哲学和SPDX不太一样——更关注安全漏洞和依赖关系。

说白了，如果你主要关心“这个组件有没有已知漏洞？它的依赖树长什么样？”，那CycloneDX更适合你。它原生支持漏洞关联（通过BOM-ref和外部引用），还能描述组件之间的“组合关系”（比如A是B的补丁，C是D的测试依赖）。

我的经验：有一次做容器镜像的SBOM，CycloneDX的“组件类型”字段帮了大忙。它能把操作系统包、应用库、中间件区分开，审计时一目了然。

CycloneDX的JSON格式很简洁：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "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": "owasp:severity",
          "value": "critical"
        }
      ]
    }
  ]
}

看到那个purl字段了吗？这是CycloneDX的亮点——它用Package URL来唯一标识组件，比SPDX的DownloadLocation更精确，也更容易被自动化工具解析。

2.3 SWID：政府与企业的“身份证”

SWID（Software Identification Tagging）是ISO/IEC 19770-2标准，最早由美国国防部和大型企业推动。它的思路和前面两个完全不同——SWID更像一个“软件身份证”，用来标记“这个软件是谁的、什么版本、安装在哪”。

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

Regid：注册机构标识（比如regid.2021-08.com.example）
Name：软件名称
Version：版本号
TagId：标签唯一标识
EntitlementRequiredIndicator：是否需要授权

我曾经在给一家银行做资产盘点时遇到过SWID。他们的IT资产管理（ITAM）系统只认SWID，因为SWID能直接关联到采购订单和授权许可。但说实话，SWID在开源社区里用得很少——大部分开源项目不会主动生成SWID标签。

避坑指南：SWID的XML格式非常冗长，一个简单的组件可能写上百行。而且SWID对“依赖关系”的支持很弱，不适合做深度供应链分析。如果你主要做开源合规，SWID不是首选。

2.4 三大标准对比：一张表说清楚

维度	SPDX	CycloneDX	SWID
维护组织	Linux基金会	OWASP	ISO/IEC
首次发布	2011年	2017年	2009年（ISO标准）
核心关注点	许可证合规	安全漏洞与依赖	软件身份与授权
颗粒度	文件级别	组件级别	软件包级别
依赖关系描述	弱（需手动关联）	强（原生支持）	弱（基本不支持）
漏洞关联	需外部映射	原生支持	需外部映射
序列化格式	RDF/XML, Tag:Value, JSON, YAML	JSON, XML, Protobuf	XML
开源生态支持	广泛	广泛且增长快	有限
典型使用场景	许可证审计、法律合规	漏洞管理、CI/CD集成	IT资产管理、软件授权

2.5 如何选型？我的建议

你可能会问：三个标准各有千秋，我到底该用哪个？

我的建议是分场景看：

如果你主要做许可证合规（比如开源项目发布、商业软件采购审计），选SPDX。它的许可证字段最完整，律师和法务团队最认可。
如果你主要做安全漏洞管理（比如DevSecOps流水线、容器镜像扫描），选CycloneDX。它的依赖树和漏洞关联能力是三个里最强的。
如果你在政府、金融或大型企业做IT资产盘点，选SWID。但要做好心理准备——开源组件基本没有SWID标签，你得自己生成。
如果客户或监管方有明确要求，那就别纠结了，客户要什么就给什么。我见过最极端的情况是客户要求同时提供SPDX和CycloneDX，那就两个都生成。

一个实用技巧：现在很多工具（比如Syft、Trivy、ORT）都支持同时输出SPDX和CycloneDX。你可以在CI/CD里配置两个生成步骤，一份给法务，一份给安全团队。这样两边都满意，你也不用反复改。

2.6 知识体系总览

下面这张图帮你理清三个标准的核心定位和关系：

你想想看，这三个标准其实不是竞争关系，而是互补关系。SPDX管“法律合规”，CycloneDX管“安全风险”，SWID管“资产身份”。一个成熟的SBOM体系，往往需要同时用到它们。