1. 课程导论：Sigstore项目背景、云原生安全基线概念、冷启动与削峰场景定义、发布证据链的重要性
1.1 Sigstore 项目背景：从软件供应链安全到无门槛签名
软件供应链攻击在近五年呈指数级增长，传统基于 PKI（公钥基础设施）的代码签名方案因密钥管理复杂、证书轮换成本高、验证流程割裂，难以在云原生 CI/CD 高频迭代场景中落地。Sigstore 项目应运而生，由 Google、Red Hat、Purdue 大学等联合发起，旨在提供一套 免费、透明、易用 的软件签名与验证服务。
Sigstore 的核心技术栈包括三个组件：
| 组件 | 功能 | 关键特性 |
|---|---|---|
| Cosign | 容器镜像与制品的签名/验证 CLI | 支持密钥对、密钥less 模式、OCI 制品签名 |
| Fulcio | 短期证书颁发机构（CA） | 基于 OIDC 身份签发 20 分钟有效证书 |
| Rekor | 不可变透明度日志 | 所有签名元数据上链，支持审计与溯源 |
关键认知： Sigstore 将“签名”从高门槛的密钥管理操作，降级为一次 OIDC 身份认证 + 一条 Rekor 日志记录。开发者无需再担心私钥泄露或证书过期。
1.2 云原生安全基线概念
云原生安全基线是指在 Kubernetes 集群、容器运行时、CI/CD 流水线中，必须满足的一组最低安全配置与行为约束。它不是一次性合规清单，而是随威胁模型持续演进的声明式策略集合。
典型的安全基线维度包括：
- 镜像签名基线：所有部署到生产环境的容器镜像必须经过 Sigstore 签名，且签名必须存在于 Rekor 日志中。
- 准入控制基线：Kubernetes 准入控制器（如 Kyverno、OPA/Gatekeeper）在 Pod 创建前验证签名与策略。
- 运行时基线：容器进程以非 root 运行，只读根文件系统，禁止特权提升。
- 依赖基线：SBOM（软件物料清单）必须生成并签名，第三方依赖无已知高危 CVE。
基线 vs 策略： 基线是“必须满足的门槛”，策略是“如何满足基线的具体规则”。Sigstore 声明式管理将基线编码为可审计的 YAML/JSON 策略文件，实现“策略即代码”。
1.3 冷启动与削峰场景定义
在云原生发布场景中，冷启动与削峰是两种极端但常见的流量与资源模式：
| 场景 | 定义 | 典型表现 | 安全挑战 |
|---|---|---|---|
| 冷启动 | 系统从零开始初始化，或长时间空闲后首次接收请求 | 新集群创建、新版本首次部署、Serverless 函数冷调用 | 签名验证缓存未预热，Fulcio/Rekor 首次调用延迟高，策略加载慢 |
| 削峰 | 突发流量高峰时，系统通过弹性伸缩或限流降级维持可用性 | 大促活动、秒杀、突发热点事件 | 签名验证吞吐量不足，Rekor 日志写入压力大，准入控制器成为瓶颈 |
冷启动与削峰场景对 Sigstore 声明式管理提出了非功能性需求：签名验证必须支持预热缓存、异步批量验证、降级策略与熔断机制，否则安全基线本身会成为发布链路的单点故障。
1.4 发布证据链的重要性
在云原生环境中，一次发布涉及代码提交、镜像构建、签名、部署、策略验证、运行时监控等多个环节。如果每个环节的安全操作没有可审计、不可篡改的证据，一旦出现安全事件，将无法回答以下问题：
- 这个镜像由谁在什么时间签名？
- 签名时使用的身份是否经过 OIDC 认证？
- 准入控制器是否验证了签名？验证结果是什么？
- 部署后的运行时基线是否被违反？
发布证据链正是为了解决上述问题而设计：它将每个安全操作的元数据（签名、验证结果、策略评估、时间戳、身份）串联成一条加密可验证的链，存储在 Rekor 日志或其他不可变存储中。
常见误区： 很多团队只做“签名”不做“证据留存”。签名本身只是一次操作，如果没有将签名与发布流水线的上下文（CI 运行 ID、提交 SHA、环境标签）绑定并持久化，事后审计时签名就是孤立的无效数据。
发布证据链的三大价值：
- 可审计性：满足 SOC2、PCI-DSS、FedRAMP 等合规框架对软件供应链的审计要求。
- 可复现性：通过证据链可以精确重建任意历史发布的完整安全状态。
- 可问责性：每个操作都关联到具体的 OIDC 身份，无法抵赖。