How do organisations get started with the SLSA Framework?

Organisations get started with the SLSA Framework by identifying which software builds and release paths need stronger provenance, then improving them step by step. Begin with controlled source, build isolation and verifiable artefacts, then raise assurance over time. Focus on repeatable builds, protected signing, and evidence of who built what and when.

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.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Supply-chain Levels for Software Artifacts	The question is about starting a SLSA rollout, so the framework itself is the primary reference.
Recommendation — Adopt the SLSA model incrementally and raise build provenance assurance over time.
NIST SP 800-53 Rev 5	CM-3 — Configuration Change Control	Controlled source and repeatable builds depend on disciplined control of build inputs and changes.
	AU-10 — Non-repudiation	Verifiable artefacts and signing support proof of who built or released software.
	SI-7 — Software, Firmware, and Information Integrity	Build provenance is materially about detecting tampering and ensuring artefact integrity.
Recommendation — Control build-source changes and approvals before promoting artefacts. Preserve evidence that ties artefacts to their build and release events. Validate build outputs and reject artefacts that cannot be trusted.
OWASP ASVS	V15 — Secure Coding and Architecture	Repeatable builds and provenance are strengthened when software delivery is designed for integrity from the start.
Recommendation — Design the delivery process so build integrity can be verified consistently.
CIS Controls v8	CIS-16 — Application Software Security	SLSA adoption is a software-delivery control effort that benefits from secure build and release practices.
Recommendation — Harden build and release processes so published software can be trusted.

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.