We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALNIST SP 800-218 SSDF

NIST SP 800-218 SSDF implementation playbook

Use SSDF v1.1 as an outcome-focused secure development framework: define the software and SDLC scope, tailor applicable practices by risk, assign responsibilities, and preserve evidence.

SSDF is normally voluntary NIST guidance, not a certification scheme or universal legal requirement. Contracts, procurement rules, agency policy, or other authorities can make selected outcomes or attestations binding in a particular context.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
5 sections1 primary sources
Overview

NIST SP 800-218 SSDF v1.1 is a core set of high-level practices that a can integrate into any software development life cycle (SDLC). Software acquirers can use the same vocabulary to state expectations and discuss evidence with suppliers. This playbook turns the four practice groups - Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV) - into a practical implementation sequence. The sequence is Sorena's synthesis; NIST does not prescribe an implementation order.

Section 1

Decide the scope, audience, and source of authority first

A useful SSDF scope names the producer, software or service, release family, development and build environments, third-party components, supporting suppliers, and the acquirer or customer expectations being addressed. Do not start from a claim that the whole organization is "SSDF compliant."

NIST says nongovernmental organizations may use SP 800-218 voluntarily. If a federal procurement rule, contract, policy, or customer questionnaire calls for an SSDF-based statement, record that separate authority and its exact scope; the SSDF publication itself does not create a universal certification or self-attestation program.

  • Producer: integrates applicable SSDF tasks into its SDLC and can explain how the outcomes are achieved.
  • Acquirer: expresses required or desired secure-development characteristics and evaluates supplier representations in the acquisition context.
  • Supplier: may provide components, tools, development services, or finished software; its obligations come from the applicable agreement or authority, not from the label alone.
  • Authority record: identifies whether the work is voluntary improvement, internal policy, contractual assurance, or a specific public-sector requirement.
Section 2

Tailor the 19 practices and 42 tasks by risk

SSDF does not prescribe one implementation method. It defines outcomes, tasks, notional examples, and references that teams can integrate into Agile, DevOps, waterfall, or other SDLC models.

Not every practice applies identically to every use case. NIST says selection and implementation can depend on risk, cost, feasibility, applicability, and automatability. A practical tailoring record classifies each task as applicable, not applicable, inherited, supplier-performed, or deferred and explains the decision.

  • PO | Establish requirements, roles, training, toolchains, check criteria, and protected development environments.
  • PS | Protect code and other software forms, make release-integrity verification available, and preserve release and provenance records.
  • PW | Address design risk, verify components, follow secure coding, configure builds, review and test code, and ship secure defaults.
  • RV | Receive and investigate vulnerability information, assess and remediate vulnerabilities, communicate fixes, and analyze root causes.
  • Tailoring record | Capture scope, task disposition, rationale, owner, evidence, open gap, approver, and review trigger.
Section 3

Connect tasks to operating evidence

Tie each claim to a named practice, task, software scope, owner, evidence period, and record location. That makes the claim reviewable without suggesting that one artifact proves all of SSDF.

Evidence varies by task. Examples include security requirements, role assignments, training records, toolchain and environment controls, design decisions, code-review and test results, release-integrity information, provenance or component records, vulnerability tickets, advisories, remediations, and root-cause analyses.

  • Accountable owner and deputy for each SSDF practice group or decision.
  • Evidence location, record type, version, reviewer, review date, and next review trigger.
  • Decision rationale showing why the selected depth is appropriate to risk and stakeholder expectations.
  • Open gaps with target state, priority, due date, and acceptance criteria.
  • Evidence of monitoring and response for vulnerabilities discovered after release.
Recommended next step

Put this NIST SSDF guidance into practice

Define the software scope, disposition each relevant task, assign owners, and identify the evidence and review trigger for each decision.

Assessment workflow
Open Assessment Autopilot for NIST SSDF

Create cited tasks, evidence requests, and review checkpoints for this NIST SSDF scope.

Explore next step
Talk to Sorena
Review this NIST SSDF scope with Sorena

Check the authority, scope, tailoring decisions, owners, evidence gaps, and next steps.

Explore next step
Section 4

Claims the evidence should not make

An organization-wide label hides the framework's task-level tailoring. Preserve the software boundary, task disposition, responsibility, evidence period, and limitations behind every representation.

Use SSDF identifiers to make representations precise. A statement such as "PW.8.2 is performed for releases in product family A" can be checked against a defined scope. SP 800-218 does not establish a NIST certification program, so do not label an internal mapping "NIST certified" or "NIST approved."

  • Do not turn NIST guidance or its February 2022 publication date into a statutory deadline.
  • Do not imply that Appendix A makes EO 14028 requirements universally applicable; it maps SSDF practices to Section 4e topics.
  • Do not describe an internal mapping as NIST certification or approval.
  • Do not map controls without documenting the expected outcome and evidence standard.
  • Do not use one generic assessment result for systems, suppliers, and releases with different risk profiles.
Section 5

Run implementation as a release-aware lifecycle

Tie SSDF work to software and releases: tailor tasks at intake, collect evidence in the SDLC, make release decisions, feed vulnerability findings back into development, and reassess after a material change.

Keep a scope and tailoring record, an evidence index, and owned remediation items. These are practical management records, not NIST-issued forms.

  • Step 1 | Authority and scope | Record why SSDF is being used and identify the producer, software, SDLC, release, environments, components, suppliers, and acquirer needs.
  • Step 2 | Tailor | Disposition each relevant PO, PS, PW, and RV task with a risk rationale and accountable owner.
  • Step 3 | Integrate | Put the selected tasks into engineering, build, release, procurement, disclosure, and vulnerability workflows.
  • Step 4 | Evidence | Link each claim to current operating records and identify inherited or supplier-provided evidence explicitly.
  • Step 5 | Review | Reassess after material architecture, toolchain, component, supplier, threat, vulnerability, or contractual change.
Primary sources

References and citations

NIST SP 800-218 SSDF v1.1
doi.org6 citations
Referenced sections
  • Primary source for SSDF scope, audience, voluntary nongovernmental use, risk-based tailoring, shared responsibility, four practice groups, tasks, examples, and EO 14028 mapping.
  • Sections 1 and 2 identify software producers and acquirers as target audiences, allow nongovernmental voluntary use, and describe distributed responsibility across providers and tenants.
  • Sections 1 and 2 explain that practices are risk-based, not prioritized, and may vary in degree and formality; Table 1 supplies the 19 practices, 42 tasks, optional examples, and references.
Show 3 more
  • Table 1 ties each task to outcomes and notional examples, including records and artifacts that can support implementation claims; the examples are optional rather than a universal evidence list.
  • Sections 1 and 2 state that SSDF focuses on outcomes, does not prescribe implementation, and uses risk-based tailoring; Appendix A maps EO 14028 Section 4e topics to SSDF practices and tasks.
  • Sections 1 and 2 support risk-based tailoring, distributed responsibility, integration throughout the SDLC, and feedback across the four practice groups.

Related guides

NIST SP 800-218 SSDF Evidence Guide

Build a task-level SSDF evidence index for internal assurance, customers, acquirers, and contract reviews without implying NIST certification.

NIST SP 800-218 SSDF FAQ: practical implementation questions

Practical answers on SSDF Version 1.1 code analysis, components, builds, release gates, provenance, threat modeling, coding evidence, and vulnerability response.

NIST SP 800-218 SSDF PO, PS, PW, and RV Practice Deep Dive

Map all 19 final SSDF v1.1 practices across PO, PS, PW, and RV, including each group's purpose, handoffs, tailoring decisions, and useful evidence.

NIST SP 800-218 SSDF SBOM and Provenance Workflow

Apply SSDF PS.3.2 to collect, protect, maintain, and share release-component provenance, including an SBOM, while keeping release integrity and component approval separate.

NIST SP 800-218 SSDF Secure Development Practices Guide

Place risk-tailored SSDF v1.1 tasks at the points where teams define requirements, design software, govern components, build, test, release, and respond to vulnerabilities.

NIST SP 800-218 SSDF Self-Attestation Guide

SSDF v1.1 does not require self-attestation. Check the requesting agency or contract: OMB rescinded the former government-wide mandate in January 2026.

Show all related guides (17)

NIST SP 800-218 SSDF Self-Attestation Workflow

Validate an SSDF-based attestation request, bound the covered software and producer, test each representation against evidence, and retain the signed submission.

NIST SSDF vs NIST SP 800-53 SA controls: practical side-by-side comparison

Map NIST SSDF tasks to SP 800-53 Rev. 5 SA controls without treating references, shared evidence, or partial overlap as full implementation.

NIST SSDF vs SLSA: practical side-by-side comparison

Compare NIST SSDF v1.1 with SLSA v1.2 Source and Build tracks, including scope, levels, evidence, provenance, verification, and limits.

How should teams handle code scanning under NIST SP 800-218 SSDF?

Decide which code review, analysis, and executable testing apply, then retain scope, results, triage, remediation, and exception records.

How should teams handle components under NIST SP 800-218 SSDF?

Evaluate third-party and in-house components, track source, version, provenance, approval, affected releases, maintenance, and known-vulnerability decisions.

How should teams handle release gates under NIST SP 800-218 SSDF?

Define risk-based release criteria, gather protected evidence, record approvals and exceptions, and bind the decision to the shipped artifact.

How should teams handle threat modeling under NIST SP 800-218 SSDF?

Use risk modeling to assess software risk, connect findings to security requirements and design decisions, and revisit the record when its assumptions change.

How should teams handle vulnerability disclosure under NIST SP 800-218 SSDF?

Run a documented path from vulnerability intake and credibility review through risk-based remediation, acquirer communication, and root-cause feedback.

What build-integrity evidence supports NIST SP 800-218 SSDF?

Connect each release to its protected build environment, approved tool configuration, integrity-verification data, provenance, and archived release record.

What secure coding evidence should teams keep for NIST SSDF SP 800-218?

Keep evidence that shows which secure coding practices applied, how code was reviewed or analyzed, what issues were found, and how each issue was handled.

Why does provenance matter in NIST SP 800-218 SSDF implementation?

SSDF provenance records component origin and change history for each release so acquirers, operations, and response teams can identify affected software.