技术深度解析
Rekor的架构巧妙地将无状态API服务器与持久化透明度日志后端分离。Rekor服务器本身用Go语言编写，提供用于提交条目（哈希值、签名、公钥、证明）和查询日志的RESTful端点。其无状态设计支持水平扩展和简化部署。然而，真正的加密重任则委托给了Trillian——一个由谷歌开发的通用透明度日志，它提供了底层的默克尔树数据结构和仅追加保证。
当客户端提交一个条目（例如，容器镜像摘要的签名）时，Rekor会将其打包成特定的“种类”（例如用于in-toto证明的`hashedrekord`或`intoto`），创建规范的JSON表示形式，并计算其SHA256哈希值。此哈希值成为Trillian默克尔树中的叶节点。包含证明——从叶节点到当前树根的默克尔路径——会与一个已签名的树头（STH）一同返回给客户端。STH会定期由Rekor的私钥签名，创建检查点，防止恶意日志操作者分叉历史记录。任何人都可以通过使用公开可用的树数据重新计算默克尔路径，并与可信的STH进行比对，来验证某个条目是否存在于日志中。
`intoto`条目类型在捕获软件物料清单（SBOM）和构建溯源方面尤为强大。它实现了in-toto证明格式，允许构建系统精确记录使用了哪些材料、谁执行了构建以及执行了哪些命令。这创建了一条从源代码到分发制品的可审计链条。
性能对采用至关重要。公共Rekor实例（rekor.sigstore.dev）处理着数百万条目。关键指标包括提交延迟、查询吞吐量和日志增长率。
| 指标 | 数值（公共实例） | 目标SLA |
|---|---|---|
| 平均条目提交延迟 | < 2 秒 | < 5 秒 |
| 查询（获取/搜索）延迟 | < 500 毫秒 | < 1 秒 |
| 已处理条目（累计） | 约 5000 万（预计2025年第一季度） | 不适用 |
| 正常运行时间（过去90天） | 99.95% | 99.9% |
| 最大条目大小 | 1 MB | 私有部署中可配置 |
数据要点： 公共Rekor实例展现了生产级的可靠性和性能，亚秒级的查询时间支持其集成到自动化CI/CD流水线中。累计条目数显示了其在开源生态系统中快速、有机的采用。
Rekor的代码库在GitHub（`sigstore/rekor`）上积极开发。最近的提交侧重于批量查询的性能优化、增强的搜索能力（包括对特定字段的正则表达式支持）以及对SBOM的新证明格式（如SPDX和CycloneDX）的改进支持。该项目针对条目类型的插件架构允许社区在不修改核心代码的情况下扩展其功能。
关键参与者与案例研究
Sigstore以及延伸的Rekor，由开源安全基金会（OpenSSF） 管理，并得到了谷歌、红帽、VMware和GitHub的重大贡献。这种跨行业的支持对于其作为一个中立公共设施被采用至关重要。谷歌的参与尤为深入，既提供了最初的Trillian技术，也贡献了重要的工程资源。Dan Lorenc，Chainguard前首席执行官、Sigstore核心贡献者，在阐述透明软件供应链愿景方面发挥了关键作用。
采用模式揭示了两个主要用例：保护开源分发和强化企业CI/CD。
开源基金会与软件包仓库： Python软件包索引（PyPI） 现在默认使用Sigstore对所有上传的软件包进行签名，并将元数据记录在Rekor中。同样，Go模块代理（`proxy.golang.org`）也使用Sigstore实现透明度。这意味着任何Python软件包或Go模块用户都可以根据公共日志加密验证其来源和完整性。Kubernetes的发布流程已完全集成Sigstore，所有发布制品都通过Cosign签名，溯源信息记录在Rekor中。
企业CI/CD集成： GitHub和GitLab等公司已在其Actions和CI流水线中内置了原生Sigstore支持。GitHub的`gh attest`命令和`sigstore/cosign-installer` Action使开发者能够轻松地对制品进行签名并将证据存储在Rekor中。Tekton和ArgoCD等流行的CI/CD平台拥有插件，可在将制品部署到生产环境之前验证Rekor条目。
存在竞争性和互补性的解决方案，但它们通常针对问题的不同部分，或在不同的信任模型下运行。
| 解决方案 | 主要关注点 | 信任模型 | 与Rekor的关键区别 |
|---|---|---|---|
| Sigstore (Rekor) | 公共透明度日志 | 去中心化，公共产品 | 全球性、不可变总账；无