1. 供应链安全概述
1.1 软件供应链攻击趋势
软件供应链攻击已成为云原生时代最具破坏力的威胁向量之一。攻击者不再直接攻破生产环境，而是将恶意代码植入开发、构建或分发环节，利用信任链的“上游污染”效应，一次性影响成千上万的下游用户。
关键数据： 根据 Sonatype 2024 年报告，过去三年软件供应链攻击数量年均增长超过 600%，其中针对容器镜像的投毒事件占比从 12% 跃升至 37%。
常见的镜像供应链攻击模式包括：
| 攻击类型 | 攻击阶段 | 典型手法 | 影响范围 |
|---|---|---|---|
| 基础镜像投毒 | 构建 | 篡改官方基础镜像，植入后门或挖矿程序 | 所有基于该镜像构建的应用 |
| 依赖混淆 | 构建 | 上传同名恶意包到公共仓库，利用自动拉取机制 | 单个项目或组织 |
| 镜像标签篡改 | 分发 | 替换 registry 中已有镜像的标签指向恶意版本 | 拉取该标签的所有客户端 |
| 中间人劫持 | 传输 | 拦截镜像拉取请求，返回伪造镜像 | 特定网络环境下的用户 |
| CI/CD 管道投毒 | 构建/部署 | 攻破 CI 系统，在构建过程中注入恶意层 | 该管道产出的所有制品 |
注意： 传统基于摘要（digest）的校验只能防止传输过程中的篡改，无法防御构建阶段的投毒或 registry 内部的标签替换。这是引入签名机制的根本原因。
1.2 镜像供应链信任模型
一个完整的镜像供应链信任模型需要回答三个核心问题：谁构建了镜像？谁批准了镜像？镜像内容是否与声明一致？
现代信任模型通常包含以下层次：
- 身份层： 确认签名者的身份（如：构建系统、安全审核员、发布经理）。
- 完整性层： 验证镜像内容未被篡改（签名与镜像摘要绑定）。
- 策略层： 定义哪些身份、在什么条件下签名的镜像可以被信任（如：必须同时有构建签名和安全审核签名）。
- 审计层： 记录所有签名、验证和策略变更事件，支持事后追溯。
下图展示了从代码提交到生产部署的完整信任链：
实践要点： 信任模型不应只依赖单一签名。推荐采用“多签策略”——要求构建系统、安全扫描工具和发布审批人分别签名，策略引擎验证所有签名均有效后才允许部署。
1.3 Cosign 在信任链中的角色
Cosign 是 Sigstore 项目下的容器镜像签名工具，旨在解决传统镜像签名方案（如 Docker Content Trust）的密钥管理复杂、无法与 CI/CD 深度集成等痛点。它在供应链信任链中承担以下核心角色：
| 角色 | 功能描述 | 对应信任模型层次 |
|---|---|---|
| 签名者 | 使用私钥或 OIDC 身份对镜像摘要进行签名，生成签名载荷 | 身份层 + 完整性层 |
| 验证者 | 验证签名是否由可信身份产生，以及镜像摘要是否与签名时一致 | 完整性层 + 策略层 |
| 策略执行者 | 通过 cosign verify 或 cosign verify-attestation 结合自定义策略检查签名属性 |
策略层 |
| 审计记录者 | 签名操作可记录到 Rekor 透明日志，提供不可篡改的审计证据 | 审计层 |
Cosign 相比传统方案的关键优势：
- 无密钥模式： 支持通过 OIDC（如 GitHub、Google、Microsoft）进行身份认证，无需管理长期私钥。
- 透明日志集成： 签名自动上传至 Rekor，任何人都可验证签名的时间戳和完整性。
- 策略即代码： 支持使用 CUE、Rego 等策略语言定义签名验证规则。
- 多平台支持： 不仅支持容器镜像，还支持二进制文件、SBOM、文本文件等任意制品。
故障排查视角： 本课程后续章节将深入分析 Cosign 签名验证失败的常见原因——包括密钥不匹配、OIDC 令牌过期、Rekor 查询超时、策略规则冲突等，并提供可复现的排查步骤和修复方案。
下图展示了 Cosign 在 Sigstore 生态中的位置及其与周边组件的交互关系：