SLSA and the SSDF answer different questions. SLSA, from the open source community, asks whether an artifact was built by the expected platform from the expected source without tampering. NIST's Secure Software Development Framework, SP 800-218, asks whether your whole development practice is secure. Many buyers ask for SSDF attestation. Engineers often reach for SLSA to satisfy part of it.
What is SLSA?
SLSA describes itself as incrementally adoptable guidelines for supply chain security, set by industry consensus. It gives a common vocabulary, a way to evaluate the trustworthiness of artifacts you consume, and a checklist for your own software. Its build track defines levels of increasing assurance, with provenance, a signed record of how an artifact was built, as the central evidence.
The project's own analogy helps: an SBOM is the ingredient label, and SLSA is the food safety handling that makes the label credible. It targets threats such as modified code after source control, artifacts not built by the expected CI/CD platform, and compromised build platforms. The current version we saw referenced on the site is 1.2, and older version pages are marked retired, so cite the current one.
What is the SSDF?
NIST SP 800-218, version 1.1, is a set of secure software development practices drawn from sources such as BSA, OWASP and SAFECode. NIST notes that few development life cycle models address software security in detail, so these practices are meant to be added to whatever process you use. It includes mappings from Executive Order 14028 section 4(e) clauses to practices and tasks. NIST has also finalized SP 800-218A, a community profile for generative AI and dual-use foundation models.
The practices are grouped into preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities. It is a practice framework, not a technical specification.
Where do they overlap?
SLSA's own introduction lists measuring progress toward forthcoming Executive Order standards in the SSDF as one of its benefits. The overlap sits in the protect-the-software and produce-secure-software areas: controlling who can change source, hardening the build, keeping integrity evidence for released artifacts, and verifying what you consume.
SLSA does not cover code review quality, threat modelling, training, vulnerability response or many other SSDF practices. The SSDF does not tell you how to format provenance or what a hardened build platform looks like.
Which do you need?
If a US federal customer or a large enterprise asks for secure development attestation, you need the SSDF as your frame. Map your existing practices to it and fill gaps.
If your problem is proving artifact integrity, such as a customer worried about build tampering or an open source project distributing packages, you need SLSA, and you can cite it as evidence for the relevant SSDF tasks.
If you are both, use the SSDF as the program outline and SLSA as the build track inside it.
A constructed example
A team ships a container image. Under SSDF they document code review rules, vulnerability handling and training. Under SLSA they move their build to a hosted pipeline that generates signed provenance, and add a deploy step that verifies provenance before running the image. The first covers how the team works. The second proves what ran.
How to check or apply this
- Ask the customer which they require, and in what form.
- Map current practices to the four SSDF groups and mark gaps.
- Check where your builds stand against the SLSA build levels.
- Generate provenance for release artifacts and verify it at deploy.
- Keep an SBOM alongside it and note how each artifact links to the other.
- Review mappings when either framework publishes a new version.
Safeguard's SBOM and dependency scanning supports the inventory side of this work.
Quick check
Does SLSA replace the SSDF?
No. SLSA is narrower and technical, focusing on build integrity. The SSDF covers the full secure development practice.
Is SLSA provenance the same as an SBOM?
No. An SBOM lists contents. Provenance records how and where an artifact was built.
Sources
Last reviewed: 18 October 2026.
