Abstract
Software supply chain attacks - SolarWinds in 2020, the XZ Utils backdoor in 2024, and a steady stream of malicious package substitutions across npm, PyPI, and RubyGems - have pushed build provenance from a research topic to a production engineering requirement. The Sigstore project and Google’s SLSA (Supply chain Levels for Software Artifacts) framework together provide a practical, interoperable foundation for artifact signing and provenance attestation. By early 2026, both have reached stable specifications and significant ecosystem adoption, making this a tractable problem for teams willing to invest in build pipeline changes.
Sigstore’s Signing Model
Sigstore’s core insight is that the hardest part of code signing is key management. Its solution is ephemeral signing keys tied to OIDC identity tokens: a developer authenticates with their GitHub, Google, or Microsoft identity; Sigstore’s Fulcio CA issues a short-lived signing certificate binding that identity to an ephemeral key pair; the artifact is signed; and a transparency log entry is recorded in Rekor. The private key is discarded immediately after signing. Verification later requires only the artifact, the Rekor log entry, and the signer’s identity - not a long-lived private key that could be stolen or rotated incorrectly. For container images, cosign handles this transparently and integrates with OCI registries. For packages, sigstore-python and the Python Packaging Authority’s adoption of Sigstore attestations in PyPI (rolled out in stages through 2024-2025) bring the same model to Python dependencies.
SLSA Provenance and Level Requirements
SLSA defines four levels of supply chain assurance, each requiring increasingly strong controls on how artifacts are built and who can influence the build. SLSA Level 1 requires machine-readable provenance; Level 2 requires the provenance to be signed and the build to run on a hosted service; Level 3 requires the build service to be hardened against modification by the source repository’s maintainers (using isolated, ephemeral build environments). GitHub Actions, Google Cloud Build, and GitLab CI now all offer SLSA Level 3 build configurations via their SLSA generator actions and attestation APIs. The provenance document itself is a JSON-LD attestation conforming to the in-toto Attestation Framework, identifying the source commit, build inputs, builder identity, and a digest of the output artifact. Kubernetes admission controllers can verify SLSA provenance before allowing image deployment, closing the last gap between artifact integrity and runtime enforcement.
Adoption Gaps and Practical Advice
As of early 2026, the main gap is dependency provenance rather than first-party artifact signing. Organizations can sign their own artifacts easily, but verifying that every transitive npm or Maven dependency has valid provenance is not yet tractable at scale. The SBOM (Software Bill of Materials) mandates from US Executive Order 14028 and the EU Cyber Resilience Act have accelerated SBOM generation tooling, but SBOM content and SLSA provenance remain only loosely connected in most toolchains. Teams should prioritize: sign your own build outputs first, enforce provenance checks on direct dependencies from major registries (npm and PyPI both surface Sigstore attestations in their metadata APIs now), and treat transitive dependency provenance as a medium-term goal rather than a blocker.