1. 供应链安全概述：软件供应链攻击趋势、镜像供应链风险、Sigstore 在供应链中的定位
1.1 软件供应链攻击趋势：从“直接漏洞”到“信任链污染”
传统安全关注应用自身的代码漏洞，而现代攻击者已将目标前移至开发、构建、分发的全链路。2023–2025 年的攻击数据表明，供应链攻击的年增长率超过 300%，且单次攻击的平均影响面从数千台服务器扩展至数十万容器实例。
| 攻击阶段 | 典型手法 | 2023–2025 代表性事件 |
|---|---|---|
| 依赖投毒 | 向 npm/PyPI/Maven 上传同名恶意包 | colors.js 事件、ua-parser-js 后门 |
| 构建环境劫持 | CI/CD 凭证泄露、恶意 Action/Plugin | Codecov 供应链投毒、SolarWinds 构建链 |
| 镜像仓库篡改 | 未签名镜像被替换、中间人注入恶意层 | Docker Hub 镜像替换、k8s.gcr.io 劫持 |
| 运行时镜像投毒 | 利用已签名但含漏洞的基础镜像横向移动 | Log4Shell 波及镜像、Alpine 镜像 CVE 链 |
关键趋势：攻击者不再依赖“零日漏洞”，而是利用信任盲区——未签名的镜像、不可验证的构建来源、无审计的依赖升级。镜像供应链已成为容器化环境中最薄弱的环节。
1.2 镜像供应链风险：冷启动场景下的四大威胁
在“冷启动”场景（新集群、新节点、弹性扩容、CI/CD 首次拉取）中，镜像供应链面临以下特有风险：
- 镜像完整性缺失：拉取时无法验证镜像是否被篡改，攻击者可插入恶意层或替换整个 manifest。
- 来源不可追溯：无法确认镜像由哪个构建系统、哪个开发者签名，难以实施准入控制。
- 依赖链爆炸：一个基础镜像可能包含数百个系统包和库，冷启动时这些依赖的签名状态未知。
- 拉取性能瓶颈：大规模冷启动时，镜像仓库和签名验证服务成为吞吐瓶颈，导致 Pod 启动延迟飙升。
1.3 Sigstore 在供应链中的定位：从“信任人”到“信任密码学证据”
Sigstore 是 CNCF 孵化的开源软件签名与验证框架，核心定位是为软件供应链提供无门槛的密码学可验证性。它不依赖中心化的 CA 或复杂的 PKI 体系，而是通过以下三个组件重塑信任模型：
| 组件 | 功能 | 在镜像供应链中的角色 |
|---|---|---|
| Cosign | 镜像签名、验证、存储签名 | 为容器镜像生成不可篡改的数字签名，绑定镜像 digest 与签名者身份 |
| Fulcio | 短期证书颁发（OIDC 身份绑定） | 将 GitHub/GitLab/Google 等 OIDC 身份映射为 X.509 证书，无需管理长期密钥 |
| Rekor | 透明日志（不可变审计账本） | 所有签名操作写入公开可审计的 Merkle 树，防止签名被删除或抵赖 |
Sigstore 的核心创新：将“信任链”从“你信任谁”转变为“你能验证什么”。任何拉取方都可以通过 Rekor 日志和 Fulcio 证书独立验证镜像签名，无需预先配置信任锚点。
1.4 为什么 Sigstore 适合冷启动削峰场景？
- 无状态验证：验证方只需持有 Rekor 的公开根哈希和 Fulcio 的证书链，无需维护本地密钥库。
- 签名与镜像分离：签名可以存储在 OCI 仓库、HTTP 服务器或内存缓存中，支持 CDN 加速和本地缓存预热。
- 批量验证能力：Cosign 支持对一批镜像的 digest 列表进行聚合签名验证，减少冷启动时的 RPC 次数。
- 与 Kubernetes 原生集成：通过
cosign verify-admission或 Kyverno/OPA 策略，在 Pod 创建前完成验证，避免运行恶意镜像。