第一章：Sigstore：重塑软件供应链安全的信任基石
在现代软件开发中，开源组件的广泛使用使得软件供应链攻击日益频繁。Sigstore 作为一个开源项目，旨在通过提供透明、自动化和可验证的代码签名机制，从根本上增强软件发布的可信度。其核心理念是让每一次构建、每一次发布都能被开发者和用户共同验证，从而建立端到端的信任链条。
零信任环境下的签名革命
传统代码签名依赖于长期有效的私钥，一旦泄露风险极高。Sigstore 引入了基于短期密钥和公开可验证日志的签名体系，利用加密技术确保签名不可伪造且可追溯。
核心组件与工作原理
Sigstore 的三大支柱包括：
- cosign：用于容器镜像和文件的签名与验证工具
- fulcio：提供基于 OIDC 身份认证的代码签名证书颁发服务
- rekor：不可篡改的透明日志系统，记录所有签名事件
开发者可通过以下命令对容器镜像进行签名：
# 使用 cosign 签名镜像 cosign sign --key oidc:// gcr.io/example/image:latest # 验证签名并查询 Rekor 日志 cosign verify gcr.io/example/image:latest
透明化验证流程
每次签名操作都会在 Rekor 中生成一条哈希记录，任何第三方均可独立验证该记录的真实性。这种设计借鉴了 Let's Encrypt 和 Certificate Transparency 的成功经验，将信任从单一实体分散至公共审计。
| 组件 | 功能 | 安全性优势 |
|---|
| Fulcio | 签发短时效代码签名证书 | 避免长期密钥暴露风险 |
| Rekor | 存储签名哈希日志 | 支持全球公开审计 |
| Cosign | 执行签名与验证 | 简化开发者操作流程 |
graph LR A[开发者] -->|OIDC身份认证| B(Fulcio) B -->|签发证书| C[Cosign] C -->|生成签名| D[容器镜像] C -->|上传哈希| E(Rekor透明日志) F[用户] -->|验证签名| C F -->|查询日志| E
第二章：Sigstore核心组件与工作原理
2.1 理解Cosign：容器镜像签名与验证机制
签名机制核心原理
Cosign 是 Sigstore 项目的一部分，专注于为容器镜像提供无密钥（keyless）签名与验证能力。它利用公钥基础设施（PKI）与透明日志（Transparency Log）确保镜像来源可信。
基本使用流程
用户可通过以下命令对镜像进行签名：
cosign sign --key cosign.key my-registry/my-image:v1
该命令使用本地私钥
cosign.key对指定镜像生成数字签名，并将其上传至镜像仓库。参数
--key指定签名所用的密钥路径，支持多种密钥格式。 验证时执行：
cosign verify --key cosign.pub my-registry/my-image:v1
系统将拉取镜像签名和公钥
cosign.pub，校验签名完整性，确认镜像未被篡改且来自可信发布者。
信任链构建方式
- 基于 OIDC 身份认证实现开发者身份绑定
- 签名记录写入 Rekor 透明日志，确保可审计性
- 支持 SLSA 安全等级提升，强化供应链防护
2.2 Rekor透明日志：不可篡改的签名审计追踪
Rekor 是 Sigstore 生态中的核心组件，提供基于可验证证书透明度（Verifiable Certificate Transparency）的公开、不可篡改日志服务。它记录所有代码签名行为，确保每个签名事件都可被独立验证和追溯。
核心机制
通过 Merkle 树结构，Rekor 将每次签名条目以哈希形式追加至日志，生成全局一致的树根。任何第三方均可通过一致性证明校验日志完整性。
条目结构示例
{ "body": "eyJpYWtlIjogImV4YW1wbGUuYXJ0aWZhY3QudGFyLmd6In0=", "integratedTime": 1678886400, "logIndex": 12345, "verification": { "signedEntryTimestamp": "ABCD1234..." } }
上述 JSON 展示了一个典型的 Rekor 条目，
body包含 Base64 编码的签名对象信息，
integratedTime表示录入时间戳，
logIndex为全局唯一序列号，
signedEntryTimestamp提供密码学证据，证明该条目已安全纳入日志。
2.3 Fulcio证书颁发：基于OIDC的身份绑定与零信任实践
Fulcio作为Sigstore生态中的核心证书颁发机构，通过集成OIDC（OpenID Connect）实现开发者身份的可信绑定，推动软件供应链向零信任架构演进。
身份验证流程
用户通过GitHub等支持OIDC的平台完成身份认证，获取短期JWT令牌。该令牌由Fulcio验证后用于签发短时效X.509证书，确保证书持有者身份可追溯。
证书签发示例
// 示例：使用OIDC ID Token请求Fulcio签发证书 resp, err := client.CreateCertificate(ctx, &cosign.CreateCertificateOptions{ OIDCIDToken: idToken, // 来自GitHub Actions的OIDC令牌 PublicKey: pubKey, // 开发者公钥 })
上述代码中，
idToken由CI环境自动注入，确保运行时身份真实性；
pubKey用于生成对应证书公钥内容，实现密钥对绑定。
- OIDC提供标准化身份源，消除静态凭据依赖
- 证书有效期通常为数分钟，降低泄露风险
- 与Rekor日志系统联动，确保证书使用可审计
2.4 签名流程实战：从本地构建到远程验证的端到端演示
在实际开发中，确保软件供应链安全的关键环节之一是代码签名与验证。本节将演示如何从本地构建签名制品，并在远程环境中完成完整性校验。
生成签名密钥对
使用 OpenSSL 生成 RSA 密钥对，用于后续签名操作：
openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048 openssl pkey -in private_key.pem -pubout -out public_key.pem
上述命令生成 2048 位的私钥和对应的公钥文件，私钥用于本地签名，公钥分发至验证方。
签署构建产物
对编译后的二进制文件计算哈希并签名：
sha256sum app.bin | awk '{print $1}' > app.hash openssl rsautl -sign -inkey private_key.pem -keyform PEM -in app.hash -out app.sig
签名文件
app.sig可随制品一同发布，供下游验证使用。
远程验证流程
验证端使用公钥对接收到的签名进行解密，并比对本地计算的哈希值，确保数据未被篡改。
2.5 公钥管理革命：告别PGP密钥环的复杂运维
传统PGP密钥环依赖用户手动交换和验证公钥，导致可扩展性差、信任链维护成本高。现代公钥基础设施（PKI）正转向自动化、集中化的管理模式。
基于证书的公钥分发
通过可信证书颁发机构（CA）签发数字证书，实现公钥与身份的绑定。客户端仅需预置少量根证书，即可验证任意用户公钥。
| 机制 | 信任模型 | 运维复杂度 |
|---|
| PGP密钥环 | 去中心化（Web of Trust） | 高 |
| X.509证书体系 | 中心化（CA层级） | 低 |
自动化密钥轮换示例
func rotateKey(certManager *CertManager) error { newKey, err := rsa.GenerateKey(rand.Reader, 2048) if err != nil { return err } // 自动向CA申请签发新证书 return certManager.SubmitCSR(newKey) }
该函数展示如何生成新密钥并自动提交证书签名请求（CSR），无需人工干预，显著降低密钥轮换门槛。
第三章：Sigstore在CI/CD中的集成策略
3.1 在GitHub Actions中自动签署制品并上传Rekor
在持续集成流程中，确保制品完整性至关重要。通过GitHub Actions可实现构建产物的自动化签名与透明化存证。
签名与上传流程
使用Cosign对容器镜像进行签名，并将签名记录提交至Sigstore的Rekor透明日志系统，增强供应链安全性。
- 构建镜像后生成签名
- 利用私钥签署制品
- 将公钥和签名上传至Rekor进行存证
- name: Sign image run: | cosign sign --key github-key://signing-key ${{ env.IMAGE }}
该步骤使用GitHub托管密钥完成签名操作，无需暴露私钥。签名信息自动关联到镜像摘要，并异步上传至Rekor，实现不可篡改的审计追踪。
3.2 使用Tekton或Argo Workflows实现企业级流水线集成
在构建现代化CI/CD体系时，Tekton和Argo Workflows成为编排复杂流水线的核心组件。两者均基于Kubernetes原生设计，支持声明式工作流定义，适用于大规模企业环境。
核心优势对比
- Tekton：模块化任务设计，适合标准CI/CD场景，与Kubernetes生态无缝集成；
- Argo Workflows：支持DAG调度，适用于机器学习、数据处理等复杂依赖场景。
典型流水线定义示例（Tekton）
apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: build-test-deploy spec: tasks: - name: build taskRef: name: build-image - name: test taskRef: name: run-tests runAfter: - build - name: deploy taskRef: name: deploy-to-prod runAfter: - test
上述Pipeline按序执行构建、测试、部署任务，
runAfter确保任务间依赖关系明确，提升流水线可预测性。
3.3 策略执行：结合Kyverno或OPA进行签名强制校验
在Kubernetes集群中，确保容器镜像来源可信是安全策略的核心环节。通过集成Kyverno或OPA（Open Policy Agent），可在准入控制阶段强制校验镜像签名。
使用Kyverno校验镜像签名
Kyverno支持基于cosign的镜像签名验证策略。以下策略示例拒绝未签名的镜像：
apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: require-signed-image spec: validationFailureAction: enforce rules: - name: verify-signed-image match: resources: kinds: - Pod verifyImages: - image: "ghcr.io/example/*" key: |-----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY-----
该策略在Pod创建时触发，验证镜像是否使用指定公钥对应的私钥签名。未通过校验的资源将被拒绝。
OPA与Cosign集成方案
通过Gatekeeper，OPA可结合外部数据（如签名元数据）实现更灵活的策略控制。例如，从Sigstore透明日志查询签名有效性，并在策略中引用。 两种工具均能有效实施零信任安全模型，强化镜像供应链安全保障。
第四章：高级应用场景与安全加固
4.1 多方协作场景下的联合签名与责任共担模型
在分布式系统中，多方协作常涉及敏感操作的共同授权。联合签名机制允许多个参与方对同一事务生成部分签名，最终合成完整签名，确保任一单方无法独立完成操作。
门限签名流程示例（2-of-3）
// 简化的门限签名聚合逻辑 func aggregateSignatures(partialSigs [][]byte) ([]byte, error) { if len(partialSigs) < 2 { return nil, errors.New("not enough signatures") } // 使用Shamir秘密共享与椭圆曲线加法合并签名 return crypto.CombineSigs(partialSigs), nil }
该函数验证至少两个签名存在，并通过密码学方法合并。参数
partialSigs代表来自不同方的部分签名，仅当达到预设阈值时才能重构有效签名。
责任共担机制设计要点
- 每个签名方使用独立密钥分片，杜绝密钥集中风险
- 所有签名请求需记录于共享审计日志
- 操作行为绑定数字指纹，支持事后追溯
4.2 私有化部署Fulcio与Rekor：合规性与数据主权保障
在高度监管的行业环境中，私有化部署Fulcio和Rekor成为保障数据主权与合规性的关键举措。企业可将证书签发（Fulcio）与透明日志记录（Rekor）完全置于内部网络中，避免敏感元数据外泄。
核心组件部署架构
- Fulcio CA运行于隔离的Kubernetes集群，使用硬件安全模块（HSM）保护根密钥
- Rekor实例对接企业级审计系统，确保所有签名事件可追溯
- 通过OIDC身份提供者实现与内部IAM系统的集成
自定义策略配置示例
apiVersion: v1 kind: ConfigMap metadata: name: fulcio-config data: config.json: | { "issuer": "https://internal-oidc.company.com", "ca-cert": "/etc/ssl/private/root-ca.pem", "enable-spire-integration": true }
上述配置启用了企业内部OIDC服务作为身份源，并集成了SPIRE以实现工作负载身份认证，确保只有授权服务才能申请证书。
网络与访问控制策略
| 组件 | 监听端口 | 访问控制策略 |
|---|
| Fulcio | 443 | 仅限Service Mesh内部调用 |
| Rekor | 8080 | 审计组只读API密钥访问 |
4.3 SBOM签名与验证：将软件物料清单纳入可信链条
在现代软件供应链中，SBOM（Software Bill of Materials）作为组件透明化的基础，其完整性与来源真实性至关重要。通过数字签名机制，可将SBOM纳入可信验证链条，防止篡改与伪造。
签名生成流程
使用私钥对SBOM的哈希值进行签名，确保内容不可抵赖：
# 生成SBOM文件的SHA256摘要 openssl dgst -sha256 -sign private.key -out sbom.sig sbom.json
该命令利用OpenSSL对
sbom.json生成数字签名，
private.key为开发者私钥，输出签名文件
sbom.sig。
验证机制实现
接收方使用公钥验证签名一致性：
openssl dgst -sha256 -verify public.pem -signature sbom.sig sbom.json
若输出"Verified OK"，则表明SBOM未被篡改且来自可信持有者。
- 签名确保SBOM完整性与来源认证
- 公钥基础设施（PKI）支撑信任传递
- 自动化验证可集成至CI/CD流水线
4.4 防御中间人攻击：利用时间戳与透明日志增强抗抵赖能力
在通信安全中，中间人攻击（MitM）常通过篡改或重放消息破坏数据完整性。引入时间戳可有效防御重放攻击，确保消息的时效性。
时间戳验证机制
客户端与服务器需同步可信时间源，并在消息中嵌入时间戳：
type SignedMessage struct { Payload []byte // 原始数据 Timestamp int64 // Unix 时间戳（秒） Signature []byte // 签名值 }
接收方验证时，检查时间戳是否在允许的时间窗口内（如±5分钟），防止旧消息被重复使用。
透明日志增强审计能力
所有签名操作记录至不可篡改的透明日志系统，形成公开可验证的操作链。这提升了系统的抗抵赖性。
- 每条日志包含哈希链指向前一条记录
- 第三方可独立审计日志完整性
- 异常行为可被及时发现并追溯
第五章：迈向无密钥未来的软件供应链安全新范式
零信任架构下的身份认证革新
传统基于静态密钥的身份验证机制在云原生环境中日益暴露其脆弱性。攻击者一旦获取密钥，即可伪装成合法服务进行横向移动。新兴的无密钥（Keyless）模式通过将身份绑定至不可复制的运行时上下文，如硬件安全模块（HSM）或可信执行环境（TEE），实现动态凭证生成。
实战案例：GitHub Actions 与 OIDC 集成
现代 CI/CD 流水线正逐步淘汰长期存在的访问令牌。以 GitHub Actions 为例，可通过 OpenID Connect（OIDC）向云平台（如 AWS）请求临时凭证：
jobs: deploy: runs-on: ubuntu-latest steps: - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@v2 with: role-to-assume: arn:aws:iam::123456789012:role/github-action-role provider: oidc role-session-name: github-action-session
该配置使工作流直接从 GitHub 的 OIDC 提供商获取短期 STS 令牌，无需存储任何密钥。
主流云平台支持对比
| 云服务商 | 支持协议 | 集成工具示例 |
|---|
| AWS | OIDC + IAM Roles | GitHub Actions, Jenkins |
| Google Cloud | Workload Identity Federation | Cloud Build, Terraform |
| Azure | Azure AD Workload ID | GitHub, Azure Pipelines |
实施路径建议
- 审计现有 CI/CD 中所有长期密钥的使用场景
- 启用云平台的联合身份功能并配置信任关系
- 重构部署脚本以使用临时凭证注入机制
- 结合 Sigstore 实现构建产物的无密钥签名与验证
