Sigstore供应链签名安全监控与告警 - 第1节
1.1 Sigstore 项目背景
软件供应链攻击在近五年呈指数级增长——从 SolarWinds 到 Codecov，攻击者不再直接攻击最终应用，而是污染构建工具、依赖库和签名基础设施。传统 PGP 签名体系存在三个致命缺陷：
- 密钥管理分散：每个开发者自行生成、保管和轮换密钥，缺乏统一生命周期管理；
- 信任锚模糊：PGP 的 Web of Trust 依赖人工验证，大规模场景下几乎不可操作；
- 无透明审计：签名行为不可公开验证，事后追溯困难。
Sigstore 由 Google、Red Hat、Purdue 大学等联合发起，旨在用 无密钥签名（Keyless Signing） 和 透明日志（Transparency Log） 彻底重构软件签名生态。2021 年进入 CNCF Sandbox，2023 年晋升为 Incubating 项目，已成为业界事实标准。
核心驱动力：Sigstore 将签名从“开发者私钥保管”转变为“短期身份凭证 + 公开可审计日志”，使任何使用 OIDC 身份（GitHub、Google、Microsoft 等）的开发者都能在 30 秒内完成可验证签名。
1.2 核心目标与设计原则
| 目标 | 说明 | 解决的传统痛点 |
|---|---|---|
| 无密钥签名 | 使用短期 OIDC 令牌 + 临时密钥对，签名后立即丢弃私钥 | 私钥泄露、丢失、轮换困难 |
| 透明日志 | 所有签名记录写入 Rekor 不可篡改日志，支持公开审计 | 签名不可追溯、无防抵赖机制 |
| 开放联邦 | 支持任意 OIDC 身份提供商，不绑定特定平台 | 供应商锁定、身份孤岛 |
| 零成本入门 | 无需管理密钥基础设施，CLI 工具 cosign 一行命令完成签名 |
PGP/GPG 学习曲线陡峭 |
Sigstore 的设计哲学可概括为：默认安全、公开透明、身份即密钥。它不要求开发者成为密码学专家，而是将安全责任下沉到基础设施层。
1.3 与软件供应链安全的关系
软件供应链安全的核心是回答三个问题：
- 谁 生产了这份工件？
- 它 是否被篡改过？
- 我 能否信任这个来源？
Sigstore 通过三个组件分别对应这三个问题：
| 供应链安全环节 | Sigstore 组件 | 作用 |
|---|---|---|
| 身份认证（Who） | Fulcio（证书颁发机构） | 基于 OIDC 签发短期代码签名证书 |
| 完整性验证（What） | Cosign（签名/验证工具） | 对容器镜像、blob、SBOM 等进行签名和校验 |
| 透明审计（Trust） | Rekor（透明日志） | 永久存储签名元数据，支持公开查询和监控 |
实践建议：在 CI/CD 流水线中集成 Sigstore 后，每次构建都会自动生成可验证的签名记录。即使攻击者拿到构建机权限，也无法伪造历史签名——因为 Rekor 日志的 Merkle 树结构会暴露任何篡改行为。
1.4 Sigstore 核心架构
下图展示了 Sigstore 在软件供应链中的位置及其内部组件交互流程：
1.5 透明日志与告警的关系
Rekor 透明日志是 Sigstore 区别于传统签名方案的核心创新，也是本课程告警体系的数据基础。每条签名记录包含：
- 工件摘要（SHA256 哈希）
- 签名者身份（OIDC 邮箱或 Subject）
- 证书序列号及有效期
- 时间戳（RFC3161 可信时间）
当安全团队需要检测异常签名行为时，Rekor 日志提供了不可抵赖的审计线索。例如：
告警场景示例：某开发者的 OIDC 令牌在非工作时间从异常 IP 签名了生产镜像。通过查询 Rekor 日志，安全团队可以立即定位该签名记录，并结合 Fulcio 证书的 OIDC 声明判断是否为身份盗用。