3. Cosign 简介：项目背景、核心功能与在 Sigstore 生态中的角色
Cosign 是 Sigstore 生态中面向容器镜像与软件工件的签名、验证与存储工具。它解决了“谁签的名、签名是否有效、工件是否被篡改”三个核心问题，是云原生供应链安全中落地最广的签名组件之一。
3.1 项目背景：为什么需要 Cosign？
在容器化与 Kubernetes 普及之前，软件分发主要依赖包管理器（apt、npm、Maven）的 GPG 签名。容器镜像引入后，传统签名方案面临三个痛点：
- 密钥管理复杂：GPG 密钥对生成、分发、吊销流程繁琐，不适合 CI/CD 自动化。
- 镜像层结构不透明：镜像由多层组成，传统签名只覆盖 manifest，无法保证每层完整性。
- 缺乏透明日志：签名行为不可审计，无法检测密钥泄露后的历史签名。
Cosign 于 2021 年由 Google、Red Hat、Chainguard 等联合推出，定位为“云原生时代的 GPG 替代品”，并成为 Sigstore 项目的核心组件之一。
关键数据：截至 2025 年，Cosign 已被超过 60% 的 CNCF 毕业项目用于镜像签名，日均签名量超过 500 万次。
3.2 核心功能矩阵
Cosign 提供从签名生成到策略验证的完整工具链，下表列出其主要功能及对应命令：
| 功能类别 | 具体能力 | 典型命令/参数 |
|---|---|---|
| 签名 | 对容器镜像、blob、文本文件进行数字签名 | cosign sign |
| 验证 | 验证签名是否有效、是否由可信公钥签发 | cosign verify |
| 密钥管理 | 生成密钥对、上传公钥到 OCI 仓库或 KMS | cosign generate-key-pair |
| 透明日志 | 将签名记录提交到 Rekor 透明日志 | cosign sign --tlog-upload |
| 策略评估 | 基于策略文件（CUE/Rego）批量验证签名 | cosign verify-attestation |
| 附件管理 | 附加 SBOM、SLSA 证明等元数据到镜像 | cosign attach |
| 密钥无感签名 | 通过 OIDC 身份自动获取短期签名证书 | cosign sign --identity- |
容量巡检场景提示：在镜像供应链安全容量巡检中，
cosign verify 是最常用的命令。巡检脚本会遍历仓库中所有镜像，检查每个镜像是否携带有效签名，并记录未签名镜像的数量与占比。
3.3 在 Sigstore 生态中的角色
Sigstore 是一个由 Fulcio（证书颁发机构）、Rekor（透明日志） 和 Cosign（签名工具） 组成的开放签名框架。Cosign 在其中的定位是“用户与 Sigstore 基础设施之间的操作接口”。
下图展示了 Cosign 在 Sigstore 生态中的核心交互流程：
3.4 三种签名模式对比
Cosign 支持三种签名模式，适用于不同的安全等级与自动化场景：
| 模式 | 密钥来源 | 适用场景 | 安全等级 |
|---|---|---|---|
| 密钥对模式 | 本地生成或 KMS 托管 | 内部私有仓库、离线环境 | 高（需妥善保管私钥） |
| 密钥无感模式 | 通过 OIDC 从 Fulcio 获取短期证书 | CI/CD 流水线、GitHub Actions | 极高（证书有效期短，自动吊销） |
| 导入模式 | 导入已有 GPG/PKI 密钥 | 从传统签名迁移过渡 | 中（依赖原有密钥管理） |
容量巡检注意事项：在巡检大规模镜像仓库时，密钥无感模式生成的签名会附带完整的证书链，验证时需要联网查询 Fulcio 和 Rekor。如果巡检环境为离线或受限网络，建议使用密钥对模式并提前将公钥分发到所有巡检节点。
3.5 签名存储结构
Cosign 将签名以 OCI 制品的形式存储在镜像仓库中，与原始镜像位于同一仓库下。签名镜像的命名规则如下：
# 原始镜像
registry.example.com/team-a/app:v1.0.0
# Cosign 自动生成的签名镜像
registry.example.com/team-a/app:sha256-<digest>.sig
# 可选的 SBOM 附件镜像
registry.example.com/team-a/app:sha256-<digest>.sbom
# 可选的证明附件镜像
registry.example.com/team-a/app:sha256-<digest>.att这种“镜像即签名载体”的设计使得签名与镜像天然绑定，无需额外的签名存储服务，也方便在容量巡检中通过 cosign verify 直接检查每个镜像的签名状态。