2. Sigstore 核心组件：功能与协作

Sigstore 并非单一工具，而是一组相互协作的开源服务与客户端，共同构建了“免密钥管理”的软件供应链安全基础设施。理解其四大核心组件——CTL (Certificate Transparency Log)、Rekor、Fulcio 和 Cosign——的功能与协作关系，是掌握 Sigstore 告警分析的基础。

2.1 组件总览与职责划分

下表从核心职责、数据存储、安全属性和告警关注点四个维度，对四大组件进行对比：

组件	核心职责	数据存储	安全属性	告警关注点
Fulcio	签发短期代码签名证书	无持久化存储（仅签发）	基于 OIDC 身份认证	证书签发异常、OIDC 令牌伪造
Rekor	不可变签名与元数据日志	Merkle Tree 结构	透明性、可审计	日志条目篡改、一致性失败
CTL	证书透明度日志	Merkle Tree 结构	证书公开监控	未记录证书、日志分叉
Cosign	客户端签名/验证/存储	OCI 制品仓库	策略执行	签名策略绕过、密钥泄露

2.2 组件深度解析

2.2.1 Fulcio —— 代码签名证书颁发机构

Fulcio 是一个专为代码签名设计的证书颁发机构（CA）。它不管理长期密钥，而是通过 OIDC（OpenID Connect）协议验证用户身份后，签发短期有效的 X.509 证书（通常有效期为 10 分钟）。

• 身份绑定：将 OIDC 身份（如 email、GitHub 账号）直接嵌入证书主体字段。
• 无密钥管理：私钥仅在签名瞬间存在于内存中，证书过期后自动失效。
• 告警场景：Fulcio 签发频率异常激增、OIDC 令牌来自未授权 IdP、证书扩展字段异常。

2.2.2 Rekor —— 透明性日志

Rekor 是 Sigstore 的不可变账本，记录所有签名元数据（包括签名本身、证书、制品哈希等）。它使用 Merkle Tree 数据结构保证日志的追加性和可验证性。

• 条目类型：支持多种签名格式（Rekord、HashedRekord、Helm 等）。
• 搜索能力：通过 UUID、制品哈希或公钥哈希检索条目。
• 告警场景：日志条目被删除或修改、Merkle Tree 根哈希不一致、搜索请求返回不一致结果。

2.2.3 CTL (Certificate Transparency Log) —— 证书透明度日志

CTL 是 Fulcio 签发证书的公开审计日志。所有由 Fulcio 签发的证书必须提交到 CTL，否则 Cosign 验证时会拒绝信任。CTL 与 Rekor 共同构成 Sigstore 的“双重透明性”保障。

• 证书监控：任何人都可以监控 CTL 中新增的证书，发现恶意签发的证书。
• 分叉检测：通过 Signed Certificate Timestamp (SCT) 验证证书是否被正确记录。
• 告警场景：证书未包含 SCT、CTL 服务器不可达、SCT 签名验证失败。

2.2.4 Cosign —— 客户端工具与策略引擎

Cosign 是 Sigstore 的命令行客户端和策略引擎，负责执行签名、验证和存储操作。它不直接管理密钥，而是调用 Fulcio 获取证书、调用 Rekor 记录签名。

• 签名流程：Cosign 生成临时密钥对 → 请求 Fulcio 签发证书 → 使用私钥签名制品 → 将签名和证书上传到 OCI 仓库 → 将签名元数据提交到 Rekor。
• 验证流程：Cosign 从 OCI 仓库获取签名 → 从 Rekor 获取对应条目 → 验证证书链和 SCT → 验证签名有效性。
• 告警场景：Cosign 验证失败（证书过期、签名不匹配）、策略违反（强制使用特定 IdP）、OCI 仓库访问异常。

2.3 组件协作流程

下图展示了 Sigstore 组件在签名和验证两个阶段的完整协作关系：

2.4 组件协作的告警意义

理解组件协作关系后，可以更精准地定位告警根因。以下是一个典型的告警排查示例：

2.5 组件依赖关系总结

下表总结了组件之间的依赖关系，帮助理解告警传播路径：

依赖方向	依赖关系	影响说明
Cosign → Fulcio	签名时必须依赖	Fulcio 不可用则无法完成签名
Fulcio → CTL	证书签发后必须提交	CTL 不可用则证书无法被信任
Cosign → Rekor	签名和验证都依赖	Rekor 不可用则无法记录或验证签名
Cosign → OCI 仓库	签名存储和获取依赖	OCI 仓库不可用则签名无法持久化