Skip to main content
Application Security Standards
Category: Software Supply Chain

Provenance Attestation

Also known as: SLSA Provenance, Build Provenance, Software Provenance Attestation
Simply put

A provenance attestation is a signed, verifiable record that describes how a piece of software was built, including details like what tools, source code, and build steps were used. It helps organizations confirm that a software artifact was produced by a known, expected process and has not been tampered with after the fact. Think of it like a receipt or certificate of origin for software, tracing it back through the supply chain.

Formal definition

A provenance attestation is a structured, cryptographically verifiable claim asserting that a particular build platform produced a specific set of software artifacts through execution of a defined build process. As specified by the SLSA framework, provenance includes metadata such as build timestamps, build parameters, the build environment, and references to source inputs (the buildDefinition), enabling consumers to trace an artifact back through the supply chain and verify that it was produced as expected. Provenance attestations typically conform to the in-toto attestation framework, which provides a standardized specification for generating verifiable claims about software production. It is important to note that provenance verification has well-defined scope boundaries: it can help detect unauthorized modifications to build inputs or unexpected changes in the declared build process, but it does not, even at higher SLSA Build levels, protect against a compromise of the build platform itself. Provenance attestations are most effective at preventing tampering and improving integrity within the boundaries of a trusted build system, rather than guaranteeing the trustworthiness of that system's internal operations.

Why it matters

Software supply chain attacks have become a significant concern for organizations of all sizes. Attackers may attempt to inject malicious code by tampering with build inputs, substituting artifacts after they are built, or manipulating the declared build process. Provenance attestations address these threats by providing a cryptographically signed record that ties a specific artifact back to its source code, build parameters, and build environment, enabling consumers to verify that an artifact was produced through a known, expected process. Without provenance, organizations have limited ability to distinguish a legitimate artifact from one that has been modified or substituted after production.

It is critical to understand the scope boundaries of provenance attestations. While they are effective at detecting unauthorized modifications to build inputs, unexpected changes to the declared build process, or post-build tampering with artifacts, provenance verification does not protect against a compromise of the build platform itself. For example, if an attacker gains control over the build system's internal operations, provenance generated by that compromised system may still appear valid. This distinction is important when threat-modeling sophisticated supply chain attacks: provenance attestations are a powerful layer of defense within the boundaries of a trusted build system, but they are not a guarantee that the build system's own integrity has not been violated.

As software supply chains grow in complexity, involving multiple source repositories, third-party dependencies, and distributed build environments, the ability to trace an artifact's origin becomes essential for risk management. Provenance attestations give security teams, auditors, and consumers a standardized mechanism to evaluate whether software was built as expected, supporting both compliance requirements and operational trust decisions across the supply chain.

Who it's relevant to

DevSecOps and Platform Engineering Teams
These teams are responsible for configuring and maintaining CI/CD pipelines and build infrastructure. Implementing provenance attestation generation at the build platform level is a foundational step in securing the software supply chain, and these teams must understand both the capabilities and the scope boundaries of what provenance can verify.
Application Security Engineers
Security engineers evaluate and enforce controls across the software development lifecycle. Provenance attestations provide a verifiable mechanism for confirming that artifacts were produced through approved build processes, supporting policy enforcement and audit requirements. Understanding the limitations of provenance (for example, that it does not cover build platform compromise) is essential for accurate threat modeling.
Software Consumers and Procurement Teams
Organizations that consume third-party software or open source packages benefit from provenance attestations as a way to evaluate the trustworthiness of artifacts before deploying them. Verifying provenance helps these teams confirm that software was built from expected sources and has not been tampered with after production.
Compliance and Audit Professionals
Provenance attestations support compliance with emerging software supply chain security requirements, such as those outlined in frameworks like SLSA. Auditors can use provenance records to verify that software production processes meet organizational or regulatory standards for integrity and traceability.
Open Source Maintainers and Package Registry Operators
Maintainers and registry operators can adopt provenance attestations to give downstream consumers confidence that published packages were built from the declared source code through a known build process, improving trust across the open source ecosystem.

Inside Provenance Attestation

Builder Identity
The identity of the build system or service that produced the artifact, typically expressed as a URI referencing a specific build platform and its configuration.
Build Instructions Reference
A pointer to the source repository, entry point, and build configuration (such as a workflow file) that defined how the artifact was built.
Source Materials / Dependencies
A listing of input materials, including source code references (often pinned to a specific commit or digest) and dependencies consumed during the build process.
Cryptographic Signature
A digital signature over the attestation, typically produced by the build platform or a signing service, that allows consumers to verify the attestation has not been tampered with and was issued by an expected party.
Build Metadata
Supplementary information such as timestamps, build invocation identifiers, and reproducibility indicators that provide additional context about the build event.
Subject Digests
Cryptographic hashes (e.g., SHA-256) of the output artifacts, binding the provenance statement to specific artifacts so consumers can verify that the attestation applies to the artifact they possess.
Predicate Type and Schema
A typed predicate, commonly following the in-toto attestation framework and SLSA provenance predicate schema, that defines the structure and semantics of the provenance claims.

Common questions

Answers to the questions practitioners most commonly ask about Provenance Attestation.

Does a provenance attestation guarantee that an artifact is free of malicious code?
No. A provenance attestation records metadata about how, where, and by whom an artifact was built, but it does not analyze or verify the content of the artifact itself. It provides a verifiable chain of custody for the build process, which enables consumers to make trust decisions. However, if malicious code is introduced through a compromised build platform, a legitimate dependency, or a tampered source repository in ways that do not violate the attested build process parameters, the provenance attestation alone will not flag the artifact as malicious. Additional controls such as code review, vulnerability scanning, and runtime monitoring remain necessary.
Would provenance attestations have detected or prevented a supply chain compromise like the 2020 SolarWinds attack, where the build platform itself was compromised?
Not necessarily. The SolarWinds compromise involved the injection of malicious code during the build process by an attacker who had compromised the build platform itself. Current provenance frameworks, including SLSA at Build L3, explicitly note that they do not cover compromise of the build platform. A provenance attestation would have accurately recorded that the artifact was produced by the compromised build system, but since the build system itself was the vector, the attestation would not have surfaced the anomaly. Detecting this class of attack typically requires additional controls such as reproducible builds, build platform integrity monitoring, and independent rebuild verification.
What are the practical first steps for implementing provenance attestations in a CI/CD pipeline?
A typical starting point involves selecting a provenance format such as in-toto or SLSA provenance predicates, then integrating attestation generation into existing CI/CD workflows. Many build systems, including GitHub Actions and Google Cloud Build, offer built-in or readily available generators that produce SLSA-compliant provenance at various levels. Teams should begin by generating attestations for their most critical artifacts, establishing a signature and key management strategy (often using Sigstore's keyless signing for reduced operational overhead), and storing attestations in a discoverable location such as an OCI registry or a transparency log.
How should consumers verify provenance attestations, and what are common pitfalls?
Consumers typically verify provenance attestations by checking the cryptographic signature against a trusted public key or certificate authority, then evaluating the attestation's claims against a verification policy (for example, confirming the expected builder identity and source repository). Common pitfalls include failing to pin the expected builder identity (allowing an attacker to substitute a different but validly signed attestation), not verifying the attestation's binding to the specific artifact digest, and accepting attestations without a defined policy, which reduces verification to a signature check with no semantic meaning.
What are the known limitations and false-negative risks when relying on provenance attestations for supply chain security?
Provenance attestations have several scope boundaries that can result in false negatives. They typically cannot detect compromises of the build platform itself, malicious code introduced through legitimately declared dependencies, or source-level attacks where an authorized committer introduces a backdoor. They also do not cover post-build tampering if the distribution channel is compromised and the consumer does not verify the artifact digest against the attestation. In most cases, attestations are only as trustworthy as the build service that produces them, which means trust in the builder's integrity is a prerequisite rather than something the attestation independently establishes.
How do provenance attestations interact with other supply chain security controls such as SBOMs and artifact signing?
Provenance attestations complement but do not replace SBOMs or standalone artifact signatures. An SBOM describes what components are in an artifact, while a provenance attestation describes how the artifact was built. Artifact signing confirms the artifact's integrity and publisher identity but does not capture build process metadata. In a layered supply chain security posture, these controls work together: the provenance attestation establishes build-time context, the SBOM enumerates dependencies for vulnerability management, and artifact signing provides tamper-evidence during distribution. Implementing all three provides deeper coverage, though each has its own scope boundaries and none individually addresses the full range of supply chain threats.

Common misconceptions

Provenance attestation guarantees the artifact is free of vulnerabilities or malicious code.
Provenance attestation documents how and where an artifact was built, not what is inside it. It does not perform vulnerability scanning or code analysis. An artifact can have valid, verified provenance and still contain vulnerabilities or, in the case of a compromised build platform, even malicious modifications.
Verified provenance attestation can detect or prevent a compromise of the build platform itself.
Provenance attestation, even at higher SLSA Build levels, documents claims made by the build platform. If the build platform itself is compromised, the provenance it generates may be technically valid yet describe a build process that was subverted. Provenance verification protects against threats such as artifact tampering after the build or unauthorized builds on unexpected infrastructure, but it does not cover a scenario where the trusted builder itself is compromised.
Simply generating a provenance attestation is sufficient to gain its security benefits.
The security value of provenance attestation depends on consumers actively verifying the attestation signature, checking that the builder identity matches an expected trusted builder, and validating that source references and build parameters conform to an established policy. Without verification and policy enforcement on the consumer side, the attestation provides no meaningful protection.

Best practices

Automate provenance generation within your CI/CD pipeline using build systems that natively support attestation (e.g., GitHub Actions with SLSA generators, Tekton Chains) rather than generating attestations in user-controlled steps where they can be more easily forged.
Verify provenance attestations at every consumption point, including during container image pulls, package installations, and deployment gates, using tools such as cosign, slsa-verifier, or policy engines like OPA and Kyverno.
Define and enforce explicit verification policies that check builder identity, source repository, and build configuration against an allowlist rather than accepting any valid signature.
Store provenance attestations alongside or linked to their artifacts in a discoverable manner, such as in OCI registries (using referrers API or tags), transparency logs, or dedicated attestation storage, so that consumers can reliably retrieve them.
Pin provenance verification to artifact digests rather than mutable references like tags or version strings, ensuring that the attestation is bound to the exact artifact being consumed.
Recognize the scope boundaries of provenance attestation: it addresses supply chain integrity questions about build origin and process, but should be combined with complementary controls (vulnerability scanning, SBOM analysis, runtime monitoring) to cover threat models that provenance alone cannot address, such as build platform compromise or vulnerabilities in source code.