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 ビルド 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 に添付されたアテステーション）。

目標

• OIDC 発行者と証明書アイデンティティを固定して、コンテナイメージ上の鍵不要の cosign 署名を検証する。
• cosign verify-attestation --type slsaprovenance を使って、イメージ上の SLSA 来歴アテステーションを検証する。
• ソースリポジトリとタグを固定して、リリースバイナリの来歴を slsa-verifier verify-artifact で検証する。
• cosign verify-blob-attestation を使って、GitHub のアーティファクトアテステーション／blob バンドルを検証する。
• 検証の成功を CI とアドミッション制御の必須条件にし、SLSA ビルド 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

終了コードが 0 以外、または結果が空の場合は、検証に失敗しています。デプロイしないでください。

ステップ 2：イメージ上の SLSA 来歴アテステーションを検証する

署名は「誰が」署名したかを証明し、来歴アテステーションは「どのように」ビルドされたかを証明します。in-toto の SLSA predicate type を検証します。

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

サポートされている predicate type には、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 バンドルを検証する

actions/attest-build-provenance で署名されたアーティファクトでは、バンドルに新しい Sigstore バンドル形式が使用されます。

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/

検証 ID リファレンス

フィールド	取得元	重要な理由
--certificate-oidc-issuer	OIDC 発行者（例：GitHub Actions）	署名証明書を要求できる主体を制限します
--certificate-identity[-regexp]	ワークフロー ID（SAN）の完全一致／パターン一致	署名したワークフローを制限し、なりすましを防ぎます
--source-uri（slsa-verifier）	想定するソースリポジトリ	アーティファクトが自分のリポジトリから生成されたことを確認します
--source-tag／--source-versioned-tag	想定する git タグ	ロールバック／すり替えを防ぎます
--builder-id	信頼されたビルダーワークフローの参照	偽造不可能な SLSA L3 ビルダーを適用します

検証基準

• cosign と slsa-verifier がインストールされ、バージョンが表示される
• 固定した OIDC 発行者と証明書 ID を指定して、イメージ署名を検証する
• SLSA 来歴アテステーションを検証する（--type slsaprovenance）
• 来歴述語を確認し、ソースリポジトリ／コミット／ビルダーが一致する
• slsa-verifier でリリースバイナリを検証する（source-uri とタグを固定）
• GitHub blob／バンドルアテステーションを検証する
• 検証をフェイルクローズの CI／アドミッションゲートとして組み込む
• 使用する各アーティファクトに SLSA ビルドレベルを割り当てる