软件供应链安全基础：SLSA框架、SBOM与镜像签名验签
现代云原生应用的交付链条高度自动化，从代码提交、构建、测试、打包到部署，任何一个环节被篡改或植入恶意组件，都会导致整个生产环境面临严重风险。本章围绕软件供应链安全的三个核心支柱——SLSA框架、软件物料清单（SBOM）、镜像签名与验签——展开讲解，为后续使用 Cosign 进行镜像安全通信打下理论基础。
2.1 软件供应链安全威胁模型
在深入具体技术之前，先明确软件供应链面临的主要攻击向量：
- 上游依赖投毒：攻击者向公共仓库（如 npm、PyPI、Docker Hub）上传包含后门的恶意包。
- 构建环境篡改：CI/CD 流水线被入侵，构建过程中被注入恶意代码或替换制品。
- 镜像仓库劫持：攻击者获得仓库凭证，将合法镜像替换为恶意镜像。
- 中间人攻击：拉取镜像时，传输链路被拦截并替换内容。
- 运行时投毒：已部署的容器被植入后门，或利用漏洞从外部篡改镜像层。
关键认知： 传统安全模型只关注“边界防御”和“运行时扫描”，但无法防御“合法镜像被篡改后重新签名”或“构建时被植入后门”这类供应链攻击。SLSA、SBOM 和签名验签正是为了解决这些盲区而设计。
2.2 SLSA框架：供应链安全成熟度模型
SLSA（Supply-chain Levels for Software Artifacts） 由 Google 发起，现为 OpenSSF 下的开放标准。它定义了一套从低到高的安全等级，帮助组织评估并提升软件制品的供应链安全水平。
| SLSA 等级 | 核心要求 | 典型实践 |
|---|---|---|
| SLSA 1 | 构建过程可追溯 | 构建日志、版本控制、自动化构建 |
| SLSA 2 | 构建过程防篡改 | 隔离构建环境、签名构建产物、生成来源证明 |
| SLSA 3 | 构建过程可审计且防旁路 | 无特权构建、硬件信任根、不可变构建日志 |
| SLSA 4 | 构建过程完全可验证 | 双人审查、可重现构建、完整来源链 |
在 Kubernetes 镜像安全场景中，达到 SLSA 2 是最低可接受门槛：必须对镜像进行签名，并生成可验证的来源证明（Provenance）。SLSA 3 和 SLSA 4 则适用于金融、医疗等强监管行业。
实践建议： 在搭建镜像签名流水线时，优先确保 CI/CD 构建环境本身满足 SLSA 2 要求（如使用隔离 runner、签名构建产物），再对镜像进行 Cosign 签名。不要跳过构建环境安全直接签名，否则签名本身可能被伪造。
2.3 软件物料清单（SBOM）
SBOM（Software Bill of Materials） 是软件制品中包含的所有组件、依赖项、版本号、许可证和来源的清单。它相当于软件的“成分表”。
SBOM 的核心价值：
- 漏洞管理：当某个依赖（如 Log4j）爆出高危漏洞时，通过 SBOM 可以快速定位哪些镜像受影响。
- 许可证合规：自动检查镜像中是否包含 GPL、AGPL 等传染性许可证。
- 供应链审计：追溯每个组件的来源，验证是否来自可信仓库。
常见的 SBOM 格式包括 CycloneDX（OWASP 维护，容器生态首选）和 SPDX（Linux 基金会维护，法律合规场景常用）。
常见误区： SBOM 本身不保证安全。它只是“清单”，如果清单中的组件来自恶意源，SBOM 只会如实记录恶意组件。SBOM 必须与签名验签结合使用——先验证镜像签名可信，再解析 SBOM 进行漏洞扫描。
2.4 镜像签名与验签的基本概念
镜像签名是一种密码学保证，用于证明镜像的发布者身份以及镜像内容未被篡改。其核心流程如下：
- 签名（Sign）：发布者使用自己的私钥对镜像的摘要（Digest）进行签名，生成签名文件。
- 存储（Store）：签名文件通常存储在镜像仓库中（如 OCI 仓库的 tag 或 referrers API），或独立的公证服务（如 Rekor 透明日志）。
- 验签（Verify）：消费者（如 kubelet、准入控制器）使用发布者的公钥验证签名是否匹配镜像摘要。
核心原则： 签名的是“镜像摘要”（sha256:...），而不是“镜像标签”（:latest）。因为标签可变，摘要不可变。验签时先计算本地镜像的摘要，再验证签名是否对该摘要有效。
下表对比了常见的镜像签名工具与机制：
| 工具/机制 | 密钥管理 | 透明日志 | K8s 集成 | 适用场景 |
|---|---|---|---|---|
| Cosign | 密钥对 / KMS / 密钥链 | Rekor（默认） | 原生（k8s 验证 webhook） | 云原生首选，轻量，社区活跃 |
| Notation | 证书 + 私钥 | 可选（Rekor 或自建） | 通过 Ratify 准入控制器 | 企业 PKI 环境，与 Notary 生态兼容 |
| Docker Content Trust (DCT) | Notary 服务 | Notary 服务 | 有限（需额外配置） | 遗留 Docker 环境，已逐渐被 Cosign 取代 |
| Sigstore | 无密钥（OIDC 身份） | Rekor（强制） | 通过 Cosign 集成 | 开源项目、CI/CD 自动化签名 |
2.5 签名与验签在 Kubernetes 中的落地形态
在 K8s 环境中，镜像验签通常通过 准入控制器（Admission Controller） 实现。当用户提交 Pod 或 Deployment 时，准入控制器拦截请求，执行以下步骤：
- 解析 Pod 中引用的所有镜像。
- 从镜像仓库拉取对应的签名对象。
- 使用预先配置的公钥（或通过 Sigstore 的 Fulcio 证书链）验证签名。
- 如果验签失败，拒绝创建 Pod；如果成功，允许继续调度。
推荐工具链： Cosign + Kyverno 或 Cosign + OPA Gatekeeper。Kyverno 内置了
verifyImages 规则，可以直接调用 Cosign 进行验签，无需额外编写 Webhook 代码。
2.6 本章小结
- SLSA 框架 提供了供应链安全的分级标准，镜像签名是达到 SLSA 2 的必要条件。
- SBOM 是镜像的“成分表”，与签名结合才能实现可信的漏洞管理。
- 镜像签名 使用私钥对镜像摘要签名，验签使用公钥验证，确保镜像发布者身份和内容完整性。
- K8s 环境 通过准入控制器自动执行验签，拒绝未签名或签名无效的镜像。