verifying-build-provenance-with-slsa-sigstore

使用 SLSA 和 Sigstore 验证构建溯源信息

概述

构建溯源信息验证可以回答一个能挫败许多供应链攻击的问题：这个制品是否确实由我信任的构建器从我认为的源代码构建而成，且未遭篡改？ 攻击者入侵构建系统、替换已编译的发布版本或注入恶意步骤（如 SolarWinds 和 3CX 事件中所发生的那样）后，生成的制品看似合法，却缺少可验证的溯源信息。SLSA（Supply-chain Levels for Software Artifacts，https://slsa.dev）定义了构建等级（L1–L3），用于描述逐步增强的溯源完整性；Sigstore（https://www.sigstore.dev）则提供签名和透明度基础设施：使用 cosign 对制品和证明进行签名与验证，使用 Fulcio 签发与 OIDC 身份绑定的短期无密钥证书，并使用 Rekor 作为防篡改透明度日志。

本技能介绍如何使用 cosign（cosign verify、cosign verify-attestation、cosign verify-blob-attestation）和 slsa-verifier（slsa-verifier verify-artifact）验证签名和 SLSA 溯源信息，并强制验证构建器身份（生成制品的 GitHub Actions 工作流）和预期的源代码仓库。无密钥验证会将信任关联到 OIDC 颁发者（例如 https://token.actions.githubusercontent.com）和证书身份，而不是长期有效的私钥。

这对应于 MITRE ATT&CK T1195 — 供应链入侵（溯源验证可检测并阻止遭篡改的制品）和 NIST CSF PR.DS-01（保护静态数据的机密性、完整性和可用性；CSF 2.0 将已弃用的 1.1 版 PR.DS-06 完整性检查结果纳入此项）。

适用场景

• 在 CI/CD 中，于部署或提升任何容器镜像或发布二进制文件之前。
• 使用会发布证明的第三方制品（基础镜像、Go/npm 发布版本）时。
• 建立 SLSA Build L3 生产者流水线，并在使用者端强制执行时。
• 事件响应期间，确认已部署制品的溯源信息是否完整。
• 在准入控制中（例如，通过 policy-controller / Kyverno 在 Kubernetes 中），仅准入经过验证的镜像。

先决条件

• cosign（Sigstore CLI）：

  go install github.com/sigstore/cosign/v2/cmd/cosign@latest
  # or download a release binary from https://github.com/sigstore/cosign/releases
  

• slsa-verifier：

  go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@latest
  # or:
  curl -sSL https://github.com/slsa-framework/slsa-verifier/releases/latest/download/slsa-verifier-linux-amd64 \
    -o /usr/local/bin/slsa-verifier && chmod +x /usr/local/bin/slsa-verifier
  

• 可访问 Rekor（https://rekor.sigstore.dev）和 Fulcio 的网络，以验证透明度日志。
• 制品及其溯源信息/证明捆绑包（.sigstore、.intoto.jsonl 或附加的 OCI 证明）。

目标

• 验证容器镜像上的无密钥 cosign 签名，并固定 OIDC 颁发者和证书身份。
• 使用 cosign verify-attestation --type slsaprovenance 验证镜像上的 SLSA 溯源证明。
• 使用 slsa-verifier verify-artifact 验证发布二进制文件的溯源信息，并固定源代码仓库和标签。
• 使用 cosign verify-blob-attestation 验证 GitHub 制品证明 / blob 捆绑包。
• 根据验证是否成功设置 CI 和准入控制门槛；了解 SLSA Build L1–L3。

MITRE ATT&CK 映射

ID	策略	技术名称	相关性
T1195	初始访问	供应链入侵	验证溯源信息和签名可以检测构建/分发链中遭篡改或替换的制品，防止供应链入侵影响部署。

工作流

步骤 1：验证镜像上的无密钥 cosign 签名

固定 OIDC 颁发者和证书身份（即签名所用工作流的确切身份）。不固定身份而直接运行 cosign verify 毫无意义——任何人都可以签名。

cosign verify \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp "^https://github.com/myorg/myrepo/.github/workflows/.*@refs/tags/v.*" \
  ghcr.io/myorg/myrepo:v1.2.3

退出状态非零或结果为空表示验证失败——不要部署。

步骤 2：验证镜像上的 SLSA 溯源证明

签名证明了谁进行了签名；溯源证明则证明了如何构建。验证 in-toto SLSA 谓词类型。

cosign verify-attestation \
  --type slsaprovenance \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity "https://github.com/myorg/myrepo/.github/workflows/build-sign.yml@refs/heads/main" \
  ghcr.io/myorg/myrepo:v1.2.3

支持的谓词类型包括 slsaprovenance、slsaprovenance02 和 slsaprovenance1。

步骤 3：检查来源谓词

解码已验证的证明，确认源代码仓库、提交和构建器符合预期。

cosign verify-attestation --type slsaprovenance \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp '.*' \
  ghcr.io/myorg/myrepo:v1.2.3 \
  | jq -r '.payload' | base64 -d | jq '.predicate.buildDefinition.externalParameters, .predicate.runDetails.builder.id'

步骤 4：使用 slsa-verifier 验证发布二进制文件

对于可下载的二进制文件（例如由 slsa-github-generator 生成的文件），固定源 URI 和标签。slsa-verifier 会检查来源证明上的加密签名，以及生成该文件的构建器是否符合预期。

slsa-verifier verify-artifact slsa-test-linux-amd64 \
  --provenance-path slsa-test-linux-amd64.intoto.jsonl \
  --source-uri github.com/myorg/myrepo \
  --source-tag v1.2.3

# Optionally pin the builder identity (SLSA L3)
slsa-verifier verify-artifact ./mybin \
  --provenance-path ./mybin.intoto.jsonl \
  --source-uri github.com/myorg/myrepo \
  --builder-id https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v2.0.0

步骤 5：验证 GitHub 工件证明／Blob Bundle

对于通过 actions/attest-build-provenance 签名的工件，Bundle 使用新的 Sigstore Bundle 格式。

cosign verify-blob-attestation \
  --bundle ./myartifact.sigstore.json \
  --new-bundle-format \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp="^https://github.com/myorg/myrepo/" \
  ./myartifact

# Equivalent native GitHub CLI verification
gh attestation verify ./myartifact --repo myorg/myrepo

步骤 6：将验证设为强制关卡

封装验证流程，确保任何错误都会导致流水线失败。

#!/usr/bin/env bash
set -euo pipefail
IMG="ghcr.io/myorg/myrepo:v1.2.3"
cosign verify \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp "^https://github.com/myorg/myrepo/" "$IMG" >/dev/null
cosign verify-attestation --type slsaprovenance \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp "^https://github.com/myorg/myrepo/" "$IMG" >/dev/null
echo "[+] $IMG verified: signature + SLSA provenance OK"

步骤 7：将发现映射到 SLSA 构建级别

记录每个所用工件达到的级别：

• 构建级别 L1 —— 存在来源证明（由构建流程生成），但它可能未经签名／可伪造。
• 构建级别 L2 —— 来源证明由托管构建服务签名。
• 构建级别 L3 —— 来源证明不可伪造：在隔离、强化的构建器上生成，且用户定义的步骤无法访问机密（例如，slsa-github-generator 可复用工作流）。高信任工件必须达到 L3。

工具和资源

工具／资源	用途	链接
cosign	对工件和证明进行签名／验证（无密钥）	https://github.com/sigstore/cosign
slsa-verifier	验证符合规范的构建器所生成的 SLSA 来源证明	https://github.com/slsa-framework/slsa-verifier
slsa-github-generator	在 GitHub Actions 中生成 SLSA L3 来源证明	https://github.com/slsa-framework/slsa-github-generator
actions/attest-build-provenance	GitHub 原生来源证明认证	https://github.com/actions/attest-build-provenance
SLSA 规范	构建级别和来源证明架构	https://slsa.dev/spec/v1.0/
Sigstore 文档	Fulcio、Rekor、cosign 验证	https://docs.sigstore.dev/cosign/verifying/verify/

验证身份参考

字段	来源	重要性
--certificate-oidc-issuer	OIDC 颁发者（例如，GitHub Actions）	限制能够请求签名证书的主体
--certificate-identity[-regexp]	精确／模式匹配的工作流身份（SAN）	限制能够签名的工作流；防止冒充
--source-uri（slsa-verifier）	预期的源代码仓库	确认工件来自你的仓库
--source-tag / --source-versioned-tag	预期的 git 标签	防止回滚／替换
--builder-id	可信构建器工作流引用	强制使用 SLSA L3 不可伪造的构建器

验证标准

• 已安装 cosign 和 slsa-verifier，并报告其版本
• 已使用固定的 OIDC 颁发者和证书身份验证镜像签名
• 已验证 SLSA 来源证明认证（--type slsaprovenance）
• 已检查来源证明谓词；源代码仓库／提交／构建器均符合预期
• 已使用 slsa-verifier 验证发布二进制文件（固定 source-uri 和标签）
• 已验证 GitHub Blob／Bundle 证明
• 已将验证接入 CI／准入关卡，确保失败时拒绝通过
• 已为每个所用工件指定 SLSA 构建级别