📚 课程目录第2章 SBOM基础

SBOM 基础：标准格式、生成工具与字段解析

软件物料清单（SBOM）是容器网络运维准入策略的“物料凭证”。本节将深入解析 SBOM 的两大国际标准格式（SPDX 与 CycloneDX）、主流生成工具（Trivy 与 Syft）以及核心字段结构，为后续声明式策略评审与证据链构建奠定基础。

2.1 SBOM 标准格式：SPDX vs CycloneDX

目前业界公认的两大 SBOM 标准格式为 SPDX（Software Package Data Exchange）与 CycloneDX。两者在设计理念、字段覆盖与生态支持上各有侧重，下表从关键维度进行对比：

对比维度	SPDX 2.3	CycloneDX 1.5
维护组织	Linux Foundation (SPDX 工作组)	OWASP 基金会
核心定位	许可证合规 + 版权溯源	安全漏洞 + 组件依赖关系
文件格式	Tag:Value, RDF/XML, JSON, YAML, XLSX	JSON, XML, Protobuf
组件标识	SPDXID + PackageVerificationCode	bom-ref + 全局唯一标识 (UUID/URN)
依赖关系	DESCRIBES / DEPENDS_ON / BUILD_TOOL_OF	dependsOn / dependencies 数组
漏洞引用	ExternalRef (SECURITY) + 可选 Advisory	vulnerabilities 内置数组 + 评分/利用
容器层支持	通过 ExternalDocumentRef 引用层	原生支持 imageContent / layers 属性
网络运维场景	需额外扩展网络策略字段	内置 service / endpoint 描述

选型建议： 在容器网络运维准入场景中，推荐以 CycloneDX 作为主格式，因其原生支持容器层、服务端点与漏洞数组，更贴合“声明式策略 + 安全准入”的自动化链路。SPDX 则更适合许可证审计与合规证据链场景。

2.2 SBOM 生成工具：Trivy 与 Syft

Trivy 与 Syft 是当前最主流的开源 SBOM 生成工具，均支持容器镜像、文件系统与代码仓库扫描。以下从生成速度、格式支持与运维集成三个维度进行对比：

特性	Trivy (v0.50+)	Syft (v1.0+)
开发语言	Go	Go
输出格式	CycloneDX, SPDX, JSON, SARIF	CycloneDX, SPDX, JSON, Table
容器镜像支持	Docker / OCI / Podman / containerd	Docker / OCI / Podman / containerd
包管理器识别	apt, yum, apk, pip, npm, go, maven, nuget 等 20+	apt, yum, apk, pip, npm, go, maven, nuget, gem 等 30+
漏洞扫描集成	内置漏洞数据库（内置）	需配合 Grype 使用
生成速度（中等镜像）	~8-15 秒	~5-10 秒
CI/CD 集成	原生 GitHub Actions / GitLab CI / Jenkins	原生 GitHub Actions / GitLab CI / Jenkins

  生产环境推荐组合： Syft 生成 CycloneDX 格式 SBOM + Trivy 进行漏洞扫描与准入策略校验。Syft 的包识别更全面，Trivy 的漏洞库更新更及时，两者互补形成“生成-校验”闭环。

2.2.1 使用 Syft 生成 CycloneDX SBOM

# 安装 Syft（macOS/Linux）
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# 生成容器镜像的 CycloneDX SBOM
syft nginx:1.25 -o cyclonedx-json > nginx-sbom.cdx.json

# 验证输出
cat nginx-sbom.cdx.json | jq '.metadata.component.name'
# 输出: "nginx:1.25"

2.2.2 使用 Trivy 生成 SPDX SBOM 并扫描漏洞

# 安装 Trivy（macOS/Linux）
brew install trivy

# 生成 SPDX 2.3 格式 SBOM
trivy image --format spdx-json --output nginx-sbom.spdx.json nginx:1.25

# 同时生成 CycloneDX 并扫描漏洞
trivy image --format cyclonedx --output nginx-sbom.cdx.json nginx:1.25
trivy image --severity CRITICAL,HIGH nginx:1.25

注意： 生成 SBOM 时务必指定明确的镜像标签（如 nginx:1.25），避免使用 latest 标签。latest 标签会随镜像更新而变化，导致 SBOM 与运行时镜像不一致，破坏准入策略的不可否认性。

2.3 SBOM 字段解析：以 CycloneDX 为例

以下以 CycloneDX 1.5 JSON 格式为例，解析 SBOM 的核心字段层级。每个字段在容器网络运维准入策略中均有明确用途。

2.3.1 关键字段详解

字段路径	类型	准入策略用途
`metadata.component.purl`	字符串	标识容器镜像的包URL，用于策略匹配镜像仓库/标签
`components[].purl`	字符串	每个组件的包URL，策略可禁止特定包（如 log4j）或版本范围
`components[].licenses`	数组	许可证合规策略，禁止 GPL 等传染性许可证进入生产环境
`dependencies[].dependsOn`	数组	依赖关系链，用于检测间接依赖中的漏洞传播路径
`vulnerabilities[].severity`	字符串	漏洞严重等级（CRITICAL/HIGH/MEDIUM/LOW），设定准入阈值
`vulnerabilities[].affects`	数组	受影响组件引用，精确定位漏洞影响范围

2.4 SBOM 字段在准入策略中的声明式映射

在容器网络运维中，SBOM 字段直接映射为声明式准入策略的匹配条件。以下是一个基于 OPA (Open Policy Agent) 的 Rego 策略示例，展示如何利用 CycloneDX 字段进行准入控制：

package container_admission

# 从 SBOM 中提取所有组件 PURL
components := [c.purl | c := input.components[_]]

# 策略 1：禁止包含已知高危组件（如 log4j-core 版本 < 2.17.0）
deny[msg] {
    some purl in components
    contains(purl, "pkg:maven/org.apache.logging.log4j/log4j-core")
    not contains(purl, "pkg:maven/org.apache.logging.log4j/log4j-core@2.17")
    msg := sprintf("高危组件禁止准入: %v", [purl])
}

# 策略 2：禁止存在 CRITICAL 漏洞
deny[msg] {
    some vuln in input.vulnerabilities
    vuln.severity == "CRITICAL"
    msg := sprintf("存在 CRITICAL 漏洞: %v", [vuln.id])
}

# 策略 3：禁止使用 GPL 许可证组件
deny[msg] {
    some comp in input.components
    some license in comp.licenses
    contains(license.license.id, "GPL")
    msg := sprintf("禁止 GPL 许可证组件: %v", [comp.name])
}

  声明式策略优势： 上述 Rego 策略可直接集成到 Kubernetes 准入控制器（如 OPA Gatekeeper / Kyverno）中，在容器部署前自动校验 SBOM 字段，实现“生成即校验、校验即准入”的自动化运维闭环。

2.5 本章小结

标准格式： SPDX 侧重许可证合规，CycloneDX 侧重安全漏洞与容器层支持，网络运维场景推荐 CycloneDX。
生成工具： Syft 包识别更全面，Trivy 漏洞库更新更及时，生产环境建议组合使用。
字段解析： purl、severity、licenses、dependsOn 是准入策略的核心匹配字段。
声明式映射： SBOM 字段可直接映射为 OPA/Kyverno 策略，实现容器部署前的自动化准入校验。