SBOM 标准与格式：SPDX、CycloneDX、SWID 对比与结构解析

聊 SBOM，绕不开三个标准：SPDX、CycloneDX 和 SWID。很多刚接触的人会问：「到底选哪个？」我的答案是——看场景。没有银弹，但搞清楚它们的差异，你就能少踩坑。

我最早接触 SBOM 是在一次供应链安全审计中。客户要求提供完整的软件物料清单，结果团队拿出的是一份 Excel 表格。嗯，那场面……后来我们统一用 CycloneDX 格式，才真正把自动化做起来。

三大标准概览

先看一张对比表，快速建立认知：

特性	SPDX	CycloneDX	SWID
发起方	Linux 基金会	OWASP	ISO/IEC
核心用途	许可证合规 + 组件溯源	安全漏洞管理 + 依赖分析	软件资产识别与授权
格式支持	Tag-value、JSON、XML、RDF	JSON、XML	XML
证书字段	无原生支持	有原生证书对象	有签名机制
生态成熟度	高（开源工具多）	高（DevSecOps 集成好）	中（Windows 生态常见）

SPDX：许可证合规的老大哥

SPDX（Software Package Data Exchange）是历史最久的 SBOM 标准。它的强项在于许可证管理——能精确描述每个组件的开源许可证类型、版本、以及版权信息。

来看一个 SPDX JSON 片段：

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-app-sbom",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-1",
      "name": "openssl",
      "versionInfo": "1.1.1k",
      "licenseConcluded": "OpenSSL",
      "checksums": [
        {
          "algorithm": "SHA256",
          "value": "a0b1c2d3e4f5..."
        }
      ]
    }
  ]
}

注意看，SPDX 的包描述里没有证书字段。如果你想记录证书信息，得用 ExternalRef 扩展。我在项目中试过，能实现，但不够优雅。

CycloneDX：DevSecOps 的宠儿

CycloneDX 是 OWASP 推出的标准，天生为安全而生。它原生支持漏洞关联、依赖图、以及——证书对象。这对我们做证书生命周期管理来说，简直是天赐之物。

看一个 CycloneDX JSON 示例：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "1.1.1k",
      "cpe": "cpe:2.3:a:openssl:openssl:1.1.1k:*:*:*:*:*:*:*",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "a0b1c2d3e4f5..."
        }
      ]
    }
  ],
  "certificates": [
    {
      "subject": {
        "commonName": "example.com",
        "organization": "Example Inc."
      },
      "issuer": {
        "commonName": "Example CA",
        "organization": "Example CA Inc."
      },
      "serialNumber": "1234567890",
      "validFrom": "2024-01-01T00:00:00Z",
      "validTo": "2025-01-01T00:00:00Z",
      "fingerprint": {
        "algorithm": "SHA-256",
        "value": "abcdef1234567890..."
      }
    }
  ]
}

看到了吗？certificates 数组直接挂在根对象下。每个证书对象包含主体、颁发者、有效期、指纹——这些信息足够我们做证书的自动续期和过期预警。

SWID：ISO 标准的硬核玩家

SWID（Software Identification Tag）是 ISO/IEC 19770-2 标准。它用 XML 描述软件资产，Windows 系统原生支持。如果你管理的是 Windows 服务器群，SWID 是绕不开的。

SWID 的 XML 结构长这样：

<SoftwareIdentity
  xmlns="urn:iso:std:iso:19770:-2:2015"
  name="OpenSSL"
  version="1.1.1k"
  tagId="openssl-1.1.1k">
  <Entity name="OpenSSL Foundation" role="tagCreator"/>
  <Evidence>
    <Directory path="C:\Program Files\OpenSSL"/>
  </Evidence>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha256"/>
      <Reference URI="#openssl-1.1.1k">
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256"/>
        <DigestValue>a0b1c2d3e4f5...</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>...</SignatureValue>
  </Signature>
</SoftwareIdentity>

SWID 的签名机制是亮点。它用 XML 数字签名保证标签的完整性和真实性。但说实话，它的证书字段支持比较弱，需要自己扩展。

JSON vs XML：选哪个？

三种标准都支持 JSON 或 XML。我个人更倾向 JSON，原因有三：

• 可读性：JSON 结构更紧凑，人眼扫描快。XML 的标签冗余太多。
• 工具链：现代编程语言对 JSON 的原生支持更好。Python 的 json 模块比 xml.etree 好用得多。
• 体积：同样内容，JSON 比 XML 小 30%-50%。在 CI/CD 流水线中，传输和存储成本更低。

但 XML 也有优势：Schema 验证更成熟，数字签名支持更好。如果你对数据完整性要求极高，XML 是稳妥的选择。

知识体系总览

下面这张图总结了三大标准的核心差异和适用场景：

如何选择？

没有标准答案，但有决策路径：

• 做许可证合规：选 SPDX。它的许可证字段最丰富，工具链最成熟。
• 做证书生命周期管理：选 CycloneDX。原生证书对象，省心省力。
• 做 Windows 资产盘点：选 SWID。系统原生支持，部署成本低。
• 混合场景：同时生成多种格式。我见过一些团队同时输出 SPDX 和 CycloneDX，各取所需。