Use NIST SSDF for a risk-based secure software development program across governance, protected environments, secure production, and vulnerability response. Use v1.2 when you need a specific Source or Build track claim backed by provenance and platform controls. SLSA can support parts of SSDF, but it does not cover the whole lifecycle; SSDF adoption does not establish a SLSA level.
Side-by-side comparison
NIST SSDF vs SLSA: practical side-by-side comparison
Compare NIST SSDF and with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.
NIST SP 800-218 SSDF v1.1 gives producers recommended practices across Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Organizations tailor tasks and formality to risk.
Second framework
SLSA
v1.2 defines separate Source and Build tracks with increasing levels. The Source track covers how source revisions are created and controlled. The Build track covers provenance, hosted build platforms, provenance authenticity, and isolation. SLSA is a specification, not a universal legal mandate or certification issued by the Linux Foundation.
NIST SSDF vs SLSA: practical side-by-side comparison
SSDF covers organizational preparation, protection of software and development environments, secure software production, and vulnerability response across the software lifecycle.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
v1.2 covers defined supply-chain properties through tracks. Source levels apply to source revisions and source-control processes; Build levels apply to package artifacts, build provenance, and build-platform properties.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Write an SSDF scope for the software and lifecycle, then a scope for each source repository, source revision, build platform, package artifact, track, and level. A product-wide SLSA claim is too broad unless every covered item is identified.
The software producer distributes SSDF work across leadership, engineering, product security, platform, release, procurement, and vulnerability-response teams, with responsibilities documented when suppliers perform tasks.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
assigns track-specific responsibilities. Repository owners and source-control systems implement Source controls; producers choose suitable build platforms and distribute provenance; build platforms generate provenance and provide required isolation; consumers or verifiers check claims against policy.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Name the actor for each claim. A platform can generate valid provenance while the producer still fails an SSDF design, testing, component-management, or vulnerability-response task.
NIST SSDF is adopted when an organization needs a secure software development practice set for a product, release, supplier, vulnerability response, or software acquisition workflow.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
is adopted when a producer, package ecosystem, consumer, contract, or internal policy requires a stated Source or Build level or verified supply-chain property. SLSA itself does not impose one target level or deadline on every project.
Official SLSA v1.2 source for the separate Source and Build tracks and their level requirements.
Record who set the SSDF scope and who set each target. Do not present a voluntary target as a legal duty or claim a higher SLSA level than the evidence supports.
NIST SSDF recommends that producers integrate applicable practices across PO, PS, PW, and RV into their software development life cycles (SDLCs). Applicability and implementation formality are risk-based; the publication does not prescribe one evidence format.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
For the Build track, L1 requires provenance to exist; L2 adds a hosted build platform and authentic provenance; L3 adds stronger resistance to provenance forgery and isolation between builds. v1.2 also reintroduces a separate Source track, with levels for version control, history and provenance, continuous technical controls, and two-party review.
Defines Source levels for version control, history and provenance, continuous technical controls, and two-party review.
Record the track and level, because ' L3' without a track is ambiguous in v1.2. Apply every normative requirement for the claimed level; do not infer missing Source controls from a Build level.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
evidence is claim-specific. Build evidence includes the artifact digest and provenance, plus producer and build-platform identity, a platform assessment, and a verification result when the stated claim requires them. Source evidence includes the source revision, a Source verification summary attestation (VSA) summarizing the security properties and level of the revision, source provenance for Source Level 2 or higher, repository controls, and evidence for the claimed Source level.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Index evidence by SSDF task and by track and level. Verify that the attestation subject matches the released artifact or source revision; a valid signature on unrelated or incomplete provenance is not enough.
NIST SSDF defines no general commencement or certification-renewal clock. Review at SDLC, release, supplier, vulnerability, and material-change points selected for the scope.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
v1.2 sets technical requirements, not a universal adoption or renewal deadline. The adopting organization or ecosystem decides when provenance is generated, when verification occurs, how platform assessments are refreshed, and what happens when verification fails.
Defines SLSA as a specification with separate tracks and levels; an adopting organization or ecosystem supplies its own rollout and review schedule.
Set triggers for new source revisions, builds, releases, platform changes, signing-key changes, policy changes, and failed verification. Keep contractual deadlines separate from the specifications.
NIST does not certify organizations against SSDF. The adopting program defines reviews, supplier checks, customer evidence, contract acceptance, or other assurance activities.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
conformance is evaluated against the normative requirements for a stated track and level. Provenance authenticity, verification, and platform or source-control assessment support the claim, but the SLSA specification does not guarantee that the source code is benign or free of vulnerabilities.
Normative Build-track requirements for producers, build platforms, provenance authenticity, and isolation.
State the exact claim, verifier, policy, evidence, and covered revision or artifact. Avoid broad labels such as ' certified' or 'NIST certified' unless a separate named program authorizes them.
SSDF tasks for protecting source, controlling development environments, preserving release integrity, recording provenance, and reviewing changes can draw on evidence when the scopes match.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
Source and Build evidence can support selected SSDF outcomes, but SLSA does not replace secure design, secure coding, component-vulnerability review, security testing, disclosure, remediation, or root-cause analysis.
Defines Build-track producer, platform, provenance, authenticity, and isolation requirements.
Use a bridge row that names the SSDF task, track and level requirement, shared evidence, and remaining gap. Do not convert overlap into a claim of full equivalence.
Use NIST SSDF when the primary question is how a producer integrates secure-development outcomes across organization preparation, software protection, secure production, and vulnerability response, or when an identified acquirer or authority requests an SSDF task mapping.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
Use when the deliverable is a Source or Build track level, a source or build provenance attestation, a platform assessment, or a verification result against a declared policy.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Use both for releases that need lifecycle-wide secure-development evidence and explicit source or build supply-chain claims. Keep a separate result for each SSDF task and each track and level.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Scope and covered activity
NIST SSDF
SSDF covers organizational preparation, protection of software and development environments, secure software production, and vulnerability response across the software lifecycle.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
SLSA
v1.2 covers defined supply-chain properties through tracks. Source levels apply to source revisions and source-control processes; Build levels apply to package artifacts, build provenance, and build-platform properties.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Operational implication
Write an SSDF scope for the software and lifecycle, then a scope for each source repository, source revision, build platform, package artifact, track, and level. A product-wide SLSA claim is too broad unless every covered item is identified.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Who must act
NIST SSDF
The software producer distributes SSDF work across leadership, engineering, product security, platform, release, procurement, and vulnerability-response teams, with responsibilities documented when suppliers perform tasks.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
SLSA
assigns track-specific responsibilities. Repository owners and source-control systems implement Source controls; producers choose suitable build platforms and distribute provenance; build platforms generate provenance and provide required isolation; consumers or verifiers check claims against policy.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Operational implication
Name the actor for each claim. A platform can generate valid provenance while the producer still fails an SSDF design, testing, component-management, or vulnerability-response task.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Trigger or threshold
NIST SSDF
NIST SSDF is adopted when an organization needs a secure software development practice set for a product, release, supplier, vulnerability response, or software acquisition workflow.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
SLSA
is adopted when a producer, package ecosystem, consumer, contract, or internal policy requires a stated Source or Build level or verified supply-chain property. SLSA itself does not impose one target level or deadline on every project.
Official SLSA v1.2 source for the separate Source and Build tracks and their level requirements.
Operational implication
Record who set the SSDF scope and who set each target. Do not present a voluntary target as a legal duty or claim a higher SLSA level than the evidence supports.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Core obligations
NIST SSDF
NIST SSDF recommends that producers integrate applicable practices across PO, PS, PW, and RV into their software development life cycles (SDLCs). Applicability and implementation formality are risk-based; the publication does not prescribe one evidence format.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
SLSA
For the Build track, L1 requires provenance to exist; L2 adds a hosted build platform and authentic provenance; L3 adds stronger resistance to provenance forgery and isolation between builds. v1.2 also reintroduces a separate Source track, with levels for version control, history and provenance, continuous technical controls, and two-party review.
Defines Source levels for version control, history and provenance, continuous technical controls, and two-party review.
Operational implication
Record the track and level, because ' L3' without a track is ambiguous in v1.2. Apply every normative requirement for the claimed level; do not infer missing Source controls from a Build level.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
SLSA
evidence is claim-specific. Build evidence includes the artifact digest and provenance, plus producer and build-platform identity, a platform assessment, and a verification result when the stated claim requires them. Source evidence includes the source revision, a Source verification summary attestation (VSA) summarizing the security properties and level of the revision, source provenance for Source Level 2 or higher, repository controls, and evidence for the claimed Source level.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Operational implication
Index evidence by SSDF task and by track and level. Verify that the attestation subject matches the released artifact or source revision; a valid signature on unrelated or incomplete provenance is not enough.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Timing and cadence
NIST SSDF
NIST SSDF defines no general commencement or certification-renewal clock. Review at SDLC, release, supplier, vulnerability, and material-change points selected for the scope.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
SLSA
v1.2 sets technical requirements, not a universal adoption or renewal deadline. The adopting organization or ecosystem decides when provenance is generated, when verification occurs, how platform assessments are refreshed, and what happens when verification fails.
Defines SLSA as a specification with separate tracks and levels; an adopting organization or ecosystem supplies its own rollout and review schedule.
Operational implication
Set triggers for new source revisions, builds, releases, platform changes, signing-key changes, policy changes, and failed verification. Keep contractual deadlines separate from the specifications.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Enforcement or assurance route
NIST SSDF
NIST does not certify organizations against SSDF. The adopting program defines reviews, supplier checks, customer evidence, contract acceptance, or other assurance activities.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
SLSA
conformance is evaluated against the normative requirements for a stated track and level. Provenance authenticity, verification, and platform or source-control assessment support the claim, but the SLSA specification does not guarantee that the source code is benign or free of vulnerabilities.
Normative Build-track requirements for producers, build platforms, provenance authenticity, and isolation.
Operational implication
State the exact claim, verifier, policy, evidence, and covered revision or artifact. Avoid broad labels such as ' certified' or 'NIST certified' unless a separate named program authorizes them.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Overlap and reuse
NIST SSDF
SSDF tasks for protecting source, controlling development environments, preserving release integrity, recording provenance, and reviewing changes can draw on evidence when the scopes match.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
SLSA
Source and Build evidence can support selected SSDF outcomes, but SLSA does not replace secure design, secure coding, component-vulnerability review, security testing, disclosure, remediation, or root-cause analysis.
Defines Build-track producer, platform, provenance, authenticity, and isolation requirements.
Operational implication
Use a bridge row that names the SSDF task, track and level requirement, shared evidence, and remaining gap. Do not convert overlap into a claim of full equivalence.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Practical decision rule
NIST SSDF
Use NIST SSDF when the primary question is how a producer integrates secure-development outcomes across organization preparation, software protection, secure production, and vulnerability response, or when an identified acquirer or authority requests an SSDF task mapping.
Primary NIST source for comparing SSDF secure-development practices with SLSA software supply-chain provenance and artifact integrity expectations.
SLSA
Use when the deliverable is a Source or Build track level, a source or build provenance attestation, a platform assessment, or a verification result against a declared policy.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Operational implication
Use both for releases that need lifecycle-wide secure-development evidence and explicit source or build supply-chain claims. Keep a separate result for each SSDF task and each track and level.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
Practical decision rule
When should teams use NIST SSDF first versus SLSA first?
Use NIST SSDF first when you need a control-and-practice checklist for how software is developed, reviewed, or fixed, and you need named owners for those tasks.
Use first when you need a defined Source or Build track claim, provenance for a source revision or artifact, a platform assessment, or verification against policy.
Use both when the same release needs lifecycle-wide secure-development evidence and explicit source or build supply-chain assurance.
Official SLSA v1.2 specification for Source and Build tracks, levels, provenance, and verification.
1
Section 1
How should teams combine NIST SSDF and SLSA v1.2?
Choose the claim before collecting evidence. For SSDF, name the applicable practice and task, covered software, owner, and expected outcome. For , name the track, level, artifact or source revision, producer, platform, provenance, and verification policy. Keep separate results even when the same repository, build service, attestation, or release record supports both.
Use the Source track for claims about version control, source history and provenance, continuous technical controls, and two-party review.
Use the Build track for claims about build provenance, hosted builds, provenance authenticity, and build isolation.
Use SSDF for requirements, training, secure design and coding, component risk, security testing, release protection, vulnerability disclosure, remediation, and root-cause analysis.
Do not use a Build L3 claim as evidence that the source is secure, the code is vulnerability-free, or every SSDF task is complete.