3. SBOM标准与格式：SPDX、CycloneDX、SWID标签标准介绍与对比

说到SBOM，很多人第一反应是「不就是个物料清单吗？」。嗯，这话对了一半。SBOM确实是个清单，但问题在于——你用谁的格式写？字段怎么定义？工具能不能读？

我入行那会儿，各家有各家的玩法。A供应商给个Excel，B供应商甩个XML，C厂商直接发PDF。你想想看，这怎么自动化？怎么对接？后来行业里慢慢形成了三个主流标准：SPDX、CycloneDX和SWID。今天咱们就把这三个标准掰开揉碎了讲清楚。

3.1 三个标准的前世今生

先简单过一下背景，不然你光看技术细节容易晕。

• SPDX（Software Package Data Exchange）：由Linux基金会主导，最早2011年就发布了1.0。初衷是解决开源许可证合规问题。说白了，律师们需要知道你的软件里用了哪些开源组件、什么许可证、有没有冲突。SPDX在这方面做得最细。
• CycloneDX：由OWASP（开源Web应用安全项目）发起，2017年才出第一个版本。它更关注安全漏洞和依赖关系。如果你做DevSecOps，这个标准你会经常碰到。
• SWID（Software Identification Tag）：这个来头不一样，它是ISO/IEC 19770-2标准，由国际标准化组织发布。主要用在软件资产管理、授权管理上。政府和大企业用得比较多。

我个人习惯是：做合规审计用SPDX，做安全扫描用CycloneDX，做资产盘点用SWID。当然，实际项目中往往是混着用的。

3.2 SPDX：许可证合规的「老大哥」

SPDX目前最新版本是2.3（2022年发布），3.0也在路上了。它的核心思路是把一个软件包拆成三部分：元数据、包信息、许可证信息。

来看一个简化的SPDX例子：

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: my-device-firmware-v1.2

## Package Information
PackageName: libssl
SPDXID: SPDXRef-Package-libssl
PackageVersion: 1.1.1k
PackageLicenseDeclared: OpenSSL
PackageLicenseConcluded: OpenSSL
PackageCopyrightText: Copyright (c) 1998-2021 The OpenSSL Project

注意看，这里有两个许可证字段：PackageLicenseDeclared（声明许可证）和PackageLicenseConcluded（结论许可证）。为什么要有两个？

我在项目中遇到过这种情况：供应商声明用的是MIT许可证，但实际代码里混了一段GPL的代码。这时候Declared写MIT，Concluded就得写GPL，因为经过分析发现实际许可证是GPL。这个设计很巧妙，它允许你保留原始声明，同时记录真实结论。

3.3 CycloneDX：安全运维的「瑞士军刀」

CycloneDX的设计哲学和SPDX不太一样。它更轻量，更面向现代应用架构。支持组件、服务、漏洞、签名等多种信息。

看一个JSON格式的例子：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.14.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    }
  ]
}

这里有个关键字段——purl（Package URL）。它是个统一包标识符，能精确定位到某个仓库里的某个版本。比如pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1，一看就知道是Maven中央仓库的log4j。

为什么这个重要？你想想看，Log4j漏洞爆发那会儿，安全团队要快速定位所有受影响的设备。如果SBOM里只有「log4j 2.14.1」这种模糊描述，根本没法自动化匹配。有了purl，工具可以直接去NVD（国家漏洞数据库）查对应版本有没有CVE。

3.4 SWID：软件资产的「身份证」

SWID标签的思路和前面两个完全不同。它把每个软件实例看作一个「实体」，给每个实体分配一个唯一ID。这个ID可以关联到安装、激活、授权等操作。

SWID标签通常以XML格式存在，结构如下：

<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="multipartnumeric">
  <Entity name="Example Corp" role="tagCreator"/>
  <Evidence>
    <Directory path="C:\Program Files\MyApp"/>
  </Evidence>
</SoftwareIdentity>

注意tagId字段，它是全局唯一的。我建议用「反向域名+版本号」的命名方式，比如com.example.myapp-1.0.0，这样基本不会冲突。

SWID在设备管理场景下特别有用。比如你要统计全厂有多少台设备装了某个版本的固件，SWID标签可以直接被资产管理系统读取，不需要人工录入。

3.5 三个标准的对比

下面这张表我建议你收藏，选型的时候直接翻出来看：

对比维度	SPDX	CycloneDX	SWID
主导组织	Linux基金会	OWASP	ISO/IEC
最新版本	2.3（3.0开发中）	1.5	ISO 19770-2:2015
核心用途	许可证合规	安全漏洞管理	软件资产识别
支持格式	Tag/Value, JSON, RDF/XML, XLSX	JSON, XML	XML
包标识方式	SPDXID + PackageName	purl + 组件名	tagId + 名称
漏洞关联	外部引用（ExternalRef）	内置漏洞对象（Vulnerability）	不直接支持
许可证粒度	细（Declared + Concluded）	中（单层license数组）	弱（仅简单声明）
工具生态	FOSSology, SPDX Tools	OWASP Dependency-Track, CycloneDX Tools	SWID Tools, 商业资产管理软件

3.6 怎么选？我的实战建议

说了这么多，你可能想问：那我到底用哪个？

我的经验是，别纠结「只用一种」。实际项目中，我见过三种混用的场景：

• 场景一：供应商交付SBOM —— 要求同时提供SPDX和CycloneDX。SPDX给法务看，CycloneDX给安全团队用。
• 场景二：内部设备资产盘点 —— 用SWID标签，直接集成到IT资产管理（ITAM）系统里。
• 场景三：DevSecOps流水线 —— 构建时生成CycloneDX，推送到漏洞管理平台做持续监控。

3.7 一张图看懂三个标准的关系

下面这张SVG图，我把三个标准的定位、核心能力和典型场景画在了一起。你可以把它当作选型参考图：

3.8 工具链怎么搭

最后聊点实际的。你光有标准不行，得有工具生成、验证、消费这些SBOM。我列几个常用的：

• SPDX生成：FOSSology（开源扫描工具）、SPDX Tools（官方Java库）、tern（容器分析工具）
• CycloneDX生成：CycloneDX Maven/Gradle插件、Syft（容器和文件系统扫描）、Trivy（漏洞扫描+SBOM生成）
• SWID生成：SWID Tools（官方工具集）、商业软件如Flexera、ServiceNow
• 验证工具：SPDX Online Validator、CycloneDX CLI、SWID Schema验证