How do organisations get started with the SLSA Framework?

What “getting started” means for SLSA

Getting started is not about jumping straight to the highest level. It means choosing the builds and release paths where provenance matters most, then tightening those paths first. For most organisations, that starts with the software that is deployed broadly, updated often, or can materially affect production trust if tampered with.

The practical question is which artefacts need evidence you can rely on later. A good starting point is any build path that already has repeatable tooling, a clear source-of-truth repository, and an identifiable release step, because those conditions make provenance controls easier to introduce and verify.

Which controls to put in place first

The early focus should be on controlled source, build isolation, and verifiable artefacts. Controlled source means limiting what can enter the build, build isolation means reducing the chance that one build can influence another, and verifiable artefacts means the output can be traced back to the build that produced it.

That is why repeatable builds matter: they make it easier to tell whether an artefact changed because the source changed or because the build process was manipulated. Protected signing then gives release consumers a way to check that the artefact they received matches what the pipeline intended to publish.

For teams that need a structured starting point, the SLSA and Build Provenance Guide maps the common build-provenance controls to practical implementation steps, while CI/CD Pipeline Identity Security Guide is useful when the first gap is pipeline access, publishing tokens, or signing permissions rather than the build system itself.

How to phase adoption without stalling delivery

A sensible rollout is to start where assurance is easiest to prove and most valuable to the business. That usually means one or two critical build paths, not every repository at once. Once those paths produce trusted evidence consistently, you can extend the same pattern to more services, more teams, and later stages of the release chain.

Use the open source dependency path as a companion problem where it helps your rollout. The Open Source Security Guide helps when the build pipeline depends on external packages, because provenance is stronger when dependency hygiene, trusted publishing, and version control are already in place.

At the external-reference level, the SLSA specification is the canonical place to confirm the current model for build provenance and assurance levels. Use it to align your internal rollout plan with the framework, rather than inventing your own interpretation of the levels.

Practitioner Guidance

What to prioritise: Start with the build path that would hurt most if a compromised artefact reached production, then instrument that path first. A narrow, high-value rollout beats a broad, low-evidence effort.

What to verify: Before you claim progress, confirm that each protected build can show source input, build isolation, signing, and an artefact record that downstream consumers can validate. If any of those are missing, you have process improvement, not provenance assurance.

Practitioner takeaway: SLSA adoption works best when it is treated as a staged evidence problem, not a one-time policy change, so begin with the few build paths where stronger provenance will materially reduce release risk.

Related resources from NHI Mgmt Group

• How should organisations get started with the NIST Cybersecurity Framework without getting lost in the details?
• How do organisations get started with a Transparency and Consent Framework?
• How do organisations get started with framework implementation tiers?
• How do organisations get started with Crypto Agility Framework?