DevOps Glossary

SLSA Provenance is signed build metadata that records where a software artifact came from, how it was built, and which build system produced it. SLSA stands for Supply-chain Levels for Software Artifacts. In practical terms, SLSA Provenance lets you verify that a container image, binary, package, or library was built from the expected source code by an expected CI/CD system.

What SLSA Provenance does

SLSA Provenance helps teams answer a basic supply chain security question: “Can we trust how this artifact was produced?”

It provides a verifiable record for an artifact, usually tied to the artifact’s cryptographic digest. This record can show:

• Source repository: the Git repository, commit, branch, or tag used for the build.
• Build system: the CI/CD platform or builder that ran the build.
• Build process: the build definition, workflow, command, or pipeline used.
• Inputs: dependencies, base images, scripts, or other materials used during the build.
• Output artifact: the exact binary, package, or image digest produced.
• Signature: proof that the provenance was created by a trusted identity or system.

How it works

A build system generates provenance during or immediately after a build. The provenance is then signed and attached to, stored beside, or published with the artifact.

A typical flow looks like this:

1. A developer merges code into a source repository.
2. A CI/CD system runs a build workflow.
3. The build produces an artifact, such as a container image or binary.
4. The build system generates provenance describing the build.
5. The provenance is signed by the build system or a signing service.
6. A deployment policy, security scanner, or admission controller verifies the signature and metadata before allowing use.

Common implementations use formats and tools such as in-toto attestations, Sigstore, cosign, GitHub Actions provenance, and registry-backed attestations for container images.

What is inside SLSA Provenance

The exact fields depend on the provenance format, but useful SLSA Provenance usually includes:

• Subject: the artifact being described, usually identified by a digest such as SHA-256.
• Builder identity: the CI/CD system, hosted builder, or build service that produced the artifact.
• Build type: the kind of build process used, such as a GitHub Actions workflow or a custom builder.
• Invocation details: build parameters, environment details, workflow references, or trigger information.
• Materials: source commits, dependencies, base images, or other inputs used during the build.
• Signature: a cryptographic signature that lets verifiers detect tampering.

Common use cases

• Release verification: confirm that a production artifact came from the approved repository and release workflow.
• Kubernetes admission control: block unsigned images or images built by untrusted builders before they reach a cluster.
• Incident response: trace which source commit and build pipeline produced a compromised artifact.
• Compliance evidence: prove that production software followed an approved build path.
• Open source package trust: help users verify that a published package was built from the expected public source.

Simple example

A platform team builds a Go service in GitHub Actions and publishes a container image to a registry. The image digest is:

sha256:abc123...

The CI workflow generates SLSA Provenance stating that this image was built from:

• Repository: github.com/example/payments-api
• Commit: 9f3a2c...
• Workflow: .github/workflows/release.yml
• Builder: GitHub Actions hosted runner
• Artifact: image digest sha256:abc123...

Before deployment, a policy checks that the image has valid signed provenance, came from the expected repository, and was built by the approved release workflow. If someone pushes a manually built image with the same tag but a different digest, the policy can reject it.

SLSA Provenance vs SBOM

SLSA Provenance and a Software Bill of Materials are related, but they answer different questions.

• SLSA Provenance: explains how an artifact was built, by whom, from what source, and with which process.
• SBOM: lists the components inside the software, such as libraries, packages, and versions.

For example, SLSA Provenance can show that a container image was built by your trusted release pipeline. An SBOM can show that the same image contains OpenSSL, Alpine Linux packages, and application dependencies. Mature software supply chain programs often use both.

Benefits

• Tamper detection: signed provenance makes it harder to swap artifacts without detection.
• Build traceability: teams can connect production artifacts back to commits, workflows, and builders.
• Policy enforcement: deployment systems can require trusted build paths instead of relying on image tags alone.
• Faster investigations: engineers can identify affected artifacts after a compromised dependency, runner, or repository event.

Limitations and tradeoffs

• Provenance is only as trustworthy as the builder: if the build system is compromised, the metadata may still look valid.
• Verification must be enforced: generating provenance helps little if no system checks it before deployment or release.
• Metadata can expose details: provenance may include repository paths, build parameters, or dependency information that needs access control.
• Adoption requires pipeline work: teams may need to update CI/CD workflows, signing setup, registry storage, and deployment policies.

Related concepts

• SLSA: a framework for improving software supply chain security through stronger source, build, and release controls.
• Attestation: a signed statement about an artifact, such as its provenance, vulnerability scan result, or test result.
• in-toto: a framework and metadata format often used for supply chain attestations.
• Sigstore: a set of tools and services for signing, verifying, and recording software artifacts and attestations.
• Artifact digest: a cryptographic hash that identifies exact artifact content, unlike a mutable tag such as latest.