SLSA (Supply-chain Levels for Software Artifacts): SLSA – Tutorial (about 60 minutes)

SLSA (pronounced "salsa", short for Supply-chain Levels for Software Artifacts) is an open, community-built security framework that describes how to protect the path software takes from a developer's keyboard to the system that runs it. It defines tracks and levels of assurance for source code and for builds, plus a standard way to record and check evidence called provenance. It is used by open-source maintainers, platform and DevOps engineers, security teams and the companies that consume third-party packages. After this tutorial you will be able to explain what each SLSA level guarantees, read and verify provenance, plan a step-by-step adoption and judge the limits of a SLSA claim.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is SLSA v1.2, marked "Approved" on the official specification site slsa.dev and announced by the SLSA project on 24 November 2025. It defines two tracks: the Build Track (levels L0 to L3) and the Source Track (levels L1 to L4, with an implicit level 0). Version 1.2 is backwards compatible with v1.1 (approved April 2025), which in turn refined v1.0 (final in April 2023). A public Working Draft also contains early material for a Build Environment Track and a Dependency Track; that material is not approved and may change, so this course only mentions it as future direction; the draft itself still names v1.2 as the current version. SLSA is developed as a cross-industry community specification within the Open Source Security Foundation (OpenSSF), part of the Linux Foundation, and is published free of charge under the Community Specification License 1.0. Verified 2026-10-29.

Who this is for: software and platform engineers, DevOps and release engineers, security and product-security staff, open-source maintainers, procurement and third-party-risk teams, and auditors who keep hearing "we are SLSA Level 3" and want to know what that really means.

Prerequisites: none. Familiarity with Git and a continuous integration (CI) pipeline helps, and it is enough to know that a digital signature proves who signed something and that it was not changed afterwards.

By the end of this tutorial:

You will be able to explain why software supply chains are attacked and which kinds of attack SLSA helps with, and which it does not.
You will be able to use the core vocabulary: artifact, provenance, attestation, build platform, control plane, external parameters, Source Control System and Verification Summary Attestation.
You will be able to describe every level of the Build Track and the Source Track and what each one adds.
You will be able to outline what producers, build platforms, source platforms and consumers each have to do.
You will be able to walk through how an artifact's provenance is verified against expectations.
You will be able to explain how SLSA claims are assessed, and why there is no official SLSA certificate for organisations.
You will be able to place SLSA next to related frameworks such as the NIST SSDF, in-toto, Sigstore and SBOM formats.

Lesson 1 – Origins, purpose and scope

Why the software supply chain needs protecting

Almost no organisation writes all of its own software. A typical application pulls in hundreds of open-source libraries, is compiled by a CI service, packaged into a container image, uploaded to a registry and finally downloaded by a server or a laptop. Each step is a link in a supply chain, and each link is a place where an attacker can insert something malicious without touching the source code that developers review.

Several well-known incidents made this visible. In the SolarWinds attack, intruders compromised the vendor's build environment, so the official, correctly signed product updates contained a backdoor even though the reviewed source looked clean. In the Codecov incident, an attacker used leaked credentials to modify a script that customers downloaded, so users received something the maintainers never built. In the event-stream case, a popular open-source package was handed to a new maintainer who added a dependency containing hidden code aimed at a cryptocurrency wallet application. None of these attacks required breaking the application's own security features; they abused trust in the path the software travelled.

Traditional security tools look at the content of software: vulnerability scanners, static analysis, code review. They rarely answer a different, equally important question: is this file really what the developers wrote and built, produced in the way we expect? That question is about integrity and origin, and it is the question SLSA was designed to answer.

Where SLSA came from

SLSA was publicly introduced by Google in June 2021 as a proposal for an industry-wide framework, drawing on controls Google had applied internally to its own production software for years. Today it is maintained by contributors from many companies under the OpenSSF, with a steering committee and an open process on GitHub that includes public release candidates and comment periods.

The first public version, v0.1, used a single list of four levels that mixed source, build and other requirements. Feedback showed that this was hard to adopt in steps, because a team could be strong in one area and weak in another. Version 1.0 (April 2023) therefore introduced the idea of separate tracks, and deliberately shipped with only the Build Track, so that the most mature part could stabilise first. Version 1.1 (April 2025) clarified and tidied the build material. Version 1.2 (November 2025) added the Source Track, restructured the documents for multiple tracks and updated the threat model.

What SLSA is

The specification describes itself as a set of guidelines that can be adopted incrementally and that were agreed by industry consensus. It serves two audiences at once:

Producers (people and organisations who create software) use it as a checklist to harden their source and build processes and to publish evidence about them.
Consumers (anyone who installs, deploys or depends on software) use it to decide how much to trust a package and to verify the evidence automatically.

It also provides a shared vocabulary. Instead of vague promises such as "our builds are secure", a producer can state "this artifact meets SLSA Build L3", and a consumer can check that claim against signed data.

What SLSA is not

Being clear about scope prevents the most common misunderstandings:

SLSA does not judge code quality. A perfectly SLSA-compliant build can still faithfully produce software full of bugs or vulnerabilities. You still need code review, testing and scanning.
SLSA does not protect you from a producer that is deliberately malicious. If the legitimate owner of a project writes malware, SLSA will truthfully record that the malware was built from their source.
SLSA does not give transitive trust. The level of an artifact says nothing about the levels of the libraries it was built from; each dependency has to be assessed separately.
Some threats are explicitly outside its current scope, such as typosquatting (publishing a package with a name similar to a popular one) and insecure use of software after installation, such as default passwords.

The threat model in one picture

SLSA organises supply-chain threats by where they enter the chain, using the letters A to I. Source threats cover a malicious producer (A), unauthorised changes during authoring and review (B) and compromise of the source code management system (C). Build threats cover artifacts built from something other than the claimed source or parameters (D), compromise of the build process itself (E), uploading an artifact that was never built by the official process (F) and tampering in the distribution channel such as a mirror (G). Usage threats cover choosing the wrong package (H) and using it insecurely (I). Dependency threats are simply the same list applied again to every component you depend on.

Figure 1 – The software supply chain from source to use, with the SLSA threat letters A to I marking where each kind of attack enters.

Roughly speaking, the Source Track addresses B and C, and the Build Track addresses D, E, F and G, provided consumers actually verify the evidence. A, H and I are mostly outside what SLSA can solve on its own.

Guiding principles

Five principles explain many design choices you will meet later:

Simple levels with clear outcomes. Each level should deliver a concrete security benefit and show the next step.
Trust platforms, verify artifacts. Put careful trust in a small number of well-run platforms, such as a build service, and then check every individual artifact automatically.
Trust code, not individuals. Trace software back to reviewed source instead of relying on whoever has upload rights to a registry.
Prefer attestations over inferences. Ask for explicit, signed evidence of how something was produced rather than guessing from access-control settings, which drift.
Support anonymous and pseudonymous contributions. Stable, strongly authenticated online identities are enough; legal names are not required, which matters for open source.

Lesson 2 – Key concepts and vocabulary

SLSA uses a small set of precise terms. The definitions below are paraphrased in plain language; the specification's own terminology pages are the authoritative source.

Artifact – any immutable file or blob produced or consumed in the chain: a source archive, a compiled binary, a container image, a library package. Artifacts are identified by a cryptographic digest such as a SHA-256 hash.
Package – a named, distributable unit, such as an npm package or a container repository, that has many versions; each version is one or more artifacts. Consumer policies are usually written per package, while evidence is attached per artifact.
Attestation – a signed, machine-readable statement about one or more artifacts. SLSA uses the in-toto attestation format: a statement containing a subject (the artifacts, by name and digest), a predicate type (what kind of claim this is) and the predicate (the claim itself), wrapped in a signed envelope.
Provenance – an attestation that describes how an artifact was produced: by which platform, from which inputs, with which parameters and when. SLSA defines its own build provenance format, identified by the predicate type https://slsa.dev/provenance/v1.
Build platform – the system that turns source into artifacts, including its hardware, software, operators and any organisation able to influence a build. A hosted CI/CD service is a typical example.
Control plane – the trusted part of a build platform that schedules builds, observes them and generates and signs the provenance. It sits inside the platform's trust boundary.
Tenant – the untrusted user or project that runs builds on the platform and defines the build steps and external parameters, for example a project's developers and their build scripts. Tenants are outside the trust boundary, so they must not be able to alter what the control plane says about their builds.
Builder ID – an identifier in the provenance that names the build platform (or the trusted part of it). Verifiers use it to decide how much trust to place in the provenance.
External parameters – the inputs that someone outside the platform controls, such as the repository URL, the branch, the workflow file and user-supplied options. Because they are not trusted, they must be checked by whoever verifies the artifact.
Resolved dependencies – the list of other artifacts fetched during a build, such as the source commit, tools and libraries. Recording them is helpful but, up to Build L3, completeness is only "best effort".
Source Control System (SCS) – the platform that hosts source repositories and enforces authentication, permissions and change-management rules, for example a hosted Git service or a self-hosted equivalent. The SCS is to the Source Track what the build platform is to the Build Track.
Revision – an immutable snapshot of the tracked files plus version-control metadata, identified by a revision ID such as a Git commit hash.
Named reference – a human-friendly name that points to a revision, mainly branches (which move forward as development continues) and tags (which should never move once created).
Source provenance – attestations issued by the SCS describing how a revision came to exist: who contributed, when, where it was hosted and which revisions it descends from.
Verification Summary Attestation (VSA) – a signed attestation from a verifier that says "I checked this artifact or revision against this policy, and the result was PASSED (or FAILED) at these SLSA levels". Its predicate type is https://slsa.dev/verification_summary/v1.
Expectations – the known-good values a verifier compares provenance against, such as the expected builder, source repository and build type for a given package.
Roots of trust – the verifier's configured list of build platforms it recognises, each identified by a key or signing identity plus a builder ID, and each mapped to the highest Build level the verifier believes that platform can achieve.
Track and level – a track covers one part of the supply chain (source, build); levels within a track are ordered steps, each including everything required by the levels below it.

A short note on in-toto and signing

SLSA does not invent its own envelope or signing scheme. It relies on the in-toto attestation framework, which packages statements in a signed envelope format called DSSE (Dead Simple Signing Envelope). The signature can come from a long-lived key or from short-lived certificates, for example those issued by the Sigstore project, which binds a signature to an identity such as a CI workflow and records it in a public transparency log. In practice, "provenance" means "a signed in-toto statement with a SLSA predicate".

What provenance contains

The SLSA build provenance predicate has two main parts. The buildDefinition describes the inputs: a buildType (a URI naming a template that explains how the rest of the fields are interpreted), the externalParameters, optional internalParameters that the platform itself controls, and the resolvedDependencies. The runDetails describe this particular execution: the builder (with its required id), metadata such as an invocation identifier and start and finish times, and optional byproducts such as logs. The statement's subject lists the output artifacts with their digests, which is how the provenance is tied to a specific file.

Lesson 3 – Structure of the specification: tracks and levels

How the documents are organised

The v1.2 specification is a set of web pages on slsa.dev rather than a single PDF. It is grouped into:

Understanding SLSA – what is new, an introduction, an overview of supply-chain threats, use cases, guiding principles, frequently asked questions and future directions.
Build Track – the basics and levels, terminology, the requirements for producing artifacts and distributing provenance, and guidance on verifying artifacts and on assessing build platforms.
Source Track – the levels and requirements for organisations and Source Control Systems, guidance on verifying source and on assessing Source Control Systems, and example controls.
Cross-track information – the detailed threats and mitigations shared by all tracks, and a list of verified properties that do not fit neatly into levels.
Attestation formats – the general attestation model and the recommended schemas for build provenance and VSAs.

Each requirement is assigned to a level and to a party: the producer, the platform (build platform or SCS) or the consumer/verifier. This makes it easy to see who must do what.

The Build Track

The Build Track answers the question "can I trust that this artifact was produced from the expected inputs, by the expected process, without tampering?". It has four levels.

Level	Short name	What it adds	Main protection
Build L0	No guarantees	Nothing; this is simply the absence of SLSA	None
Build L1	Provenance exists	A consistent build process and provenance generated by the build platform and given to consumers; it may be unsigned or incomplete	Catches mistakes, helps debugging and inventory
Build L2	Hosted build platform	Builds run on a hosted platform whose control plane generates and signs the provenance; consumers check the signature	Tampering after the build; forging evidence now needs a deliberate attack
Build L3	Hardened builds	The platform isolates builds from one another and keeps signing secrets away from user-defined steps, so tenants cannot forge provenance	Tampering during the build by insiders, other tenants or stolen credentials

Two ideas sit behind the progression. First, who writes the provenance moves from "anything" (L1) to "the trusted control plane, with a signature" (L2) to "the control plane, in a way that build steps cannot influence" (L3). Second, where the build runs moves from "anywhere, including a developer laptop" to "a hosted service" to "a hosted service that provides strong isolation". At L3 the isolation requirements include ephemeral build environments that are freshly created for each run, no ability for concurrent builds to influence one another, protection of shared caches against poisoning, and no hidden remote influence that is not recorded as an external parameter.

Note what is not required. Hermetic builds (builds with no network access) and fully reproducible builds are not Build L3 requirements; the specification lists hermeticity among possible future directions. Reproducible builds are mentioned as one acceptable way for a platform to generate trustworthy provenance after the fact, but they are an option, not a rule. There is also no Build L4 in v1.0 or later; the old v0.1 "level 4" no longer exists, and anyone who claims "SLSA 4" is using outdated terminology.

Self-hosted runners (machines you operate that a hosted CI service sends jobs to) need care. The specification's FAQ says the Build requirements apply to every system that informs the provenance: if the runner generates the provenance or holds credentials used for it, the runner must meet the isolation and key-protection requirements too.

The Source Track

The Source Track answers a different question: "can I trust that this revision of the source is what the organisation intended, with an intact history and the agreed controls applied?". Responsibility is split between the organisation (the people who produce revisions and decide the rules) and the SCS (which enforces the rules and issues evidence). Levels attach to revisions and are reported in source VSAs.

Level	Short name	What it adds
Source L0	(implicit)	No source VSA has been issued for the revision
Source L1	Version controlled	Source lives in a modern version control system with stable repository and revision identifiers, immutable revisions and readable diffs; the SCS issues a source VSA
Source L2	History and provenance	Branch history is continuous, immutable and retained: no force-push rewrites, tags cannot be moved or deleted, every update to a named reference is recorded with who, when and what; the SCS issues source provenance; sensitive operations are access-controlled
Source L3	Continuous technical controls	The organisation declares protected branches or tags and the technical controls that apply to them; the SCS enforces those controls continuously and records them in attestations
Source L4	Two-party review	Every change to a protected branch must be agreed by at least two trusted persons, approvals apply to the final version of the change, and reviewers see a clear view of its effect

Two concepts deserve attention. Continuity means a control must have been enforced without a gap from a given revision onwards; if protection is switched off, even briefly, continuity restarts at a later revision. Onboarding means that when a branch joins the track or moves up a level, claims apply only from that revision forward, never retroactively. The Source Track also defines roles: administrators (who can perform privileged operations), trusted persons (allowed to propose and approve changes), trusted robots (automation authorised for narrow, defined purposes, such as a dependency-update bot) and untrusted persons (who may read and propose, but not approve). A documented "safe expunging" process is expected for the rare cases when content must be removed for legal or privacy reasons.

Figure 2 – The two approved SLSA v1.2 tracks; each level includes everything required by the levels beneath it.

Levels are per track, per artifact

Because tracks are independent, there is no single "SLSA level" for a product or company. A correct claim always names the track and the subject: "release 2.4.0 of our container image meets Build L3", or "revisions on the main branch of the payments repository meet Source L3". A VSA reports exactly one level per track, the highest one verified, since each level implies those below it. An organisation might reach Build L3 for its flagship products while its internal tools remain at Build L1 and its source sits at L2, and that is a perfectly honest position.

Cross-track pieces

The attestation model describes how producers, platforms and verifiers exchange evidence, and the VSA format allows a trusted verifier to summarise a decision using standard level names such as SLSA_BUILD_LEVEL_3 or SLSA_SOURCE_LEVEL_2. The verified properties page adds named claims that are not levels, such as SLSA_SOURCE_TWO_PARTY_REVIEWED and SLSA_BUILD_REPRODUCED. The Source Track also lets organisations report their own properties, which must start with the ORG_SOURCE_ prefix, for example to record that a custom review rule was enforced.

Lesson 4 – How it works in practice

Roles and responsibilities

SLSA spreads work across four parties, and adoption goes smoothly only when each knows its part.

Producer – chooses a build platform able to reach the target level, follows a consistent build process (so that verifiers can form stable expectations), and makes provenance available to consumers, ideally through the conventions of the package ecosystem. For the Source Track, the organisation chooses a capable SCS, decides which branches are protected and which controls apply, and documents them.
Build platform – generates provenance (L1), signs it from the control plane (L2) and makes it unforgeable through isolation and protected signing secrets (L3).
Source Control System – keeps revisions and history immutable, records changes to branches and tags, enforces protection rules and issues source provenance and VSAs.
Consumer or verifier – defines expectations, checks provenance or VSAs before accepting an artifact, and decides what to do when checks fail.

From build to verified artifact

The heart of the Build Track is a simple loop. A developer triggers a build on a hosted platform. The control plane records what it was asked to build and with which parameters, runs the tenant's build steps in a fresh environment, collects the digests of the outputs and signs a provenance statement. The artifact and its provenance are published, either side by side in a registry or through an attestation store. Before the artifact is installed or deployed, a verifier checks the provenance. If anything is wrong, the artifact is rejected.

Figure 3 – Build Track flow: the control plane, not the build script, signs provenance that a verifier checks before the artifact is used.

Verifying provenance step by step

The specification describes verification in three steps.

Step 1 – establish the Build level. Once, the verifier configures its roots of trust: which builders it recognises and the highest level it will grant each one. For every artifact it then checks the envelope signature against those roots, confirms that the provenance subject's digest matches the actual artifact, confirms the predicate type is SLSA provenance, and looks up the level for that signer and builder ID. If the builder is not recognised, the provenance can at best count as Build L1, because anyone could have written it.

Step 2 – check expectations. A genuine, signed provenance only proves where an artifact came from. The verifier must also check that it came from the right place: at minimum the builder identity, the canonical source repository (not a fork), the build type and the external parameters. Unknown external parameters should cause rejection by default, because they might change the build's behaviour. This step is what defends against threat D, an artifact built from the wrong inputs.

Step 3 – optionally check dependencies. A verifier may walk the resolved dependencies recursively. Because many transitive dependencies (for example, the compiler's own toolchain) have no provenance at all, this almost always needs exceptions or trimming, and VSAs are used to avoid re-checking the same dependency again and again.

Where expectations come from

Expectations belong to a package, while provenance belongs to an artifact. The specification describes three ways to define them:

Trust on first use – accept the first version seen and alert whenever a later version's provenance differs in an unexpected way.
Defined by the producer – the producer publishes the expected values through an authenticated channel, protected against one person changing them alone.
Defined in source – the package name is bound to a repository and the rest of the expectations live in that repository, as in ecosystems where the package name is the repository location.

A useful design tip: if external parameters are hard to verify, the build type is probably too low-level. Keeping the list of build steps in a configuration file inside the source repository, so that the only parameters are the repository and the revision, makes verification far simpler.

Where verification happens

Verification can be done by the package ecosystem when an artifact is uploaded (which protects every client at once and is the preferred option), by consumers when they download or deploy (defence in depth, and able to catch tampering that happens after upload, such as in a mirror), or by an independent monitor that checks many packages and reports problems. Options can be combined. In container platforms, for example, an admission controller can refuse to start any image whose provenance or VSA does not satisfy policy.

Figure 4 – The decision path a verifier follows for build provenance, from signature check to expectations.

Typical implementation steps

Organisations rarely jump straight to the top. A practical sequence looks like this:

Inventory. List the artifacts you ship and the ones you consume, the platforms that build them and how they are published.
Pick targets. Decide which artifacts matter most and set a target level per track for each.
Reach Build L1. Move release builds into a scripted, repeatable process and turn on provenance generation.
Reach Build L2. Run release builds on a hosted platform that signs provenance, and stop publishing artifacts built on personal machines.
Start verifying. Add verification at the point of deployment or upload, first in "warn" mode and then enforcing.
Harden toward Build L3. Use a platform configuration that isolates builds and keeps signing material away from build steps.
Raise source levels. Protect branch history and tags (L2), declare protected branches with enforced controls such as required checks (L3), and require two-person review where justified (L4), as far as your SCS can support and attest to these.
Measure and maintain. Track the share of deployed artifacts with verified provenance and keep watching for drift, such as a repository that quietly loses branch protection.

Tooling helps a great deal: several CI services and package ecosystems generate SLSA provenance natively. For example, GitHub's documentation states that its artifact attestations provide Build L2 on their own (stated against SLSA v1.0) and that running the build in a shared reusable workflow can provide the isolation needed for Build L3. Always check the current documentation of your platform before claiming a level, because the level depends on how you configure it, not just on which product you use.

Lesson 5 – Assessment, certification and compliance

There is no official SLSA certificate for organisations

SLSA is not a management-system standard like ISO/IEC 27001 and has no accreditation scheme, no register of certified companies and no official logo programme. Nobody can be "SLSA certified" in the way a company is ISO certified. Instead, SLSA levels are properties of individual artifacts and revisions, demonstrated by evidence that consumers check themselves. If a supplier tells you "we are SLSA Level 3 certified", the right response is to ask which track, which artifacts, which builder, and where the provenance or VSAs are published.

Assessing build platforms

The level a verifier grants depends heavily on how much it trusts the build platform. Signed provenance from an untrustworthy platform is worthless. The specification therefore provides a guide with prompts for evaluating a build platform before trusting it for Build L3. The prompts cover five areas:

External parameters – how inputs are processed and whether all of them appear in the provenance.
Control plane – privileged administration and how misuse is detected, how provenance is generated, development practices for the platform itself, how build environments are created and how cryptographic secrets are stored, rotated and protected.
Build environment – isolation technology, patching and vulnerability response, and how long a compromised environment could persist.
Caches – which caches exist and how their contents are validated before reuse.
Output storage – how builds are prevented from reading or overwriting each other's outputs.

A platform operator can answer these questions as a public self-attestation, or have them checked by an independent third-party auditor; in the second case the detailed evidence need not be made public. The specification calls this second route third-party certification of the platform, but there is no official SLSA accreditation scheme or register of approved auditors behind it. Either way, the decision to trust is made by the consumer when it adds the builder to its roots of trust. The verification guidance stresses that Build L3 does not cover compromise of the build platform itself, for example by a malicious platform administrator, which is exactly why this choice deserves care.

Assessing source

For the Source Track, the evidence is the source VSA issued by the SCS, backed by source provenance from Level 2 upwards. A consumer checks that the VSA is signed by a trusted SCS or verifier, that it names the expected repository and revision, that its result is PASSED and that the reported level (and any organisation-specific properties) meets policy. Because claims apply only from onboarding forward and require continuity, an auditor should also check when a control was introduced and whether it ever lapsed.

Verification Summary Attestations as audit evidence

A VSA records who verified, when, against which policy, using which input attestations, with what result and at which levels; optionally it counts the levels of transitive dependencies. VSAs are useful when a central security team verifies once and many downstream teams rely on that decision, when consumers want a simple rule such as "Build L2 or higher", or when a producer cannot disclose pipeline details but can show that a trusted verifier checked them.

SLSA and regulation

SLSA itself is voluntary. However, regulators and large customers increasingly ask suppliers to show secure development and supply-chain practices. The SLSA project explicitly positions the framework as a way to measure progress against the NIST Secure Software Development Framework (SSDF), which US government software-attestation requirements reference. Provenance and VSAs are concrete, machine-checkable evidence that can support such attestations and similar expectations elsewhere, such as the secure-development obligations in the EU Cyber Resilience Act. SLSA does not by itself make anyone compliant with a law; it supplies evidence for specific integrity controls.

Lesson 6 – Worked example

The organisation

Harbourline is a fictional company of 120 engineers that sells a logistics platform. It ships a command-line tool to customers, publishes a client library to a public package registry, and runs about forty microservices as container images on Kubernetes. A large customer has asked for "evidence of software supply-chain integrity", and the security team has chosen SLSA as the framework.

Step 1: understand the starting point

An inventory reveals three problems. The command-line tool is compiled on a senior developer's laptop and uploaded by hand. The client library is built in CI, but publishing uses a long-lived registry token stored as a CI secret that every repository maintainer can read. The microservices are built in CI on shared self-hosted runners that are reused between jobs. Source is in a hosted Git service, but force pushes are allowed on main branches and tags are routinely moved when a release is "fixed".

In SLSA terms: the laptop build is Build L0; the library and the services might produce some metadata but no trustworthy provenance; on the source side, revisions are version controlled, but history and tags are not protected.

Step 2: set targets

The team sets targets per artifact rather than one target for the company: Build L3 for the customer-facing tool and the public library, Build L2 rising to L3 within a year for production services, Source L3 for the repositories behind those artifacts, and Source L4 for the payment and authentication services, where an insider change would do the most damage. Internal prototypes remain unrated.

Step 3: Build L1 and L2

The command-line tool's release process is moved into the hosted CI service, with the build steps defined in a configuration file in the repository. Provenance generation is switched on. Within a week every release of the tool, the library and the services carries provenance signed by the CI platform's control plane rather than by a script the developers wrote, which puts those builds at Build L2. Manual uploads are disabled, and the old registry token is replaced with short-lived, workflow-bound credentials.

Step 4: verification before use

The platform team adds a verification step in two places. The public library's release job uses the registry's support for provenance so that consumers can check it. The Kubernetes clusters get an admission policy that checks each image: signature from the company's CI builder, subject digest equal to the image digest, source repository within the company's organisation, and the expected build workflow. For a month the policy only logs failures. It turns up two surprises: a service deployed from a developer's fork, and an image built by hand during an outage. Both are fixed, and the policy moves to enforcing mode.

Step 5: Build L3

The services' self-hosted runners are a problem for L3. They run the release builds, hold the credentials used to publish and attest the images, and persist between jobs, so they are part of the platform that informs the provenance, and one job could leave something behind for the next. That fails the L3 isolation requirement. Harbourline moves release builds to fresh, platform-managed environments and to a single centrally owned build workflow that all repositories call, so that the signing identity is available only to that workflow and not to individual project steps. After reviewing the platform's published security information against the SLSA assessment prompts, the security team adds this builder to the verifier's roots of trust at Build L3. The verification policy for the tool and library now requires L3.

Step 6: Source track

On the source side, the team blocks force pushes and branch deletion on main branches, makes release tags immutable and turns on the SCS's audit of reference changes. Because the hosted Git service, together with an attestation tool the team adopts, can emit source provenance and VSAs for these repositories, revisions created after this change can reach Source L2; older history is not claimed, following the onboarding rule. Next, the main branches are declared protected, with required status checks and code-owner approval enforced continuously and recorded in attestations, which gives Source L3. For the payment and authentication services, two-party review is required on every change, approvals reset when a change is updated, and a dependency-update bot is registered as a trusted robot with a narrowly defined exception. One week the protection on a repository is accidentally disabled during a migration; the monitor notices, and continuity restarts from the next protected revision rather than being silently glossed over.

Step 7: report and maintain

For the customer, Harbourline publishes a short statement listing each product, its Build and Source levels under SLSA v1.2, the builder ID, where provenance and VSAs are published and how to verify them. Internally, a dashboard tracks the percentage of running containers with verified provenance (it reaches 97 % after six months; the remainder are third-party images handled through an exception list). The team also records what SLSA does not cover for them: the quality of their dependencies is still assessed through separate open-source risk checks, and vulnerability scanning continues as before.

Lesson 7 – Relationship to other standards and frameworks

SLSA is one piece of a larger supply-chain security picture. It focuses on the integrity and origin of source and builds and relies on other projects for formats, signing and broader practices.

Framework or project	Owner	What it covers	How it relates to SLSA
NIST Secure Software Development Framework (SSDF), SP 800-218	NIST (US)	High-level secure development practices across preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities	SSDF says what outcomes to achieve; SLSA gives concrete, measurable levels and evidence for the integrity-related practices, such as protecting code and build environments and recording provenance
in-toto and the in-toto attestation framework	CNCF project	A general framework and format for signed statements about software supply-chain steps	SLSA provenance and VSAs are in-toto attestations with SLSA-defined predicates
Sigstore	OpenSSF project	Signing with short-lived identity-based certificates and public transparency logs	A common way to sign and record SLSA provenance so that verifiers can check who signed it
SBOM formats (SPDX, CycloneDX)	Linux Foundation / OWASP-Ecma	An inventory of the components inside a piece of software	An SBOM lists what is inside; provenance records how and where it was built. They complement each other, and both can be distributed as attestations
OpenSSF Scorecard	OpenSSF	Automated checks of an open-source project's security practices, such as branch protection and pinned dependencies	Helps consumers judge projects and spot weaknesses, while SLSA defines levels backed by attestations for specific artifacts and revisions
ISO/IEC 27001	ISO/IEC	A certifiable information security management system for a whole organisation	An ISMS can select SLSA as the technical approach for its secure development and supplier-security controls; ISO/IEC 27001 certification does not imply any SLSA level

How to combine them

A mature programme often uses the SSDF or an ISMS as the management umbrella, SLSA as the yardstick for build and source integrity, in-toto and Sigstore as the plumbing for signed evidence, SBOMs for component transparency and tools such as Scorecard to evaluate the open-source projects it consumes. OpenSSF also publishes a separate framework for consuming open-source dependencies safely, which tackles some of the dependency risks SLSA leaves open, and the SLSA working draft explores a dedicated Dependency Track for the same reason.

Common confusions

"We have an SBOM, so we are SLSA compliant." No: an SBOM is a parts list, not proof of how something was built.
"We sign our artifacts, so we are Build L3." No: a signature shows who signed, not that the build was isolated and the provenance unforgeable by build steps.
"We are SSDF compliant, so SLSA is redundant." No: SSDF is outcome-oriented; SLSA provides concrete, verifiable evidence for part of it.

Common pitfalls and best practices

Pitfalls

Generating provenance that nobody verifies. Evidence without a verification step only helps after an incident; tampering still gets through.
Claiming a level for a whole company. Levels belong to artifacts and revisions in a named track; a single company-wide number misleads customers.
Trusting any signature. Accepting provenance from builders that are not in your roots of trust, or not checking that the subject digest matches the file, defeats the purpose.
Ignoring external parameters. Checking only the builder lets an attacker run the trusted builder on a fork or with injected options.
Persistent or shared build machines. Reused runners and writable shared caches break the isolation that Build L3 depends on.
Leaving manual side doors open. Keeping a long-lived registry token or a manual upload path means attackers can bypass the trusted build entirely.
Retroactive source claims. Claiming Source L3 for history that predates branch protection, or hiding a lapse in enforcement, breaks the continuity rule.

Best practices

Start with inventory and risk. Raise levels first for the artifacts whose compromise would hurt most.
Use platform-native provenance. Let the build service's control plane create and sign provenance rather than writing it in your own scripts.
Verify close to use. Check provenance at upload and again at deployment or install, starting in warning mode and moving to enforcement.
Keep build definitions in source. Fewer and simpler external parameters make expectations easy to write and hard to bypass.
Centralise release builds. A small number of well-managed, shared build workflows is easier to harden, assess and trust than many bespoke ones.
Protect history and tags early. Blocking force pushes and tag moves is cheap and lays the foundation for higher source levels.
Publish clear statements. State track, level, specification version, scope and how to verify, and keep the statement current.
Combine with other controls. Pair SLSA with code review, scanning, SBOMs and dependency vetting, because SLSA does not judge code quality.

Summary and key takeaways

SLSA is a free, community-maintained OpenSSF framework for software supply-chain integrity; the current approved edition is v1.2 (November 2025).
It protects the path from source to artifact against tampering, wrong inputs and unofficial uploads, not the quality of the code or the honesty of the producer.
The Build Track runs from L0 to L3: provenance exists, then signed provenance from a hosted platform, then hardened and isolated builds whose provenance build steps cannot forge.
The Source Track runs from L1 to L4: version control, protected history with source provenance, continuously enforced controls, and two-party review.
Provenance is a signed in-toto statement that names the outputs by digest and records the builder, build type, parameters and dependencies.
Verification is essential: check the signature against roots of trust, match the subject digest, then compare builder, source and parameters with expectations.
There is no SLSA certification body; levels are evidence-based claims about specific artifacts, and build platforms are assessed by self-attestation or independent audit.
SLSA complements the NIST SSDF, in-toto, Sigstore, SBOMs and management-system standards rather than replacing them.

Reflection questions

Think of one artifact your team ships today. Which SLSA Build level does it honestly meet, and what is the single biggest change needed to reach the next level?
Where in your organisation would verification of provenance have the greatest effect: at upload to a registry, at deployment, or both? What would you do with an artifact that fails?
Which of the threats A to I from Figure 1 worry you most for your products, and which of them would SLSA leave unaddressed?
If a supplier tells you its product is "SLSA certified", which follow-up questions would you ask, and what evidence would satisfy you?
For your most sensitive repository, what would be the practical cost of Source L4 two-party review, and how would you handle automation such as dependency-update bots?