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 the four practice groups explained

SSDF v1.1 contains 19 current practices and 42 tasks: five Prepare the Organization practices, three Protect the Software practices, eight Produce Well-Secured Software practices, and three Respond to Vulnerabilities practices.

The groups are not maturity levels or a sequence that ends at release. They form a connected lifecycle, and organizations tailor task applicability and implementation formality to risk.

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

SSDF v1.1 organizes secure software development into four : Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Each current practice contains one or more tasks, notional implementation examples, and references. The examples are optional and non-exhaustive. PW.3 appears in the table only as a retired identifier because Version 1.1 moved its work into other practices.

Section 1

Prepare the Organization (PO): make secure development possible

PO establishes the organizational conditions that the other groups depend on. It covers requirements, roles and training, toolchains, security-check criteria, and protected development environments.

PO evidence should show that teams maintain requirements, assigned responsibilities, proficiency, toolchain controls, check criteria, and protected development environments. NIST leaves terms such as "qualified person," "sensitive data," and environment names to each organization to define for its own use case.

  • PO.1 | Define and maintain internal and external security requirements for software development and organization-developed software.
  • PO.2 | Define software development life cycle (SDLC) roles and responsibilities and provide role-based training.
  • PO.3 | Specify, integrate, secure, monitor, and maintain supporting toolchains.
  • PO.4 | Define criteria for software security checks and gather and safeguard the information needed to apply them.
  • PO.5 | Separate and protect development environments and maintain their components and configurations.
Section 2

Protect the Software (PS): preserve code and release trust

PS addresses unauthorized access and tampering across source code, executable code, configuration, and other software forms. It also gives acquirers ways to verify that a release is legitimate and has not been altered.

A software bill of materials (SBOM) can be part of provenance data under PS.3.2, but an SBOM alone does not prove release integrity, secure development, or conformance with every SSDF practice.

  • PS.1 | Store code according to least privilege and protect it from unauthorized access and tampering.
  • PS.2 | Make integrity-verification information, such as appropriately published cryptographic hashes or signatures, available to acquirers.
  • PS.3 | Archive each release and collect, safeguard, maintain, and share provenance data for its components according to policy.
Section 3

Produce Well-Secured Software (PW): build security into the product

PW covers design through release configuration. It combines risk modeling and design review with component governance, secure coding, build configuration, human-readable code analysis, executable testing, and secure defaults.

The tasks call for organization-defined decisions. For example, PW.8.1 asks whether executable-code testing should be performed and which testing types should be used; SSDF does not mandate one scanner, severity threshold, or universal release gate.

  • PW.1-PW.2 | Model security risk, track requirements and design decisions, and review the design against them.
  • PW.4 | Acquire and maintain well-secured components, create reusable internal components where appropriate, and verify acquired components against organization-defined requirements throughout their life cycles. Version 1.1 retired PW.3: PW.3.1 moved to PO.1.3; the work from PW.3.2 is in final task PW.4.4 after PW.4.5 was merged into it.
  • PW.5-PW.6 | Follow appropriate secure coding practices and configure compilation, interpretation, and build processes to improve security.
  • PW.7-PW.8 | Review or analyze human-readable code and determine, scope, perform, document, and triage executable-code testing.
  • PW.9 | Configure software with secure settings by default and provide information that helps acquirers use the settings.
Section 4

Respond to Vulnerabilities (RV): close the loop after release

RV keeps vulnerability handling connected to development. Producers gather reports from acquirers, users, and public sources; investigate credible reports; assess and prioritize vulnerabilities; remediate them; communicate to affected acquirers; and use root-cause analysis to prevent recurrence.

A vulnerability disclosure policy is only the intake surface. Evidence should also show investigation, prioritization, remediation, advisory or customer communication where appropriate, and feedback into requirements, design, code, toolchains, and tests.

  • RV.1 | Gather vulnerability information continuously, investigate credible reports, and periodically identify software components with known vulnerabilities.
  • RV.2 | Assess, prioritize, remediate, and communicate vulnerabilities, retaining the decisions and remediation evidence.
  • RV.3 | Analyze root causes and feed the lessons into the SDLC to prevent similar vulnerabilities from recurring.
Section 5

Tailor tasks without breaking the lifecycle

NIST expects the degree and formality of implementation to vary. It says risk, cost, feasibility, applicability, and automatability can affect selection and implementation. A useful tailoring record states why each task is relevant, not applicable, inherited, supplier-performed, or deferred.

Keep the groups connected: PO criteria govern PW checks; PS provenance informs PW component decisions and RV monitoring; RV root-cause findings update PO requirements and PW design, coding, and testing.

  • Define the software, SDLC, release, environment, component, producer, supplier, and acquirer boundary.
  • Record the implementation status, risk rationale, owner, evidence, and any inherited responsibility for each of the 42 tasks.
  • Use the task statement as the outcome; use NIST's examples and references as implementation options, not an exhaustive mandatory list.
  • Reassess the mapping when architecture, toolchains, components, suppliers, threats, vulnerabilities, customer requirements, or authority changes.
Recommended next step

Put this NIST SSDF guidance into practice

Choose a practice group, identify its current tasks, and trace the upstream requirements and downstream evidence needed to keep the groups connected.

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 group boundaries, task ownership, evidence gaps, and the handoffs among PO, PS, PW, and RV.

Explore next step
Primary sources

References and citations

NIST SP 800-218 SSDF v1.1
doi.org6 citations
Referenced sections
  • Primary source for the four groups, 19 current practices, 42 tasks, optional implementation examples, tailoring principles, and Version 1.1 change log.
  • Table 1 defines PO.1 through PO.5 and their tasks; the table conventions explain that organizations must define contextual terms and enumerate their development environments.
  • Table 1 defines PS.1 through PS.3, including release integrity information, release archiving, and provenance data for release components.
Show 3 more
  • Table 1 defines the eight current PW practices (PW.1, PW.2, and PW.4 through PW.9); Appendix C records the retirement of PW.3 and the destinations of its tasks.
  • Table 1 defines RV.1 through RV.3 and connects intake, investigation, remediation, communication, and root-cause analysis.
  • Sections 2 and 3 explain risk-based tailoring, distributed responsibility, optional examples, and that table order does not imply sequence or relative importance.

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 implementation playbook

Implement final SSDF v1.1 by defining the software boundary, selecting applicable tasks by risk, assigning shared responsibilities, and retaining task-level 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.