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.
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.
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.
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.
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.
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.
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 SDLCs. Applicability and implementation formality are risk-based; the publication does not prescribe one evidence format.
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.
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.
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 VSA, source provenance for Source Level 2 or higher, repository controls, and evidence for the claimed Source level.
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.
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.
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.
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.
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.
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.
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.
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.
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.
SSDF covers organizational preparation, protection of software and development environments, secure software production, and vulnerability response across the software lifecycle.
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.
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.
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.
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.
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.
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 SDLCs. Applicability and implementation formality are risk-based; the publication does not prescribe one evidence format.
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.
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.
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 VSA, source provenance for Source Level 2 or higher, repository controls, and evidence for the claimed Source level.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Use the cited sources to make this page operational: define the exact SSDF scope, assign owners, list required artifacts, and set the review gate before moving forward.