SLSA (Supply-chain Levels for Software Artifacts) proves that a software artifact was built the way its producer claims, using signed provenance and a four-level assurance scale. It works for anyone building, shipping, or consuming code, from a two-person startup to

a platform team securing thousands of internal packages. If you’re evaluating whether to adopt it, the answer is yes, and the sooner you start signing provenance, the less rework you’ll face later.

TL;DR:

  • Achieving at least SLSA Level 2 with a hosted build platform significantly reduces tampering risks compared to basic CI setups.
  • Level 3 requires source and build isolation along with signed provenance generated by the build platform, essential for verifying tamper resistance.
  • Starting with signed provenance at Level 1 is inexpensive and facilitates a smoother transition to higher assurance levels later.
  • Most current builders, like GitHub Actions, can reach Level 3 with proper configuration, while Level 4 remains reserved for critical infrastructure.
  • Continual enforcement of controls and documenting start points are crucial for maintaining compliance and avoiding audit failures.

Table of Contents

What Is the SLSA Framework and Why Does It Exist?

You already trust dozens of dependencies you’ve never inspected. SLSA exists because that trust used to be a handshake, and handshakes don’t scale across a supply chain with thousands of transitive packages. The SLSA framework gives producers and consumers a shared, verifiable language for artifact integrity instead of relying on a vendor’s word.

OpenSSF governs the project, which matters because SLSA isn’t a single vendor’s checklist. It’s a consensus standard shaped by the same open source community that maintains the tooling most of the industry already runs on. That governance model is also why SLSA plays well with other supply chain initiatives rather than competing with them.

  • SBOMs list what’s in an artifact. SLSA proves how that artifact was built and by whom.
  • NIST’s supply chain guidance informs procurement criteria that SLSA’s provenance fields can satisfy directly.
  • CISA’s recommended practices guide buyers on what to demand from suppliers, and SLSA gives suppliers a concrete way to answer.

SLSA earns its keep fastest when your artifacts leave your own network: open source packages, container images pulled by other teams, or anything sold to enterprise customers who run their own vendor risk reviews.

What Are the SLSA Assurance Levels (1 Through 4)?

Each level raises the bar on what you can prove, and each one changes how your build pipeline actually operates, not just what paperwork you keep.

  1. Level 1 requires a documented build process and generated provenance. No enforcement, just a record. Almost any CI setup clears this with minor configuration changes.
  2. Level 2 requires a hosted build platform (not a laptop or a self-managed runner with root access) and signed provenance. This is where forged provenance becomes meaningfully harder.
  3. Level 3 adds source and build isolation: builds can’t be tampered with by other jobs, and secrets used during one build stay unreachable to another. It also introduces the requirement for non-falsifiable provenance generated by the build platform itself, not the build script.
  4. Level 4 requires two-person review of every change and hermetic, fully reproducible builds. This is the tier defense contractors and platform teams securing critical infrastructure target, not the average SaaS product.

Most teams overestimate what Level 4 demands and underestimate what Level 2 already buys them. Level 2, achieved with a properly configured hosted builder, closes off the most common tampering vector: a compromised build machine silently altering an artifact after code review has already happened.

Pick your starting target based on risk, not ambition. A team is skipping tokens shipping internal tooling with no external consumers can sit comfortably at Level 2. A team publishing a widely depended-on open source library should push toward Level 3, because that’s the level where downstream consumers can actually verify tamper resistance.

What Do the SLSA Source and Build Tracks Require?

The spec organizes requirements into tracks, and each track produces evidence a verifier checks independently. Treat these as engineering requirements, not documentation exercises.

Source track controls:

  • Branch protection on the repository that produces released artifacts, with required reviews before merge.
  • A retained, immutable change history, so any commit can be traced to its author and review record.
  • Source Verified Summary Attestations (Source VSAs) that a platform can issue once it confirms these controls are actually enforced.
  • Continuity from a documented start revision: controls must run without gaps, and any gap resets your continuity clock.

Build track controls:

  • Use of a hosted builder rather than a self-administered runner, so no single engineer can quietly modify the build environment.
  • Isolation guarantees that prevent one build job from influencing another’s inputs, cache, or secrets.
  • Provenance signed by the builder platform, not generated and self-signed by the same script that produced the artifact.

Provenance content and publishing: the attestation needs to name the source commit, the builder identity, the entry point invoked, and the materials consumed. It gets signed, then published somewhere a verifier can retrieve it, typically alongside the artifact in a registry or transparency log.

How Do You Get Started With SLSA Compliance?

Getting your first artifact to a verifiable state takes less engineering than most teams expect. The heaviest cost is deciding what target level makes sense, not the implementation itself.

  1. Pick a target level you can defend to a security reviewer. Don’t default to Level 1 just because it’s easiest. If you’re likely to need Level 3 within a year, build toward it now rather than migrating build platforms twice.
  2. Adopt a hosted build platform that generates and signs provenance natively. This is the single highest-leverage step in the entire process.
  3. Configure provenance publishing so downstream consumers, or your own internal verification tooling, can retrieve and check it without asking you directly.
  4. Document your controls and pick a start revision. This is the moment your continuity clock begins; write down the date and the commit.
  5. Test verification end to end. Run a generic SLSA verifier against your published provenance before you tell anyone it’s compliant.

Pro Tip: Sign provenance at Level 1 even if you’re not required to yet. It costs almost nothing at that stage, and it means your Level 2 migration is a policy change, not a rebuild.

Teams that skip straight to “we’ll do this properly at Level 3” often ship nothing for months. Working provenance today beats a perfect pipeline that’s still in design review.

Which Builders Map to Which SLSA Levels?

Your builder choice determines your ceiling. Some platforms get you to Level 3 with configuration; others cap out lower until the ecosystem catches up.

  • GitHub Actions can reach SLSA Level 3 using the language-agnostic provenance generator, which handles signing and isolation guarantees for you. Check that your workflow uses the reusable generator rather than a custom signing step, which won’t carry the same guarantees.
  • Google Cloud Build is listed as a potential Level 3 builder as well, provided you configure it to emit signed provenance rather than relying on build logs alone.
  • FRSCA currently maps to Level 2, an emerging option worth watching if you’re standardizing on Kubernetes native tooling.

If your current builder can’t hit your target level, you have two paths: migrate to one that can, or layer attestation and verification tooling on top of your existing CI/CD. Migration costs more upfront but avoids permanent workarounds. A builder that produces structured provenance today, even at a lower level, keeps you “SLSA ready” as tooling matures around it.

Common SLSA Implementation Pitfalls and Best Practices

The biggest mistake we see is treating SLSA as a one-time audit item, something you achieve, screenshot, and file away. It doesn’t work that way. Technical controls have to run continuously, and any lapse resets your continuity from that point forward. A branch protection rule disabled for a weekend hotfix isn’t a footnote. It’s a reset.

Sign provenance now, even at Level 1, even if nobody’s asking for it yet. Teams that wait until a customer demands Level 3 usually discover their build pipeline needs a rewrite, not a policy update.

Migrating build platforms is expensive. Before you commit to one, ask whether attestation tooling layered onto your current CI/CD gets you 80% of the way there. Sometimes the answer is yes, and the migration can wait.

When controls start slipping, or you’re not confident your provenance would survive a real audit, an outside code audit catches gaps a busy internal team misses on its own pipeline.

Where to Find the SLSA Spec and Next Steps

You don’t need to guess at any of this. The spec and getting-started guidance are public and specific.

Your next move: run a provenance proof-of-concept on one artifact this week, pick the builder that gets you closest to your target level, and write down your continuity start date before you call it done.

Real-World SLSA Adoption: What It Looks Like in Practice

Open source foundations were the early adopters, and for good reason: their artifacts get pulled by thousands of downstream projects with no direct relationship to the maintainers. A maintainer who signs provenance through a hosted builder gives every consumer of that package a way to verify it wasn’t tampered with between the commit and the registry, without ever exchanging an email.

Hands placing sealed envelope with security tokens

Enterprise platform teams have followed a different path. Rather than chasing Level 4 across an entire product line, most start by targeting Level 3 on their highest-risk build pipelines, typically anything that produces artifacts consumed by other internal teams or external customers, and leave lower-risk internal tooling at Level 2 or Level 1. That triage approach avoids the trap of treating SLSA as all-or-nothing.

A common pattern worth borrowing: teams standardize on one hosted builder across their organization first, then raise the assurance level incrementally once the builder itself is locked in. That sequencing avoids the expensive mistake of hitting Level 3 requirements on one builder, then discovering a different team’s builder can’t follow, forcing a second migration a year later.

The lesson across these approaches is consistent. Adoption succeeds fastest when it starts with the artifacts that carry the most exposure, not the ones that are easiest to fix first.

How Does SLSA Compare to Other Supply Chain Security Approaches?

SLSA doesn’t replace SBOMs, code signing standards, or vulnerability scanning. It sits alongside them, and each does a different job.

An SBOM is an inventory. It tells you what components an artifact contains, which matters enormously when a new CVE drops and you need to know your exposure fast. It says nothing about whether the artifact itself was built honestly.

SLSA’s provenance answers the question an SBOM can’t: was this specific build produced by the process the producer claims, from the source commit they claim, without tampering along the way? A vulnerability scanner can tell you a dependency is outdated. Neither an SBOM nor a scanner can tell you whether your build server was compromised last Tuesday.

Code signing, on its own, proves an artifact wasn’t altered after signing. It doesn’t prove anything about how the artifact was built in the first place, which is the gap SLSA’s build track closes. Think of signing as sealing an envelope and SLSA as documenting who wrote the letter and where they wrote it.

Where SLSA earns its distinct place is in the combination: a signed, structured, verifiable claim about your entire build process, not just a static snapshot of dependencies or a signature on the final file. Organizations serious about supply chain risk tend to run all three together: SBOM for inventory, SLSA for build integrity, and signing for tamper detection after the fact.

How Does SLSA Fit Into a CI/CD Pipeline?

SLSA isn’t a separate system bolted onto your pipeline. It’s a set of properties your existing CI/CD either already has or needs to acquire, mostly around who controls the build environment and what gets recorded when.

The practical integration points are narrower than they sound. Your source repository needs branch protection and required reviews before merge, which most teams already run through pull request policies. Your build step needs to run on a hosted, isolated runner rather than a long-lived self-managed machine, and it needs to emit a signed provenance attestation as a build artifact, alongside (not instead of) your binary, container image, or package.

That provenance attestation then needs a publishing step: pushed to a registry alongside the artifact, attached to a release, or written to a transparency log, depending on your ecosystem. GitHub Actions handles this cleanly through its reusable provenance generator, which slots into an existing workflow file as an additional job rather than a pipeline rewrite.

The part teams underestimate is verification. Producing signed provenance without ever checking it means you’re trusting your own claims without testing them. Add a verification step, even a manual one at first, that pulls your published provenance and confirms it matches the artifact before you consider the integration complete.

Hands holding USB cryptographic verification token

None of this requires ripping out your existing CI/CD platform. It requires adding a provenance generation step, a signing step, and a publishing step, in that order, to a pipeline you likely already trust for everything else.

What Does SLSA Compliance Actually Reduce in Terms of Risk?

The risk SLSA targets is specific: a build environment that produces something other than what the source code and review process intended. That’s a narrower threat than “supply chain security” broadly, but it’s one of the hardest to detect after the fact, because a tampered build can pass every code review and still ship a compromised artifact.

Signed provenance changes the economics of that attack. A build system compromise gives an attacker nothing useful, because the resulting artifact either won’t carry valid provenance or will carry provenance that doesn’t match its claimed source, and either signal gets caught the moment a consumer verifies. That’s a meaningfully different posture than relying on code review alone, which can’t detect tampering that happens after review and before release.

The isolation guarantees at Level 3 close a related gap: a build job for one project can’t reach into secrets or caches belonging to another. Without that isolation, a single compromised pipeline on a shared build platform becomes a lever an attacker can use against every other pipeline running on the same infrastructure, a pattern that has shown up in real supply chain incidents across the industry.

None of this eliminates risk from vulnerable dependencies, which is a separate problem SBOMs and scanning tools address. What it removes is a specific, structural blind spot: the assumption that what left your build server is what your source code actually described. For any team shipping to customers who run vendor risk assessments, that’s the exact claim procurement teams increasingly ask for evidence of, not just an assertion.

What’s Next for the SLSA Framework?

SLSA reached spec v1.2 as a maturing, actively maintained standard, not a finished one. The direction of travel is toward broader builder support and tighter integration with the attestation ecosystem it depends on.

Expect continued expansion of the builder ecosystem that can natively generate Level 3 provenance without custom engineering. Platforms like FRSCA, currently mapped to Level 2, represent the kind of tooling likely to close the gap toward Level 3 as isolation and signing capabilities mature, following the path GitHub Actions and Google Cloud Build have already taken.

Verification tooling is the other area worth watching closely. Right now, checking published provenance against an artifact often requires assembling your own verification script or relying on a generic verifier. As more registries and package ecosystems build native verification into their pull and install flows, the manual step teams currently treat as optional will likely become automatic, the same way checksum verification became invisible infrastructure a decade ago.

The governance model itself, run through OpenSSF with input from the same community that built much of today’s CI/CD tooling, suggests SLSA will keep evolving alongside real-world adoption feedback rather than shipping a rigid spec and walking away. Teams adopting SLSA now are effectively building on a standard that will keep getting easier to satisfy, not harder, as tooling catches up to the spec.

Editorial Take: What Practitioners Get Wrong About SLSA

Most teams treat SLSA as a security team’s problem to solve after the product ships. That’s backwards. The controls that matter most, branch protection, hosted builders, signed provenance, are cheapest to add on day one and expensive to bolt onto a mature pipeline with entrenched habits and legacy runners nobody wants to touch.

The conventional advice tells teams to “start at Level 1 and work up.” That’s technically correct and practically misleading. If you can identify your realistic ceiling now, whether that’s Level 2 for internal tooling or Level 3 for anything customer-facing, build toward that ceiling directly. The teams that treat each level as a separate migration end up doing the hosted-builder work twice.

What gets underestimated across the board is continuity. Compliance isn’t a snapshot; it’s a clock that starts on a specific revision and resets the moment a control lapses. Most teams that fail an audit don’t fail because they lacked controls. They fail because nobody documented when those controls actually started, or because someone quietly disabled branch protection for a hotfix and never re-enabled the continuity tracking. Fix that discipline before you worry about which level to target.

— Chad

Sources

FAQ

What Does SLSA Stand For?

SLSA stands for Supply-chain Levels for Software Artifacts, a framework governed by OpenSSF that defines progressive assurance levels for verifying how software was built and where it came from.

What Are the Requirements for SLSA Level 3?

Level 3 requires a hosted build platform with source and build isolation, meaning no build job can be tampered with or influenced by another, plus non-falsifiable signed provenance generated by the platform itself rather than by the build script.

Do I Need SLSA Level 4 for My Project?

Most teams don’t. Level 4 requires two-person review of every change and fully hermetic, reproducible builds, a bar typically reserved for critical infrastructure and defense-grade software rather than standard commercial products.

Which Builders Support SLSA Level 3 Today?

GitHub Actions and Google Cloud Build are both listed as potential Level 3 builders when configured with the appropriate provenance generators, while platforms like FRSCA currently support Level 2.

How Long Does It Take to Reach SLSA Compliance?

Reaching Level 1 or 2 can happen in days once you adopt a hosted builder that signs provenance; Level 3 takes longer because it depends on your builder’s isolation guarantees and how mature your source controls already are.