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

聊SBOM，绕不开格式问题。很多团队一上来就问：「到底该用哪种格式？」说实话，没有标准答案。但如果你不懂SPDX、CycloneDX和SWID的区别，选型就是瞎蒙。

我最早接触SBOM是在2019年，帮一家车企做软件供应链审计。当时他们拿到的SBOM全是Excel表格，字段乱得没法看。后来我们统一用SPDX，才把问题理清楚。嗯，今天我就把这三种主流格式掰开揉碎讲给你听。

SPDX标准详解

SPDX（Software Package Data Exchange）由Linux基金会主导，是目前最成熟的SBOM标准。它最早关注的是许可证合规，后来扩展到安全领域。

我个人习惯把SPDX看作「软件物料的法律档案」。它记录每个组件的名称、版本、许可证、版权信息，以及组件之间的依赖关系。

SPDX的核心字段

字段	说明	是否必填
SPDXID	每个组件的唯一标识	是
PackageName	组件名称	是
PackageVersion	组件版本号	是
LicenseConcluded	实际使用的许可证	是
LicenseDeclared	声明中的许可证	是
CopyrightText	版权声明	是
Relationship	组件间依赖关系	推荐

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

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: my-app-sbom

## Package: log4j-core
PackageName: log4j-core
PackageVersion: 2.17.1
PackageDownloadLocation: https://repo1.maven.org/...
PackageLicenseConcluded: Apache-2.0
PackageCopyrightText: Copyright 2023 The Apache Software Foundation

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

CycloneDX标准详解

CycloneDX由OWASP社区推动，天生就是为安全场景设计的。它比SPDX更轻量，对漏洞信息、组件元数据、服务依赖的支持更好。

我更喜欢把CycloneDX叫做「安全运维的体检报告」。它除了记录组件信息，还直接嵌入CVE编号、严重等级、修复建议。

CycloneDX的核心特点

• 原生支持漏洞管理：每个组件可以关联多个漏洞条目
• 支持服务依赖：不只是软件包，还能描述API、微服务之间的调用关系
• 支持组件类型：明确区分库、框架、容器镜像、操作系统包等
• 支持元数据扩展：可以自定义属性，灵活性高

来看一个CycloneDX的JSON示例：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "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"
          }
        }
      ],
      "vulnerabilities": [
        {
          "id": "CVE-2021-44228",
          "severity": "critical",
          "description": "Log4j JNDI injection vulnerability"
        }
      ]
    }
  ]
}

SWID标签介绍

SWID（Software Identification Tag）是ISO/IEC 19770-2标准，由美国国土安全部推动。它主要用在软件资产管理场景，比如企业IT资产盘点、软件许可审计。

说实话，SWID在国内用得不多。我只有在帮一家外企做合规审计时接触过。它的核心思路是：每个软件安装后，生成一个XML标签文件，记录软件的身份信息。

SWID标签结构

<SoftwareIdentity
  xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
  tagId="com.example.myapp-1.0.0"
  name="MyApp"
  version="1.0.0"
  versionScheme="semantic">
  <Entity name="Example Corp" role="softwareCreator"/>
  <Evidence date="2023-06-15T10:30:00Z"/>
  <Payload>
    <File name="myapp.exe" size="1048576"/>
  </Payload>
</SoftwareIdentity>

SWID的优势在于标准化程度高，但缺点也很明显：它只描述「安装了什么」，不描述「依赖了什么」。在供应链安全场景中，这个缺陷是致命的。

标准对比与选型

三种标准各有侧重。我整理了一张对比表，方便你快速决策：

维度	SPDX	CycloneDX	SWID
主导组织	Linux基金会	OWASP	ISO/IEC
核心场景	许可证合规	安全漏洞管理	软件资产管理
依赖关系描述	强（Relationship）	强（Dependency）	弱（无原生支持）
漏洞信息嵌入	需扩展	原生支持	不支持
格式支持	Tag/JSON/XML/RDF	JSON/XML	XML
工具生态	成熟	快速增长	有限
学习成本	中等	低	高

三种标准的关系图谱

为了让你更直观地理解三者的定位，我画了一张关系图：

避坑指南

最后，分享几个我在项目中踩过的坑：

• 不要迷信「一种格式走天下」。我曾经在一个项目中强制统一用SPDX，结果安全团队抱怨没法直接嵌入漏洞信息。后来我们改成SPDX+CycloneDX双格式输出，问题才解决。
• 注意版本兼容性。SPDX 2.2和2.3的字段有差异，CycloneDX 1.4和1.5的漏洞格式也不同。生成SBOM时一定要标明规范版本号。
• 工具链要提前验证。不是所有工具都支持所有格式。我见过一个团队生成CycloneDX 1.5的SBOM，结果他们的扫描器只支持1.4，解析直接报错。
• 别忽略purl和cpe。这两个字段是组件识别的关键。没有它们，SBOM就是一堆名字，没法自动化处理。