SLSA: Build Provenance and Source Integrity for Software Supply Chains

The SLSA framework, pronounced "salsa" and short for Supply-chain Levels for Software Artifacts, is an open specification for making sure software has not been tampered with on its way from source code to the package you install. It was started by Google and is now maintained by the Open Source Security Foundation (OpenSSF). SLSA gives producers a set of increasingly strong practices, and gives consumers a way to verify what they receive.

The current version, SLSA v1.2, defines two tracks: the Build track, which covers how artifacts are built and how their provenance is recorded, and the Source track, which covers how source code is controlled and reviewed. This guide explains the threats SLSA addresses, each level, the attestations involved, how to adopt SLSA in a CI/CD pipeline, how consumers verify artifacts, and how SLSA relates to SBOMs, NIST SSDF and the EU Cyber Resilience Act.

What is SLSA?

SLSA is a security framework and checklist of standards and controls to prevent tampering, improve integrity and secure packages and infrastructure. It focuses on the integrity of the supply chain: making sure the artifact you run was built from the source you expect, by the process you expect, without unauthorised changes. It does not, by itself, say whether the code is free of vulnerabilities; that is the job of secure development, testing and vulnerability management.

SLSA is organised into tracks, each with levels that describe increasing security guarantees. Version 1.0 introduced the Build track in 2023; v1.2 added a Source track and remains backwards compatible with v1.1. Separating tracks lets organisations improve build integrity and source integrity independently, and report progress on each without one blocking the other.

The threats SLSA addresses

SLSA's threat model follows the path from a developer's change to a consumer's use of an artifact. Threats include:

• Source threats: submitting unauthorised changes, bypassing code review, compromising the source repository or rewriting history.
• Build threats: building from modified source, compromising the build process, injecting malicious steps, or tampering with outputs after the build.
• Distribution threats: uploading a modified package, compromising the package registry, or tricking users into installing the wrong artifact.
• Dependency threats: using a compromised dependency, which SLSA addresses by applying the framework recursively to dependencies.

High-profile incidents, such as compromised build servers that injected malware into signed updates, showed that protecting source code alone is not enough.

Why build integrity matters

Software supply chain attacks have shown that an attacker does not need to break into every customer; compromising one producer's build or distribution process can reach thousands of organisations at once. Incidents have included malicious code inserted into a vendor's build system so that signed updates carried a backdoor, stolen CI credentials used to publish altered packages, malicious packages uploaded to public registries under names similar to popular ones, and compromised maintainer accounts. In each case, users trusted an artifact because it came from a familiar source. SLSA aims to replace that implicit trust with evidence that can be checked automatically.

Roles in SLSA

SLSA distinguishes between the producer, who creates the software; the build platform, which runs builds and generates provenance; the source control system, which hosts code and enforces controls; and the consumer, who verifies and uses artifacts. Some requirements fall on the producer, such as using a consistent build process, and others on the platform, such as isolating builds and protecting signing keys. This division matters for buyers: choosing a build platform that already meets Build L3 requirements lets producers reach that level without building complex infrastructure themselves.

The Build track

Level	Name	Requirements	Protects against
Build L0	No guarantees	No SLSA requirements.	Nothing; suitable only for development builds.
Build L1	Provenance exists	A consistent build process; the build platform automatically generates provenance describing who built the package, how and from which top-level inputs; provenance is distributed to consumers.	Mistakes and documentation gaps, though provenance can be forged.
Build L2	Hosted build platform	L1 plus builds run on a hosted platform that generates and signs the provenance, which consumers validate.	Tampering after the build.
Build L3	Hardened builds	L2 plus the platform isolates build runs from one another and keeps provenance-signing secrets away from user-defined build steps.	Tampering during the build by insiders, compromised credentials or other tenants.

The Source track

Level	Name	Requirements
Source L1	Version controlled	Source is stored and managed in a modern version control system with discrete revisions that can be referenced precisely.
Source L2	History and provenance	Branch history is continuous, immutable and retained, and the source control system issues source provenance attestations for each new revision.
Source L3	Continuous technical controls	The source control system enforces the organisation's technical controls on protected branches and tags, with evidence that the controls remain in place.
Source L4	Two-party review	Two trusted people must review all changes to protected branches.

Provenance and attestations

Provenance is a verifiable statement about how an artifact was produced: which build platform, which build definition, which source revision and which inputs. SLSA recommends attestation formats based on the in-toto attestation framework. Key types include build provenance, source provenance and the verification summary attestation (VSA), which records that an artifact was verified against a policy and at what SLSA level, so downstream consumers do not have to repeat full verification. Attestations are signed so that consumers can check they came from a trusted build platform or verifier.

How consumers verify artifacts

Verification is what makes SLSA useful. Before using an artifact, a consumer or deployment system:

1. Obtains the artifact's provenance.
2. Checks the provenance signature against the expected build platform's identity.
3. Checks that the provenance matches the artifact's digest.
4. Checks that the builder, source repository, branch or tag and build parameters match expectations.
5. Rejects the artifact if any check fails.

Organisations can enforce verification at deployment, for example through admission policies in Kubernetes that only allow images with valid provenance from approved builders. Package managers and registries are also adding verification features, so developers can check provenance when installing dependencies. Verification policies should be versioned and reviewed like code, because a policy that is too loose gives false confidence.

SLSA for SaaS companies

SLSA is often discussed for open source packages, but it matters for SaaS too. A SaaS company deploys container images and functions built by its own pipelines; if an attacker tampers with the build, every customer is affected. Applying SLSA internally means building every production image in CI with signed provenance, restricting who can change pipeline definitions, protecting branches, and having the deployment system verify provenance before running anything. Enterprise customers increasingly ask about these controls in security questionnaires, and SLSA gives a clear, standard way to answer.

Dependencies and recursive trust

Most software is mostly dependencies. SLSA's levels apply to each artifact independently, so a product at Build L3 can still include a dependency with no provenance. Consumers can raise their assurance by preferring dependencies that publish provenance, verifying it where available, pinning versions by digest, mirroring critical dependencies into controlled registries, and tracking components with an SBOM. Over time, as more package ecosystems support provenance, organisations can set policies that require minimum SLSA levels for critical dependencies.

Hardening CI/CD alongside SLSA

SLSA levels are easier to reach and more meaningful when the pipeline itself is well protected. Useful practices include short-lived credentials for CI jobs using workload identity instead of long-lived secrets, separate permissions for build, sign and publish steps, review requirements for changes to pipeline files, pinning third-party CI actions by commit hash, isolating runners for release builds, and logging every release. These controls reduce the chance that an attacker who gains access to one part of the pipeline can produce a trusted, signed artifact. We set up hardened pipelines with signed provenance and deployment verification as part of our custom software development and SaaS product work.

Benefits and limitations

• Benefits: clear, incremental levels; open and vendor-neutral; strong tooling support; verifiable evidence for customers; and protection against high-impact build and distribution attacks.
• Limitations: does not address vulnerabilities in code; value depends on consumers actually verifying; higher levels depend on platform capabilities; and coverage of dependencies is still uneven across ecosystems.

Is it mandatory or voluntary?

Voluntary. However, customers increasingly ask suppliers how software is built and protected, package ecosystems have added provenance support, and regulations such as the EU Cyber Resilience Act expect manufacturers to manage supply chain risks. SLSA provides a clear way to show what has been done.

How to adopt SLSA, step by step

1. Start at Build L1: build every release through a scripted CI pipeline and generate provenance automatically.
2. Move to Build L2: use a hosted CI platform that signs provenance, and publish it with artifacts.
3. Reach Build L3: use build platforms or reusable workflows that isolate builds and protect signing keys from build steps.
4. Raise source integrity: protect branches, prevent history rewrites, require reviews, and enable source provenance where your platform supports it.
5. Verify on consumption: check provenance in deployment pipelines and for third-party dependencies where available.
6. Document your levels and share them with customers.

Tools and technologies

• CI/CD platforms with built-in provenance generation and artifact attestations.
• OpenSSF SLSA generators and verifiers for common build systems.
• Sigstore tools for keyless signing and transparency logs.
• in-toto attestation libraries.
• Container registries and package managers that store and serve attestations.
• Policy engines for admission control based on provenance.

Communicating SLSA levels to customers

Claims about SLSA should be specific and verifiable. A good statement names the product or artifact, the track and level achieved, the build platform used, where provenance can be found, and how customers can verify it, for example with a named verification tool and the expected builder identity. Avoid claiming a level for the whole company when only some products meet it. Security whitepapers, trust centres and responses to vendor questionnaires are natural places to publish this, alongside SBOM availability and secure development practices.

Documentation you will need

• Build pipeline definitions under version control.
• Provenance and attestations published with releases.
• Branch protection and review policies.
• Verification policies for consumers and deployments.
• Records of build platform configuration and access controls.
• Statements of SLSA levels achieved per product.

Timeline and cost considerations

For teams already using hosted CI, Build L1 and L2 can often be reached in days to weeks by enabling provenance and signing features. Build L3 depends on the build platform; many hosted platforms provide L3-capable reusable workflows. Source levels depend on repository settings and team practices, especially two-party review for Source L4. Costs are mostly engineering time and, in some cases, platform features.

Common mistakes

• Generating provenance but never verifying it.
• Building releases on developer laptops.
• Letting build steps access signing keys.
• Allowing force pushes or admin bypass on protected branches.
• Confusing SLSA with SBOM; they answer different questions.

SLSA, SBOM and SSDF

Framework	Question it answers
SLSA	Was this artifact built from the expected source by the expected process without tampering?
SBOM	What components and dependencies does this software contain?
NIST SSDF	Does the producer follow secure development practices overall?
OWASP SAMM	How mature is the organisation's software security programme?

Used together, they give customers a far more complete picture of software trustworthiness.

Real-world example

An Indian SaaS company that distributes a self-hosted agent to enterprise customers moves its release builds from a shared build server to a hosted CI platform with reusable workflows that meet Build L3. Each release now carries signed provenance and an SBOM. Branch protection requires two reviewers for the main branch, and history rewrites are blocked. Customers' deployment pipelines verify the provenance before installing updates, and the company documents its SLSA levels in its security whitepaper.

Next steps

1. Move all release builds to CI.
2. Enable signed provenance.
3. Protect branches and require reviews.
4. Verify provenance at deployment.
5. Publish your SLSA levels.

Frequently asked questions

What is SLSA?

Supply-chain Levels for Software Artifacts, an OpenSSF specification for preventing tampering between source code and deployed software.

What is the current SLSA version?

SLSA v1.2, which adds the Source track and is backwards compatible with v1.1.

What are the SLSA build levels?

Build L0 no guarantees, L1 provenance exists, L2 hosted build platform, and L3 hardened builds.

What are the SLSA source levels?

Source L1 version controlled, L2 history and provenance, L3 continuous technical controls, and L4 two-party review.

What is build provenance?

A signed, verifiable record of how an artifact was built, from which source and on which platform.

Is SLSA a certification?

No. Producers claim levels supported by attestations that consumers can verify.

How is SLSA different from an SBOM?

An SBOM lists components; SLSA shows how an artifact was built and whether it was tampered with.

Does SLSA find vulnerabilities?

No. It addresses integrity; vulnerability detection needs testing, scanning and secure development.

Who maintains SLSA?

The Open Source Security Foundation, part of the Linux Foundation, through an open community working group that publishes the specification.

Do SaaS companies need SLSA?

It is voluntary, but applying it to internal builds protects every customer from build tampering and answers common security questionnaire items.

What is a verification summary attestation?

A signed record that an artifact was verified against a policy and at what SLSA level, so downstream users can rely on that check.

Does SLSA help with the Cyber Resilience Act?

It helps demonstrate supply chain integrity, which supports the Act's expectations on managing cybersecurity risks across a product's lifecycle.