2. 供应链安全基础：软件供应链攻击案例、SBOM标准与信任模型
软件供应链安全是信任边界通信机制的基石。现代软件开发高度依赖第三方组件、开源库、容器镜像和CI/CD流水线，任何一个环节被攻破，都会导致下游所有制品被污染。本章通过真实攻击案例、SBOM标准化实践和供应链信任模型，建立对供应链攻击面与防御手段的系统认知。
2.1 软件供应链攻击典型案例
供应链攻击的核心特征是“一次投毒，多点受害”。攻击者不直接攻击目标系统，而是污染目标所依赖的上游组件或构建工具。以下三个案例分别代表了依赖混淆、维护者劫持和构建环境投毒三类典型攻击模式。
| 攻击案例 | 攻击类型 | 影响范围 | 关键教训 |
|---|---|---|---|
| SolarWinds Orion (2020) | 构建环境投毒 | 18,000+ 客户，包括美国政府机构 | 签名证书被滥用，构建流水线缺乏完整性校验 |
| Codecov Bash Uploader (2021) | 凭证泄露 + 镜像篡改 | 29,000+ 客户，Docker镜像被替换 | CI/CD凭证轮换不足，镜像摘要未锁定 |
| UA-Parser-JS (2021) | 维护者劫持 + 恶意版本 | npm 周下载量 800万+ | 开源维护者权限过大，缺乏多因素认证 |
关键洞察： 三个案例的共同特征是攻击者都绕过了传统的“代码审查”防线，在构建、分发或依赖解析阶段植入恶意代码。信任边界通信机制必须覆盖从源码到运行时的全链路。
2.2 SBOM（软件物料清单）标准
SBOM 是供应链可见性的核心载体。它是一份机器可读的清单，列出软件制品中包含的所有组件、版本、依赖关系和许可证信息。没有 SBOM，安全团队就无法知道“我的软件里有什么”，也就无法在漏洞披露时快速定位受影响组件。
2.2.1 主流 SBOM 格式对比
| 格式 | 维护组织 | 序列化方式 | 核心能力 | 适用场景 |
|---|---|---|---|---|
| SPDX 2.3 | Linux Foundation | JSON / RDF / Tag:Value | 许可证合规 + 安全参考 + 完整性哈希 | 开源合规、法律审计 |
| CycloneDX 1.5 | OWASP | JSON / XML | 漏洞关联 + 服务依赖 + 组件元数据 | 安全运营、漏洞管理 |
| SWID | ISO/IEC 19770-2 | XML | 软件标识 + 资产清单 | 企业资产管理、软件许可 |
推荐实践： 在镜像供应链场景中，优先使用 CycloneDX 格式，因为它原生支持容器镜像层级的组件枚举和依赖图，且与 OWASP Dependency-Track 等工具集成度最高。
2.2.2 SBOM 生成与验证流程
SBOM 必须在构建阶段自动生成，并随制品一起签名和分发。以下是一个典型的 SBOM 生命周期：
- 构建时扫描： 使用工具（如 Syft、Trivy）扫描容器镜像或源码目录，提取所有依赖包、操作系统库和语言运行时。
- 格式转换与丰富： 将原始扫描结果转换为 CycloneDX 或 SPDX 格式，并补充漏洞参考（CVE ID）、许可证信息和组件哈希。
- 签名与附加： 使用私钥对 SBOM 文件进行数字签名（如 Cosign），并将签名后的 SBOM 作为 OCI artifact 附加到镜像仓库中。
- 消费与验证： 部署时，策略引擎拉取 SBOM，验证签名，并与漏洞数据库交叉比对，决定是否允许部署。
# 使用 Syft 生成 CycloneDX SBOM 示例
syft packages alpine:latest -o cyclonedx-json > sbom.cdx.json
# 使用 Cosign 对 SBOM 签名
cosign sign-blob --key cosign.key sbom.cdx.json > sbom.cdx.json.sig
# 将 SBOM 附加到镜像
oras attach registry.example.com/app:v1 \
--artifact-type application/vnd.cyclonedx+json \
sbom.cdx.json2.3 供应链信任模型
信任模型定义了“我凭什么相信这个软件制品是安全的”。在传统模型中，信任基于“谁签发的”（如知名厂商签名），但在供应链攻击中，签名证书本身可能被窃取或滥用。现代信任模型转向“可验证的构建过程”和“可审计的依赖链”。
2.3.1 三种信任模型对比
| 信任模型 | 信任锚点 | 验证方式 | 抗攻击能力 | 典型工具 |
|---|---|---|---|---|
| 基于签名的信任 | 签名者公钥 | 验证数字签名 | 弱（证书泄露即失效） | GPG、Cosign |
| 基于透明度的信任 | 公共日志（Rekor） | 验证签名 + 日志存在性证明 | 中（可审计历史，但日志可能被污染） | Sigstore、Rekor |
| 基于可重现构建的信任 | 构建环境 + 源码哈希 | 独立重现构建并比对哈希 | 强（攻击者需同时控制所有构建环境） | Reproducible Builds、diffoscope |
注意： 基于签名的信任模型在供应链场景中已不足以防御高级攻击。SolarWinds 攻击者拥有合法签名证书，签名验证无法阻止恶意更新。建议至少采用“签名 + 透明度日志”的组合模型。
2.3.2 信任链传递与信任边界
在镜像供应链中，信任从根（基础镜像、构建工具）逐层传递到最终部署的容器。每一层都需要建立独立的信任证据，形成“信任链”。信任边界则定义了哪些组件必须经过严格验证，哪些可以基于上下文信任。
2.4 供应链信任的实践框架：SLSA
SLSA（Supply-chain Levels for Software Artifacts）是 Google 提出的供应链安全成熟度模型，定义了从 L1 到 L4 四个等级。每个等级要求更强的构建完整性、来源可验证性和依赖隔离。信任边界通信机制至少应达到 SLSA L3，即要求构建过程可重现、构建平台经过认证、且所有依赖都有 SBOM 和签名。
| SLSA 等级 | 核心要求 | 信任边界通信对应措施 |
|---|---|---|
| L1 | 构建过程可追溯（有日志） | 记录所有构建步骤和输入来源 |
| L2 | 构建过程防篡改（签名 + 隔离） | 使用隔离构建环境，对产物签名 |
| L3 | 构建过程可重现 + 依赖完整性 | 锁定基础镜像摘要，SBOM 签名验证 |
| L4 | 构建过程完全可审计 + 双人审批 | 所有信任边界变更需多方签名 |
课程关联： 本课程后续章节将基于 SLSA L3 设计信任边界通信机制。所有进入信任边界的镜像必须携带经过签名的 SBOM，且构建过程必须来自受信任的构建平台（如 Tekton Chains + Sigstore）。
2.5 本章小结
- 供应链攻击 利用依赖关系和构建流程的信任盲区，实现“一次投毒，多点受害”。
- SBOM 是供应链可见性的基础，CycloneDX 格式在容器场景中具有最佳适配性。
- 信任模型 应从基于签名转向基于透明度日志和可重现构建，以抵御证书泄露风险。
- SLSA 框架 提供了供应链安全成熟度的阶梯式路径，信任边界通信机制应至少对齐 SLSA L3。