NIST Secure Software Development Framework (SSDF)

The NIST Secure Software Development Framework (SSDF), formally published as NIST Special Publication 800-218, establishes a core set of high-level secure software development practices organized into discrete practice groups. Mandated for federal agencies and their software suppliers under the May 2021 Executive Order 14028 on Improving the Nation's Cybersecurity, the SSDF has become the primary federal reference standard for software producers seeking to demonstrate supply-chain security posture. This page describes the framework's structure, operational mechanics, applicable scenarios, and the boundaries that determine when and how it applies relative to adjacent standards such as the Application Security Providers landscape it intersects with.

Definition and scope

NIST SP 800-218, published by the National Institute of Standards and Technology in February 2022, defines the SSDF as a set of fundamental, sound practices for secure software development (NIST SP 800-218). The framework is not a checklist or a certification scheme — it is a practice-based reference that organizations map against their existing software development lifecycle (SDLC) controls to identify gaps and demonstrate conformance.

The SSDF's scope covers any organization that develops or maintains software, including commercial software producers, open-source maintainers, and federal agencies developing custom systems. Its four primary practice groups define the full coverage boundary:

1. Prepare the Organization (PO) — Establishes organizational roles, tooling, and processes to support secure development. Includes defining security requirements for the SDLC and supplying developers with training and adequate security tooling.
2. Protect the Software (PS) — Addresses protecting all components of a software project from unauthorized access and tampering, including source code repositories, build pipelines, and distribution mechanisms.
3. Produce Well-Secured Software (PW) — Covers design, coding, testing, and vulnerability remediation practices that reduce defect density. This group includes threat modeling, static analysis, and code review requirements.
4. Respond to Vulnerabilities (RV) — Defines processes for identifying, disclosing, and remediating vulnerabilities discovered after release, including coordinated vulnerability disclosure aligned with ISO/IEC 29147.

Each practice within these groups carries a unique identifier (e.g., PW.4.1 for reusing secure, well-tested software components) and is cross-referenced to over 20 other standards including ISO/IEC 27001, the OWASP Software Assurance Maturity Model (SAMM), and NIST SP 800-53 Rev. 5.

How it works

The SSDF is implemented through a mapping exercise rather than a prescriptive audit protocol. Organizations document their existing SDLC practices, map those practices to the relevant SSDF practice identifiers, and identify gaps where controls are absent or insufficient. The framework specifies 4 practice groups, 19 practices, and 42 tasks as of the 2022 publication.

NIST designed the framework to be technology-agnostic and process-agnostic. A team using Agile sprints and a team using waterfall development apply the same practice identifiers; the evidence of conformance differs by method but the outcome requirements remain constant.

Federal procurement is the primary compliance driver. The Office of Management and Budget (OMB) Memorandum M-22-18, issued September 2022, required federal agencies to collect self-attestations and, for critical software, third-party assessments from software producers confirming conformance with the SSDF (OMB M-22-18). OMB M-23-16 subsequently extended deadlines and clarified artifact collection requirements for agencies. Software producers supplying the federal government complete a Secure Software Development Attestation Form developed jointly by CISA and OMB, which directly references SSDF practice identifiers as the attestation baseline.

For organizations integrating SSDF into a broader application security program, the implementation sequence typically follows this order:

Common scenarios

Federal software suppliers represent the highest-urgency adoption segment. Any commercial vendor whose software is used by a federal civilian executive branch agency must submit a completed attestation form to that agency. Agencies procuring software defined as "critical" under EO 14028 — software that performs security functions, runs with elevated privileges, or has direct access to networks — must obtain third-party assessments rather than self-attestations alone.

FedRAMP cloud service providers encounter the SSDF through FedRAMP's alignment with OMB M-22-18. Cloud platforms authorized under FedRAMP and subject to recurring assessment must demonstrate SSDF-aligned development practices as part of their continuous monitoring obligations.

Financial services technology developers building applications subject to FFIEC guidance or OCC standards increasingly reference SSDF conformance as a third-party risk management signal when evaluating software vendors, even absent direct federal procurement relationships.

Open-source maintainers contributing to projects embedded in federal supply chains may receive SSDF-related inquiries from downstream integrators performing software composition analysis. NIST SP 800-218A, published in 2023, extends SSDF guidance specifically to AI model development, expanding the framework's applicability to machine-learning pipeline security.

Decision boundaries

The SSDF is a practice framework, not a certification program. No "SSDF certified" credential exists; conformance is demonstrated through attestation documentation or third-party assessment artifacts, not a pass/fail audit against a fixed scoring rubric. This distinguishes it from standards like ISO/IEC 27001 (which carries formal certification through accredited bodies) and from compliance regimes like PCI DSS (which uses qualified security assessors and explicit audit findings).

The SSDF overlaps substantially with OWASP SAMM (Software Assurance Maturity Model) at the practice level, but the two serve different primary purposes. OWASP SAMM provides a maturity scoring model across five business functions with 15 security practices, enabling organizations to benchmark progress along a 0–3 maturity scale. The SSDF does not assign maturity scores — it defines minimum acceptable practices. Organizations using SAMM for internal capability measurement and SSDF for federal compliance reporting operate both frameworks in parallel without redundancy conflicts. The reference explains how these frameworks intersect within broader appsec program structures.

A critical boundary concerns the difference between SSDF applicability and SSDF enforcement. The framework applies broadly to any software development organization; enforcement through attestation requirements, contract clauses, or agency acquisition policy applies narrowly to the federal procurement channel. State-level software procurement requirements and international equivalents (such as the EU Cyber Resilience Act) reference similar practice domains but operate under separate legal authorities.

Organizations assessing whether SSDF conformance is operationally necessary should evaluate three threshold factors: whether the software will be sold or licensed to a US federal civilian agency, whether the software qualifies as "critical" under EO 14028 definitions, and whether contractual terms in federal acquisition instruments (FAR/DFARS clauses) explicitly reference OMB M-22-18 attestation requirements. When all three conditions are met, attestation is mandatory. For organizations navigating how this framework intersects with vendor qualification, the how to use this application security resource reference page describes the service-sector context for framework-aligned security providers.