2. 软件供应链安全基础：攻击模型、SLSA 框架与 SBOM
现代软件开发高度依赖开源组件、第三方库、容器镜像和 CI/CD 流水线。攻击者不再直接攻击生产环境，而是将恶意代码注入上游依赖、构建工具或分发通道，形成“供应链投毒”。理解攻击模型、信任框架和物料清单是实施镜像安全准入的前提。
2.1 软件供应链攻击模型
根据 CNCF 及行业安全报告，供应链攻击可归纳为以下四个阶段（A 型攻击链）：
| 阶段 | 攻击目标 | 典型手法 |
|---|---|---|
| 1. 上游污染 | 源代码仓库、开源包 | 依赖混淆、恶意 PR、账户劫持后植入后门 |
| 2. 构建劫持 | CI/CD 流水线、构建环境 | 篡改 Dockerfile、注入恶意构建步骤、利用缓存投毒 |
| 3. 分发篡改 | 镜像仓库、包管理器 | 中间人攻击、仓库凭证泄露、替换合法镜像标签 |
| 4. 运行时利用 | 生产集群、终端设备 | 利用被篡改镜像中的后门执行横向移动或数据窃取 |
关键认知： 传统“边界防御”在供应链攻击面前失效。攻击者只需污染一个上游依赖，即可影响下游数千个应用。镜像签名（Cosign）和准入检查（Kyverno/OPA）正是针对阶段 2 和阶段 3 的补偿控制。
2.2 SLSA 框架：供应链安全成熟度模型
SLSA（Supply-chain Levels for Software Artifacts）由 Google 发起，现为 OpenSSF 旗下标准。它定义了从 L0（无保障）到 L4（最高保障）的四个等级，每个等级包含对来源、构建完整性和依赖关系的要求。
| 等级 | 核心要求 | 对镜像供应链的意义 |
|---|---|---|
| L0 | 无保障，仅存在软件制品 | 当前大多数项目的现状，无法抵御任何供应链攻击 |
| L1 | 构建过程可追溯（来源元数据） | 要求镜像仓库记录构建来源（如 GitHub Actions 工作流） |
| L2 | 构建过程防篡改 + 签名 | Cosign 签名 + 可验证的构建证明（Provenance） |
| L3 | 构建过程隔离 + 可复现 | 构建环境无网络、无持久化存储；镜像哈希可复现验证 |
| L4 | 构建过程完全审计 + 依赖枚举 | SBOM 自动生成 + 依赖链签名 + 策略强制准入 |
实践映射： 本课程后续实现的“Cosign 签名 + Kyverno 准入检查”可帮助团队从 L1 跃升至 L2–L3。结合 SBOM 生成与验证，可进一步向 L4 演进。
2.3 SBOM：软件物料清单的概念与重要性
SBOM（Software Bill of Materials）是软件制品中包含的所有组件的嵌套清单，类似食品包装上的配料表。对于容器镜像，SBOM 通常包含：
- 基础镜像：操作系统层（如 Ubuntu 22.04、Alpine 3.19）
- 系统包：apt/yum/apk 安装的库（如 openssl、libcurl）
- 语言依赖：pip/npm/go modules 引入的第三方包
- 应用层文件：自定义 JAR、WAR、二进制文件
- 元数据：组件版本、许可证、来源仓库、已知漏洞（CVE）关联
| SBOM 格式 | 特点 | 工具支持 |
|---|---|---|
| SPDX | Linux 基金会标准，支持许可证和安全性描述 | syft、tern、ort |
| CycloneDX | OWASP 标准，专为安全审计设计，支持组件层级 | syft、cyclonedx-gomod、jenkins 插件 |
| SWID | ISO 标准，主要用于软件资产管理 | NIST 工具、商业产品 |
常见误区： 生成 SBOM 不等于安全。SBOM 必须与签名绑定（Cosign 可对 SBOM 进行签名），并在准入策略中强制验证 SBOM 的完整性和时效性。未签名的 SBOM 可被攻击者篡改，失去审计价值。
2.4 三者的关系：攻击模型 → SLSA → SBOM
在镜像供应链安全实践中，三者形成递进关系：
- 攻击模型 揭示威胁所在（上游、构建、分发、运行时）。
- SLSA 框架 提供可量化的防御等级和具体控制措施。
- SBOM 作为可验证的物料清单，是 SLSA L3+ 的必备产出，也是准入检查的输入条件。