软件供应链安全基础：SLSA框架、SBOM概念与镜像签名的重要性
在云原生环境中，软件供应链安全已从“可选增强”演变为“核心基线”。攻击者不再仅针对运行时漏洞，而是将恶意代码注入到开发、构建、分发等上游环节。本章将围绕三个关键支柱——SLSA框架、SBOM概念与镜像签名——建立软件供应链安全的知识底座，为后续使用Cosign进行签名验证打下理论基础。
2.1 SLSA框架：供应链安全成熟度模型
SLSA（Supply-chain Levels for Software Artifacts）是由Google发起、业界广泛采纳的软件供应链安全成熟度框架。它将供应链安全从“无防护”到“高度自动化可审计”划分为四个等级，为组织提供清晰的演进路径。
核心观点： SLSA不是一次性认证，而是一组可逐步实施的构建与发布控制要求。等级越高，攻击者篡改或植入恶意代码的难度呈指数级上升。
下表总结了SLSA四个等级的核心要求与防护目标：
| SLSA等级 | 核心要求 | 主要防护目标 |
|---|---|---|
| L1（基础） | 构建过程可追溯，生成构建元数据 | 防止完全无记录的构建 |
| L2（托管构建） | 使用托管构建服务，签名验证构建来源 | 防止构建平台被篡改 |
| L3（硬化构建） | 构建过程隔离、无网络、防篡改审计日志 | 防止构建时依赖投毒 |
| L4（最高） | 双人审查、可复现构建、完整可审计供应链 | 防止内部人员恶意提交 |
在镜像供应链安全容量巡检中，SLSA L2及以上等级要求镜像必须经过签名验证，这正是Cosign发挥核心作用的场景。
2.2 SBOM：软件物料清单
SBOM（Software Bill of Materials）是软件制品中所有组件的嵌套清单，类似于食品包装上的配料表。在容器镜像场景中，SBOM 列出了镜像内包含的所有操作系统包、语言库、应用依赖及其版本信息。
实践要点： 生成SBOM的最佳时机是在镜像构建完成时，与镜像一同签名存储。常见的SBOM格式包括 SPDX 和 CycloneDX。Cosign 可以附加SBOM到镜像签名中，实现“签名+物料清单”的绑定交付。
SBOM在供应链安全中的三个核心用途：
- 漏洞扫描前置：通过SBOM快速匹配已知CVE，无需拉取完整镜像。
- 许可证合规：识别所有组件的开源许可证，避免法律风险。
- 溯源与应急：当发现某个基础镜像存在漏洞时，通过SBOM快速定位所有受影响的业务镜像。
2.3 镜像签名的重要性
容器镜像签名是确保镜像来源可信与内容完整性的关键机制。没有签名验证的镜像供应链，本质上依赖“信任网络”或“手动校验”，这在规模化运维中不可持续。
镜像签名解决的核心问题：
| 安全威胁 | 无签名时的风险 | 签名后的防护效果 |
|---|---|---|
| 镜像篡改 | 攻击者替换仓库中的镜像标签 | 签名校验失败，拒绝拉取 |
| 中间人攻击 | 传输过程中镜像被恶意修改 | 摘要与签名不匹配，阻断部署 |
| 伪造来源 | 攻击者上传同名恶意镜像 | 签名密钥不匹配，无法通过验证 |
| 依赖混淆 | 内部镜像被外部同名恶意镜像覆盖 | 只有持有正确私钥的镜像才能通过验证 |
2.4 三者的协同关系
SLSA、SBOM与镜像签名并非孤立概念，它们在软件供应链安全中形成互补的防御体系：
- SLSA框架提供流程与成熟度的指导，定义“应该做到什么程度”。
- SBOM提供透明度与可见性，回答“镜像里有什么”。
- 镜像签名提供信任与完整性，回答“这个镜像是否可信、是否被篡改”。
常见误区： 部分团队只做SBOM生成但不做签名验证，导致SBOM本身可能被篡改；或者只做签名但不生成SBOM，导致无法快速定位漏洞影响范围。在容量巡检实践中，签名+SBOM必须成对出现，并纳入SLSA L2及以上的自动化流水线。