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.

By Sorena AIPublished Updated

NIST SP 800-218 SSDF

NIST SP 800-218 SSDF

Use final NIST SP 800-218 to scope secure software development, tailor its 19 practices and 42 tasks by risk, assign responsibilities, and evaluate evidence.

Practices
19
Tasks
42
Mapped
EO 14028
Tailored
Risk-based

Understand NIST SP 800-218 SSDF

NIST SP 800-218 is the current final Secure Software Development Framework: 19 outcome-focused practices and 42 tasks that producers can integrate into any . Use it to decide what applies, who owns it, and what evidence supports the decision.

NIST published Version 1.1 on February 3, 2022. Nongovernmental organizations may use it voluntarily; a contract, policy, procurement rule, or other authority can separately require particular outcomes. NIST published Version 1.2 as a draft on December 17, 2025, so do not treat that draft as a replacement for final Version 1.1.

The SSDF states desired outcomes and does not prescribe one tool or implementation. Its examples are optional and non-exhaustive. Tailor applicability and formality to risk, then retain evidence close to the SDLC work that produced it.

Quick scan

Implementation playbook

How to scope software and SDLC boundaries, tailor applicable practices by risk, assign producers and suppliers, and preserve decisions.

Evidence for assurance

Which records support practice-level claims, while keeping customer, contractual, federal attestation, and internal assurance uses distinct.

Secure development practices

Task-level guidance for PO, PS, PW, and RV, including toolchains, components, release integrity, testing, disclosure, remediation, and root-cause learning.

Implementation decisions

  1. 1

    Translate SSDF tasks into engineering controls

    Start with the four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Select applicable practices and tasks by risk; the table order does not set implementation sequence or priority.

  2. 2

    Strengthen release integrity and provenance

    Connect requirements, roles, toolchains, protected environments, design and code checks, release integrity, provenance, component records, and vulnerability response to reviewable evidence.

  3. 3

    Prepare producer and supplier assurance

    Help state desired secure-development outcomes and help producers explain how their own teams and third-party suppliers address them without treating an SSDF mapping as certification.

Choose the next SSDF decision

New to the SSDF? Start with its status, audience, four groups, and risk-based tailoring. If the scope is already settled, jump to implementation evidence, supplier communication, or a focused engineering question.

Start here: scope and practice structure

Understand what is, who uses it, why it is normally voluntary guidance, and how its 19 practices and 42 tasks are organized into PO, PS, PW, and RV.

Implementation and evidence

Translate selected practices into owned SDLC work and retain evidence that supports a specific scope, practice, task, release, and risk decision.

Producer, acquirer, and supplier assurance

Use SSDF vocabulary in acquisition and assurance without assuming that SP 800-218 itself creates a universal attestation, certification, or legal deadline.

Compare related frameworks or answer a focused question

See how SSDF relates to SP 800-53 system controls and SLSA supply-chain assurance, or go directly to implementation FAQs.

Sources

Next steps

Apply SSDF to a defined software scope

Choose the software, release process, and applicable SSDF tasks before requesting evidence or assigning remediation work.

  • Record why SSDF is being used and which producer, product, environments, components, suppliers, and acquirer needs are in scope.
  • Assign each selected task to the team that performs the work and identify the evidence it produces.
  • Keep tailoring decisions, evidence, exceptions, and review triggers with the software scope they support.
  • Reassess the mapping after a material change to the architecture, toolchain, supplier, threat, or requirement.
  • Open Assessment Autopilot

    Turn selected SSDF tasks into owned work, evidence requests, and review checkpoints.

  • Open SSOT

    Keep SSDF decisions, evidence, exceptions, and control records in one governed system.

  • Talk through implementation

    Review your current process, evidence model, and next implementation steps.