SBOM 标准与格式：SPDX、CycloneDX、SWID 标准对比，以及 JSON/XML 格式解析

聊 SBOM，绕不开三个标准：SPDX、CycloneDX 和 SWID。很多刚接触供应链安全的朋友会问：「到底选哪个？」我的回答通常是——先别急着选，搞清楚它们各自擅长什么再说。

这三个标准，说白了就是三种不同的「说话方式」。它们都在描述软件成分，但侧重点完全不同。我在几个大型金融项目里都踩过坑，今天把经验摊开来聊聊。

三大标准的核心定位

标准	发起方	核心定位	典型场景
SPDX	Linux 基金会	许可证合规 + 软件包关系	开源合规审计、法律部门审查
CycloneDX	OWASP	安全漏洞 + 依赖关系	DevSecOps 流水线、漏洞管理
SWID	ISO/IEC	软件身份标识 + 安装管理	企业资产管理、软件授权

嗯，这里要注意：SPDX 和 CycloneDX 是目前最主流的两个。SWID 更多用在传统 IT 资产管理和微软生态里，开源社区用得少。

SPDX：许可证合规的老大哥

SPDX 是资历最老的。我记得 2018 年第一次接触它时，还在用 SPDX 1.2 版本。现在已经是 2.3 了，3.0 也在路上了。

SPDX 最拿手的是许可证管理。它能把每个组件的许可证、版权信息、文件级贡献者都列得清清楚楚。如果你所在的公司经常被法务追着问「这个开源库的许可证到底兼容不兼容」，那 SPDX 就是你的救星。

举个例子，一个简单的 SPDX JSON 片段长这样：

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-app-sbom",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-log4j",
      "name": "log4j-core",
      "versionInfo": "2.17.1",
      "licenseConcluded": "Apache-2.0",
      "supplier": "Organization: Apache Software Foundation"
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relatedSpdxElement": "SPDXRef-Package-log4j",
      "relationshipType": "DESCRIBES"
    }
  ]
}

你看，SPDX 的字段命名偏长，但语义非常清晰。不过说实话，SPDX 的 JSON 结构有点「重」。我在一个项目里生成过包含 5000 个包的 SPDX 文件，光解析就花了 3 秒多。

CycloneDX：安全优先的轻量选手

CycloneDX 是后起之秀，但发展极快。OWASP 出品，天生就带着安全基因。我个人习惯在 CI/CD 流水线里用 CycloneDX，因为它对漏洞信息的支持更直接。

CycloneDX 的 JSON 结构比 SPDX 简洁很多。它内置了 vulnerabilities 字段，可以直接把 CVE 信息嵌进去。这一点 SPDX 做不到，SPDX 需要额外关联 BOM 才能表达漏洞。

CycloneDX 的 JSON 示例：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "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"
          }
        }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
      "dependsOn": []
    }
  ]
}

注意看，CycloneDX 用了 purl（Package URL）来标识组件。这个设计非常聪明——purl 是通用的包坐标格式，不管你是 Maven、npm 还是 PyPI，都能统一表达。

SWID：企业资产管理的「身份证」

SWID 全称是 Software Identification Tag。它和前面两个不太一样，SWID 更像是一张「软件身份证」。每个安装的软件都有一个 SWID 标签，记录它的发行者、版本、安装路径等信息。

SWID 在 Windows 生态里很常见。微软的很多产品安装后都会生成 SWID 标签。如果你做的是企业级软件资产管理（SAM），SWID 是绕不开的。

但说实话，SWID 在开源社区的存在感比较弱。我很少看到开源项目主动生成 SWID 标签。它的 XML 格式也比较「重」，可读性不如 JSON。

JSON vs XML：格式之争

这三个标准都支持 JSON 和 XML 两种序列化格式。但实际使用中，JSON 已经成了绝对主流。

为什么会这样？

• JSON 更轻量：同样的数据，JSON 比 XML 小 30%-50%。
• JSON 解析更快：JavaScript、Python、Go 都有原生 JSON 支持，XML 解析需要额外库。
• JSON 可读性更好：没有闭合标签，结构一目了然。

不过 XML 也有它的优势：

• Schema 验证更严格：XSD 可以精确约束每个字段的类型和取值范围。
• 命名空间支持：适合混合多个标准的情况。
• 注释支持：XML 可以加注释，JSON 不行。

标准对比总览

维度	SPDX	CycloneDX	SWID
许可证覆盖	★★★★★	★★★★	★★
漏洞集成	★★★	★★★★★	★
依赖关系表达	★★★★	★★★★★	★★
工具生态	★★★★	★★★★★	★★★
企业资产管理	★★	★★★	★★★★★

知识体系结构图

下面这张图帮你理清三个标准的关系和适用场景：

如何选择？我的建议

你想想看，如果你的团队主要做开源合规，SPDX 是首选。它的许可证字段最丰富，法务部门看了也放心。

如果你的重点是安全漏洞管理，CycloneDX 更合适。它和 Dependency-Track、Trivy 这些工具的集成度最高。我在一个金融科技项目里，用 CycloneDX + Dependency-Track 搭建了自动化的漏洞监控体系，效果非常好。

至于 SWID，除非你在做企业级软件资产管理，否则暂时不用太关注。