SLSA Framework Explained: Build Provenance, Levels, and Attestation

What SLSA Actually Is

SLSA stands for Supply chain Levels for Software Artifacts. It is a security framework governed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, originally seeded by work at Google and now maintained as a community specification at slsa.dev. The framework is structured around a small number of objectives (build integrity, source integrity, dependency integrity), a graded set of levels for each objective (the Build track currently runs L1 to L3, with L4 documented as a future target), and a precise vocabulary for the artefacts that the levels expect (provenance, attestation, build platform, signing). The current published specification is SLSA 1.0 for the Build track, with the Source and Dependencies tracks documented as forthcoming.

SLSA is a producer-and-consumer framework. The producer is the organisation that builds and ships software; the consumer is the downstream user that receives it. Each level specifies what the producer must do to claim the level and what the consumer can verify when they receive an artefact. SLSA is not a checklist of engineering practices (SSDF covers that), it is not an inventory of components (SBOM covers that), and it is not a per-CVE exploitability statement (VEX covers that). SLSA is the build-platform discipline that makes the other three trustworthy.

The framework matters because the central trust assumption of every modern software programme is that the artefact running in production was built from the source the developer reviewed. Without provenance, that assumption is unverifiable. Recent high-profile supply chain incidents (SolarWinds, the XZ Utils backdoor, the 3CX desktop client compromise, multiple npm typosquatting and dependency-confusion events) all involved a divergence between the source the maintainer reviewed and the artefact the customer received. SLSA makes that divergence detectable.

SLSA vs SBOM vs VEX vs SSDF

Programmes adopting SLSA almost always adopt SBOM, VEX, and SSDF in the same window, and the four are easy to conflate. Each answers a different question, and each produces a different artefact. Read together they describe the supply-chain posture; read separately they each cover one slice.

Read together, the four artefacts are: an SBOM that lists components, a VEX statement that filters the SBOM-derived CVEs by exploitability, a SLSA provenance attestation that proves the build was trustworthy, and an SSDF programme document that describes the practices the producer follows. The CISA Secure Software Development Attestation (the federal self-attestation form) reads against SSDF, but a producer who has invested in SLSA holds materially better evidence when an auditor or federal customer asks how PS.1 and PS.2 are operationalised.

The SLSA Threat Model

SLSA is built around a documented threat model that names the points where an attacker can compromise the path between source and artefact. Reading the threat model first is the fastest way to understand why each level exists and what it buys you.

The framework does not claim to eliminate every supply-chain threat. It claims to make the build path between source and artefact verifiable, with successively stronger guarantees as the level rises. Programmes designing for SLSA need to be honest about which threats the chosen level addresses and which threats sit outside the framework.

The Four Build Track Levels

The SLSA Build track defines three production levels (L1, L2, L3) plus a documented future L4 target. Each level adds requirements on top of the previous level and closes a larger share of build-integrity threats.

Most production programmes target L2 as the realistic near-term goal and L3 as the multi-quarter goal. L1 is the entry point that gets the provenance discipline into the release process. Treating L4 as the planning target is a common mistake; the specification itself does not yet pin the exact requirements.

In-Toto and the Provenance Format

SLSA provenance is expressed in the in-toto attestation format. In-toto is a separate specification (governed by the Cloud Native Computing Foundation) that defines a generic attestation envelope: a producer (the build platform), a statement (a structured claim about a subject), and a signature. SLSA is the specific predicate type that names the build details (source, configuration, dependencies, materials, output digest). When you read the SLSA specification, the structure of the JSON document you produce is in-toto; the field-level meaning of the predicate is SLSA.

The provenance document carries: the buildType (a URI naming the build platform and entry point), the externalParameters (the inputs the user supplied to the build, such as source repository, branch, commit), the systemParameters (the inputs the build platform contributed, such as platform image, runner version), the resolved dependencies (every artefact the build pulled in), the materials (the inputs the build consumed, such as source archives), and the subject (the artefact digest the build produced). A SLSA-compliant verifier reads the document, checks the signature, and confirms the artefact digest matches the claim.

For a producer, the practical consequence is that the in-toto plus SLSA stack is the file format the build platform writes per release. For a consumer, it is the file format the verifier reads to make a trust decision. The format is intentionally generic so multiple build platforms can produce attestations a single verifier can consume; the alternative was a proliferation of platform-specific provenance formats that no one would standardise on.

Sigstore and Keyless Signing

SLSA L2 and L3 require signed provenance. The historical objection to signed provenance was that signing keys are themselves a target: if the signing key is stolen, the attacker can sign forged provenance. Sigstore is the OpenSSF-governed project that addresses the key-management problem with a keyless signing model anchored on short-lived certificates from a public certificate authority.

The sigstore stack has three components. Cosign is the signing client used to sign and verify artefacts. Fulcio is the certificate authority that issues short-lived (ten-minute) certificates bound to an OIDC identity, so the workflow signing the artefact is provably the workflow you ran on the named build platform. Rekor is the public transparency log that records every signature, so a forged signature would be detectable in the public log.

For a programme adopting SLSA, sigstore matters because it removes the long-lived signing key from the threat model. Signatures are bound to OIDC workload identity (a GitHub Actions workflow, a GitLab CI job, a Kubernetes service account) rather than to a stored key. The reference SLSA Build L3 generators for GitHub Actions already produce sigstore-signed in-toto provenance with a single workflow line; the adoption cost has dropped substantially in the last two SLSA releases.

Sigstore is not the only signing model SLSA accepts, and the specification does not require sigstore. Programmes operating in air-gapped or sovereign-cloud environments often use platform-provided signing keys protected by a hardware security module instead. The threat model is the same: provenance must be signed, the signing must be tied to an identity the consumer can verify, and the signature must be tamper-evident.

Producer Expectations at Each Level

For each level the producer is expected to do specific work. The work is cumulative; L3 producers also do everything L1 and L2 producers do. The list below is the practical work an internal programme will plan against.

Consumer Expectations at Each Level

The framework specifies what a consumer of a SLSA-compliant artefact can verify and what trust assumptions the consumer makes implicit. The consumer side is just as load-bearing as the producer side; provenance that no one verifies is theatre.

At L1, the consumer can read the provenance to learn how the artefact was built. The provenance is unsigned, so the trust assumption is that the producer is honest. L1 is useful for incident-response forensics and for transparency, but it does not close any swap-in-flight threats.

At L2, the consumer can verify the signature on the provenance and confirm the artefact digest matches the claim. The trust assumption shifts from the producer being honest to the build platform being uncompromised. L2 closes the trivial tampering threat (a man-in-the-middle that swaps the artefact will fail signature verification), but a determined attacker who compromises the build platform itself can still forge provenance.

At L3, the consumer trust assumption shifts to the build platform itself enforcing isolation between builds. A user with full access to the build configuration cannot forge provenance for a different artefact, because the signing happens at the platform layer the user cannot reach. L3 is the level where signed provenance becomes meaningfully tamper-evident in the realistic adversary model.

SLSA, EO 14028, and the CISA Secure Software Development Attestation

US Executive Order 14028 (Improving the Nation's Cybersecurity) directed the federal government to require attestations from software producers selling to federal agencies. CISA operationalised the requirement through the Secure Software Development Attestation Form, which reads against the NIST SSDF (SP 800-218). The attestation does not call out SLSA by name, but several of the required SSDF practices are most cleanly evidenced through SLSA artefacts.

PS.1 (Protect code from unauthorised access and tampering) is most cleanly evidenced through L2-or-higher signed provenance plus the build configuration review history. PS.2 (Provide a mechanism for verifying software release integrity) is precisely what signed provenance plus published verification instructions delivers. PS.3 (Archive each release) is satisfied by retaining the in-toto attestation alongside the release artefact. A producer attesting against SSDF who has invested in SLSA holds materially stronger evidence than one who has not.

The CISA Secure by Design pledge separately describes seven goals manufacturers commit to. Goal 4 (Enable Secure-By-Default) and Goal 5 (Reduce hardening requirements) are not directly SLSA goals, but Goal 6 (Provide complete CVE records) and the broader transparency narrative read directly against the provenance-plus-SBOM-plus-VEX evidence stack a SLSA programme produces. See our CISA Secure by Design framework page for the principles and pledge mechanics, and our NIST SSDF implementation guide for the SSDF practice walkthrough that the federal attestation reads against.

For the form-level walkthrough, the four practice clusters the federal form condenses out of SSDF, the role of POAMs and 3PAOs, the renewal cycle, and the False Claims Act exposure on the signing officer, see the CISA SSDA form guide. SLSA provenance lands in the SSDA provenance cluster as the strongest available evidence for PS.1 and PS.3.

Where SLSA Meets the Vulnerability Management Programme

SLSA is normally framed as an AppSec or product-security framework, but the vulnerability management function gains real operating value from SLSA-compliant provenance. The connection is the build identity: every finding the programme tracks lives against a specific artefact, and the artefact provenance pins the artefact to a specific source commit and build configuration. When a CVE lands against a dependency, the question is which artefacts in production contain the vulnerable dependency. With SBOM the question is answerable; with SLSA provenance the answer is verifiable.

The same pattern applies to remediation tracking. A finding closed by upgrading a dependency is properly closed when the next release artefact is built from the updated source under the same provenance attestation. Without provenance, the programme has to take the engineering team's word that the upgraded artefact shipped; with provenance, the verification is mechanical. Pair this with the remediation tracking workflow and the vulnerability prioritisation workflow so the close-on-evidence discipline ties to a verifiable build identity.

For findings produced by code scanning (SAST and SCA), the provenance attestation is the link between the source the scanner analysed and the artefact the build produced. A finding from a SAST run against the source commit recorded in the provenance applies to every artefact built from that commit, and the cross-build traceability lets the programme avoid re-scanning artefacts that share a provenance ancestor.

A Pragmatic SLSA Rollout Plan

Most internal programmes find SLSA easier to adopt than the specification length suggests, provided the rollout is sequenced. The rollout below is the practical order most teams follow, mapped to typical quarterly planning.

SLSA Audit Evidence: What an Assessor Wants to See

For a SOC 2, ISO 27001, federal procurement, or customer security questionnaire review that touches supply-chain integrity, the evidence set below is the minimum an assessor will read against. Build the set as a side effect of the rollout above and the audit collapses into a query rather than a multi-team scramble.

• The signed in-toto SLSA provenance attestation for each shipping release, retained for the period the producer policy specifies.
• The build platform configuration and the named entry point that produced the release, version-controlled alongside the source.
• The verification record showing the release pipeline rejected unsigned or mismatched artefacts, captured in the build platform's native audit trail.
• The SBOM (SPDX or CycloneDX) for each release, referenced from the provenance and stored alongside it.
• The VEX statements published against the SBOM, dated and tied to the release identifier.
• The SSDF programme document that names the practices PS.1, PS.2, PS.3 are evidenced against, and the dated cross-reference between the SSDF practices and the SLSA artefacts.
• The CISA Secure Software Development Attestation form (where federal sales apply), referencing the SSDF and SLSA evidence above.
• The dated record of any SLSA level upgrade, including which pipelines moved and what the verifier confirmed.

The evidence pack is portable across audits because the artefacts themselves are standards-based. A consumer writing a customer security questionnaire can ask for the provenance attestation directly; a federal customer can read it against the SSDF attestation; an ISO 27001 auditor can read it against A 8.28, A 8.29, A 8.30, and the wider supply-chain control set.

Common SLSA Failure Modes

Where SLSA Sits in the Wider Internal Programme

SLSA is owned in different parts of an internal security organisation depending on where the build platform sits. Different audiences read SLSA differently and need different surfaces.

For the AppSec function that owns the secure-coding curriculum, the SAST stack, and the developer-facing security narrative, SecPortal for AppSec teams covers how SLSA-derived build identity feeds the cross-finding traceability the AppSec dashboard depends on. For the product security function that owns the per-release security posture and the customer attestation, SecPortal for product security teams covers how the provenance plus SBOM plus VEX trio feeds the customer-facing evidence pack. For the vulnerability management function that runs the find-track-fix-verify queue, SecPortal for vulnerability management teams covers how the provenance attestation pins findings to specific artefacts. For the CISO sponsoring the programme, SecPortal for CISOs covers how SLSA outcomes roll into leadership reporting. For the GRC owner translating SLSA into evidence, SecPortal for GRC and compliance teams covers the audit-side discipline that turns the artefacts into a portable evidence pack. For the security engineering function that builds the platform patterns SLSA depends on, SecPortal for security engineering teams covers the platform-side investment that operating SLSA requires.

Pair the SLSA programme with adjacent enterprise reading. The SAST vs SCA code scanning guide covers the source-side analysis that runs before the build SLSA validates. The secure code review checklist covers the developer-side discipline upstream of SLSA. The DevSecOps enterprise guide covers the wider pipeline-and-platform discipline that SLSA plugs into. The SDLC vulnerability handoff use case covers the lifecycle-layer routing across SDLC stage gates that pairs with provenance-anchored release identity.

Run a SLSA-Aware Programme on a Single Record

SLSA is not a SecPortal feature. The provenance attestations are produced by the build platform, signed by sigstore or a platform-controlled signing key, and verified by the SLSA verifier. SecPortal does not generate SLSA provenance, sign in-toto attestations, or run sigstore signing on its own. What SecPortal does is keep the SLSA-related operating record alongside the rest of the security programme so the AppSec, product security, vulnerability management, and GRC functions all read from the same source.

The relevant SecPortal capabilities pair with SLSA evidence as follows. Repository connections (GitHub, GitLab, Bitbucket, Azure DevOps via OAuth) put the source side of the build path on the same record as the security findings the build produces. Code scanning via Semgrep SAST and SCA scans the source the build will compile, so the findings travel with the source identity that ends up in the provenance. Findings management with CVSS 3.1 vector and structured fields lets the team tag findings with the release identifier the provenance pins. Document management holds the SSDF programme document, the release-level SBOM, the VEX statements, and the in-toto attestations as supporting evidence on the engagement record. Activity log keeps the timestamped chain of state changes by user across findings, engagements, and documents, with plan retention of 30, 90, or 365 days. Compliance tracking maps findings and controls to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST and exports the evidence pack as CSV. AI report generation derives the executive summary when leadership wants the leadership-level read of the supply-chain posture.

None of these features generate SLSA provenance, sign sigstore attestations, run in-toto verification, or replace the build platform's native signing. The attestation work happens on the build platform; SecPortal provides the operating record that the AppSec, product security, vulnerability management, and GRC functions all read against the same source the build produces.

Wider Reading

SLSA intersects with several other parts of the supply-chain and AppSec programme. The following pages cover the adjacent disciplines from different angles and feed back into the SLSA workflow.

• SBOM guide for the component inventory artefact that pairs with the SLSA provenance per release.
• VEX guide for the exploitability assertion that filters SBOM-derived CVEs in the SLSA-anchored release.
• NIST SSDF implementation guide for the practice framework that PS.1, PS.2, and PS.3 sit in and that SLSA operationalises.
• CWE explained for the classification layer that feeds the cross-finding view inside the SLSA-anchored release.
• CVE Numbering Authority explained for the upstream identifier-issuance layer that mints the CVE IDs SLSA-anchored advisory references cite, and the CNA scope a vendor product organisation works within when publishing supply-chain advisories alongside SLSA provenance.
• Threat modelling guide for the upstream design step that names the supply-chain threats SLSA addresses.
• Security champions program guide for the engineering-side programme that owns the build-platform discipline SLSA depends on.
• DevSecOps scanning use case for the CI-side scanner integration that runs before the SLSA-tracked build.
• SDLC vulnerability handoff for the lifecycle-layer routing across stage gates that pairs with the provenance-anchored release identity.
• Security tool coverage overlap research for the catalogue-level coverage map that names where build-time provenance sits next to runtime scanning categories.
• ISO 27001, SOC 2, NIST, NIST CSF 2.0, and CISA Secure by Design for the framework-side mapping that SLSA-derived evidence flows into. The Secure by Design pledge transparency narrative reads directly against the provenance plus SBOM plus VEX evidence stack a SLSA programme produces.