技术深度解析
Fulcio的架构堪称利用现有网络基础设施实现创新安全目标的典范。其本质是一个专业化的公钥基础设施（PKI），其中证书的“主体”不再是组织名称，而是OIDC身份声明。工作流程遵循精确的序列：
1. 身份验证：开发者运行`cosign sign`等命令，被重定向至OIDC提供商（如GitHub）进行认证。成功后获得OIDC ID令牌。
2. 证书颁发：客户端将包含新生成公钥的证书签名请求（CSR）与OIDC ID令牌一同发送至Fulcio。
3. 身份核验：Fulcio验证ID令牌的签名并提取预定义声明。关键声明是`email`字段，该字段必须经过OIDC提供商验证。Fulcio同时检查令牌颁发者是否在允许列表中。
4. 证书绑定：Fulcio构建X.509证书，将主题备用名称（SAN）设置为开发者邮箱（如`email:developer@company.com`）。证书的`颁发者`和`主体`也基于OIDC声明填充。CSR中的公钥被嵌入，证书由Fulcio根CA签名。
5. 短期有效：所颁发证书有效期通常为10-20分钟，仅够完成签名事务。
6. 透明日志记录：证书与制品签名被发送至Rekor，创建公开且防篡改的记录。
与证书公钥对应的私钥仅在客户端机器上短暂存在（通常在内存中），签名后即被丢弃。这正是“身份即密钥”的精髓——长期秘密并非加密密钥，而是开发者对其OIDC账户的访问权限。
Fulcio的信任根是其根证书颁发机构，其公钥已广泛分发并嵌入Cosign等客户端。项目维护测试和生产两个根证书，后者是生态系统的关键信任锚。技术栈采用Go语言编写，强调简洁性与安全性。`sigstore/fulcio` GitHub仓库（⭐814）作为规范实现，积极开发的重点包括支持新OIDC提供商、完善证书配置文件以及提升可扩展性。
关键性能指标是颁发延迟和可靠性，因其位于开发者工作流的关键路径上。虽然Fulcio未发布正式基准测试，但社区观察表明证书颁发可在亚秒级完成，在整个CI/CD流水线中可忽略不计。
| 组件 | 角色 | 信任机制 | 生命周期 |
|---|---|---|---|
| OIDC提供商（GitHub） | 验证开发者身份 | 中心化、网络级认证 | 长期账户 |
| Fulcio CA | 颁发代码签名证书 | 受信任根证书 | 10-20分钟 |
| 客户端私钥 | 签署制品 | 临时性、内存存储 | 秒级（单次使用） |
| Rekor | 记录签名与证书 | 默克尔树+流言协议 | 不可变、永久 |
数据洞察：此表展示了签名过程中信任与生命周期的根本性重新分配。长期秘密（OIDC账户）由成熟的外部提供商管理，而加密秘密则是临时的。Fulcio充当了这两个世界之间关键的可信桥梁。
关键参与者与案例研究
以Fulcio为核心的Sigstore生态系统由行业领导者联盟推动，并被主要平台采用，形成了强大的网络效应。
核心维护者与支持方：项目由Google、Red Hat和普渡大学SECURE研究实验室的开发者共同创建。持续的重要贡献来自Chainguard的工程师，这家由Sigstore联合创始人创立的企业为项目提供商业支持和企业工具。Linux基金会作为项目的中立托管方，资金来自包括Google、Red Hat、VMware和Cisco在内的联盟。
应用案例研究：
1. Google：作为主要支持者，Google将Sigstore深度集成至其服务中。Google Cloud Build原生支持使用Sigstore签名制品。更重要的是，Artifact Registry和Cloud Run能够验证Sigstore签名，强制执行仅部署正确签名容器的策略，从而形成闭环的安全软件工厂。
2. GitHub Actions：官方的`sigstore/cosign-installer` Action每周运行超过150万次。这使得任何GitHub工作流都能利用运行器内置的GitHub OIDC令牌轻松签名发布制品，完全自动化来源生成，无需任何秘密配置。
3. Kubernetes：Kubernetes发布流程