3. 制品签名基础：软件供应链安全、签名算法简介与签名价值
在云原生环境中，从代码提交到生产部署的链路中，每一个制品（容器镜像、Helm Chart、策略包）都可能成为攻击目标。制品签名是软件供应链安全的第一道防线，它确保制品的完整性、来源真实性和不可抵赖性。
3.1 软件供应链安全威胁模型
现代软件供应链攻击不再局限于代码仓库，而是渗透到构建、分发和部署的每一个环节。常见的攻击向量包括：
- 依赖混淆：攻击者上传同名恶意包到公共仓库，利用内部包管理器的优先级缺陷。
- 构建环境投毒：CI/CD 流水线中的临时凭证泄露或恶意插件篡改构建产物。
- 镜像篡改：在镜像推送到仓库后、拉取到集群前，中间人替换镜像层。
- 元数据伪造：篡改镜像的标签、注解或 SBOM（软件物料清单）信息。
核心原则：签名必须发生在构建管线的可信节点（如 CI Runner 或专用的签名服务），并在部署策略中强制验证，形成“签名-验证”闭环。
3.2 签名算法简介：GPG 与 Sigstore/Cosign
当前主流的制品签名方案分为两类：传统的 GPG 和云原生时代的 Sigstore/Cosign。下表从多个维度对比两者的差异：
| 维度 | GPG (OpenPGP) | Sigstore / Cosign |
|---|---|---|
| 密钥管理 | 自生成密钥对，需自行保护私钥，公钥分发依赖 Key Server 或手动交换 | 无长期密钥；使用 OIDC 身份（GitHub/GitLab/Email）签发临时密钥，签名后私钥即销毁 |
| 签名算法 | RSA / DSA / ECDSA | ECDSA-P256 / Ed25519（通过 Fulcio CA 签发） |
| 验证方式 | 导入公钥到本地信任链，验证签名与摘要 | 通过 Rekor 透明日志查询签名记录，无需预先导入公钥 |
| 透明日志 | 无内置日志，依赖审计 | Rekor 提供不可篡改的签名审计链 |
| 适用场景 | 传统 Git 提交签名、老旧系统集成 | 云原生容器镜像、Helm Chart、策略包签名 |
3.2.1 GPG 签名流程
GPG 使用非对称加密，签名者用私钥对制品的哈希值加密，验证者用公钥解密并比对哈希。其核心步骤为：
- 生成密钥对：
gpg --full-generate-key - 导出公钥并分发：
gpg --armor --export <key-id> > public.key - 对制品签名：
gpg --detach-sign --armor artifact.tar.gz - 验证签名：
gpg --verify artifact.tar.gz.asc artifact.tar.gz
GPG 的运维挑战：私钥泄露风险高、公钥分发依赖带外渠道、密钥轮换成本大，在自动化 CI/CD 中容易成为安全短板。
3.2.2 Sigstore / Cosign 签名流程
Cosign 是 Sigstore 项目的一部分，专为容器镜像和 OCI 制品设计。它消除了密钥管理的痛点：
- 身份绑定：开发者通过 OIDC 登录（如
cosign login），Fulcio CA 签发短期证书。 - 签名与上传：
cosign sign <image>生成签名，并自动上传到 Rekor 透明日志。 - 验证：
cosign verify <image>从 Rekor 获取签名和证书，验证身份与完整性。
# 使用 Cosign 对镜像签名（基于 OIDC 身份）
cosign sign --key azurekms://mykeyvault/mykey myregistry.io/app:1.0
# 验证签名（无需预先导入公钥）
cosign verify --certificate-identity "developer@example.com" \
--certificate-oidc-issuer "https://accounts.google.com" \
myregistry.io/app:1.03.3 签名的作用与价值
制品签名在 DevSecOps 实践中提供三重核心价值：
- 完整性保护：任何对制品的篡改（包括镜像层、配置元数据）都会导致签名验证失败，从源头阻断供应链投毒。
- 身份认证：签名绑定到具体的 OIDC 身份或 GPG 密钥，确保制品来自可信的构建主体，防止“冒名发布”。
- 审计与溯源：Rekor 透明日志提供不可篡改的签名记录，结合 CI/CD 流水线 ID，可快速定位“谁、在何时、签发了哪个制品”。
实践建议：在 IDP 中，建议将 Cosign 签名作为默认策略，并配合 Kyverno / OPA 在集群侧强制验证。对于遗留系统，可使用 GPG 签名作为过渡方案，但需建立密钥轮换和审计机制。
3.4 制品签名链路架构图
下图展示了从开发者提交代码到制品部署的完整签名与验证链路：
3.5 签名算法对比总结
在选择签名方案时，需结合团队运维能力和安全要求。下表给出推荐场景：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 云原生新项目 | Sigstore / Cosign | 无密钥管理、原生 OCI 支持、透明日志审计 |
| 遗留系统 / Git 签名 | GPG | 工具链成熟、社区广泛支持 |
| 高合规金融场景 | Cosign + 硬件密钥 | 短期证书 + HSM 保护私钥，满足合规审计 |
| 多团队 IDP 平台 | Cosign + OIDC | 自动绑定团队身份，策略引擎可基于身份做细粒度控制 |
关键结论：制品签名不是可选项，而是软件供应链安全的强制性基线。在 IDP 中，签名应作为流水线的内置步骤，而非事后补充。结合 Sigstore 的透明日志和 OIDC 身份，可以构建“零信任”的制品交付链路。