last update
Jun 24, 2026
license
MITv1.0.0
format
SKILL.md
- Install
// Downloads SKILL.md into ~/.claude/skills/sigstore-slsa-provenance/
$ curl -fsSL --create-dirs -o ~/.claude/skills/sigstore-slsa-provenance/SKILL.md https://claudeskil.com/skills/sigstore-slsa-provenance/SKILL.md - Invoke
// Inside Claude Code, type the skill name as a slash command
> /sigstore-slsa-provenance wire up a GitHub Actions deploy - Or just ask
// Claude loads the skill by itself when a request matches its description
> wire up a GitHub Actions deploy
- name:
- Sigstore SLSA Provenance
- slug:
- sigstore-slsa-provenance
- version:
- v1.0.0
- license:
- MIT
- author:
- @chiragthummar16
- categories:
- tags:
- #sigstore#cosign#slsa#supply-chain#in-toto
- description:
Keyless cosign signing, SLSA Build L3 provenance, and in-toto attestation verification at admission for CRA compliance.
README.md
Sigstore SLSA Provenance
Keyless signing, attestation, and verification for your container and artifact supply chain, built on Sigstore and the SLSA framework. This skill wires cosign keyless signing, SLSA Build L3 provenance generation, and in-toto attestation checks into your CI and admission flow so every image you ship carries a verifiable, transparency-logged chain of custody. It's aimed at platform and DevSecOps engineers who need to satisfy the EU Cyber Resilience Act (CRA), executive-order SBOM mandates, or internal "no unsigned images in prod" policies.
When to use it
- You publish OCI images or release artifacts from GitHub Actions and want signatures without managing long-lived private keys.
- An auditor or the CRA requires you to demonstrate build provenance and SBOM attestations per release.
- You want a Kubernetes admission gate that rejects images lacking valid Sigstore signatures or SLSA provenance.
- You're migrating off GPG-based release signing toward keyless, OIDC-driven workflows.
How it works
Signing is keyless: cosign sign requests a short-lived (~10 min) code-signing cert from Fulcio, bound to the OIDC identity of the workflow (in GitHub Actions, the ambient id-token: write token). The signature and cert are recorded in the Rekor transparency log, so no key material is stored. For supply-chain metadata, cosign attest --type spdxjson (or cyclonedx) wraps an SBOM as a DSSE-enveloped in-toto attestation.
SLSA Build L3 provenance comes from the slsa-github-generator reusable workflows (e.g. generator_container_slsa3.yml), which run in an isolated builder and emit a signed provenance predicate. Verification uses cosign verify / cosign verify-attestation with --certificate-identity-regexp and --certificate-oidc-issuer, or slsa-verifier verify-image to assert builder identity and source repo.
Usage
curl -fsSL --create-dirs -o ~/.claude/skills/sigstore-slsa-provenance/SKILL.md https://claudeskil.com/skills/sigstore-slsa-provenance/SKILL.md
# In CI (GitHub Actions job needs: id-token: write, packages: write)
cosign sign --yes ghcr.io/acme/api@${DIGEST}
cosign attest --yes --type spdxjson \
--predicate sbom.spdx.json ghcr.io/acme/api@${DIGEST}
# At admission / pre-deploy
cosign verify ghcr.io/acme/api@${DIGEST} \
--certificate-identity-regexp '^https://github.com/acme/.+' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com
slsa-verifier verify-image ghcr.io/acme/api@${DIGEST} \
--source-uri github.com/acme/api --builder-id 'https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v2.0.0'
Tips & gotchas
- Always sign and verify by digest, never by tag — tags are mutable and a verified tag tells you nothing about what's running.
verifywithout--certificate-identity*flags will pass any valid Fulcio cert; pin the identity regexp and issuer or the check is cosmetic.- For air-gapped or self-hosted Sigstore, point cosign at your own Fulcio/Rekor via
--fulcio-url/--rekor-urland a TUF root; the public Good instance won't be reachable. - SLSA L3 requires the isolated reusable workflow — provenance generated in your own job tops out at L2.
FAQ
Do I need to store a private key? No. Keyless signing derives ephemeral keys from your OIDC identity; only the Rekor log entry persists.
Can policy controllers consume this? Yes — Kyverno and the Sigstore Policy Controller both verify cosign signatures and in-toto attestations at admission.
SPDX or CycloneDX? Either; cosign attest --type supports both, and verifiers extract the predicate by type.
$ cat reviews/