3、镜像供应链安全模型：SLSA框架、软件物料清单（SBOM）、签名与验证流程

在云原生环境下，镜像供应链面临从开发、构建、分发到部署的全链路安全风险。为了系统性地解决这些风险，业界形成了三大核心支柱：SLSA框架（Supply-chain Levels for Software Artifacts）、软件物料清单（SBOM）以及签名与验证流程。本节将深入解析这三者的定义、关系及在Sigstore生态中的实践。

3.1 SLSA框架：供应链安全成熟度模型

SLSA（发音为“salsa”）是由Google发起、被OpenSSF采纳的供应链安全标准。它定义了一套从低到高的安全等级（L1-L4），帮助组织评估和提升其软件构建与分发流程的完整性。

3.1.1 SLSA等级与要求

3.2 软件物料清单（SBOM）：供应链的“成分表”

SBOM是一份机器可读的清单，详细列出了软件制品中使用的所有组件、库、依赖及其版本信息。它是进行漏洞扫描、许可证合规性检查和供应链风险分析的基础。

3.2.1 SBOM的核心要素

• 组件名称与版本：明确标识每个依赖项的唯一身份。
• 依赖关系：展示组件之间的层级依赖树。
• 哈希值：提供每个组件的加密哈希，用于验证完整性。
• 许可证信息：列出每个组件的开源许可证类型。
• 供应商与作者：标识组件的来源。

3.2.2 主流SBOM格式对比

3.3 签名与验证流程：信任的基石

签名与验证是连接SLSA框架和SBOM的桥梁。通过签名，我们可以将构建元数据（Provenance）和SBOM与具体的镜像制品绑定，形成一个可验证的信任链。

3.3.1 基于Sigstore的签名与验证流程

Sigstore通过Keyless签名模式，简化了传统PKI的复杂性。其核心流程如下：

1. 身份认证：开发者使用OIDC身份（如GitHub、Google、Microsoft账号）向Fulcio证书颁发机构请求短期证书。
2. 签名生成：使用短期证书对镜像摘要、SBOM或Provenance文件进行签名，生成签名文件（.sig）。
3. 透明日志记录：签名记录被提交到Rekor透明日志，提供全局可审计的公共账本。
4. 验证：验证者从Rekor获取签名记录，通过Fulcio证书和OIDC身份验证签名者的身份，并检查镜像摘要是否匹配。

3.3.2 签名与验证流程SVG图

3.4 三者的协同关系

SLSA、SBOM和签名验证并非孤立存在，而是构成一个完整的供应链安全模型：

• SLSA框架定义了“如何构建”的安全标准，确保构建过程的完整性。
• SBOM回答了“用了什么”，提供软件成分的透明度。
• 签名与验证解决了“谁构建的、是否被篡改”的信任问题，将SLSA的Provenance和SBOM与制品绑定。

3.4.1 协同关系SVG图

3.5 实践中的关键命令

以下是在Sigstore生态中，使用cosign工具进行签名和验证的典型命令示例：

3.5.1 生成并签名SBOM

# 使用 syft 生成 CycloneDX 格式的 SBOM
syft ghcr.io/your-org/your-image:latest -o cyclonedx-json > sbom.cdx.json

# 使用 cosign 对 SBOM 进行签名
cosign sign-blob --key none --bundle sbom.bundle sbom.cdx.json

3.5.2 签名镜像并附加Provenance

# 使用 cosign 对镜像进行 Keyless 签名
cosign sign --key none ghcr.io/your-org/your-image:latest

# 生成并签名 SLSA Provenance（需要 in-toto 工具链）
# 假设已生成 provenance.json
cosign sign-blob --key none --bundle provenance.bundle provenance.json

3.5.3 验证镜像及其附件

# 验证镜像签名
cosign verify --key none ghcr.io/your-org/your-image:latest

# 验证 SBOM 签名
cosign verify-blob --bundle sbom.bundle sbom.cdx.json

# 验证 Provenance 签名
cosign verify-blob --bundle provenance.bundle provenance.json