What Is the NIST SSDF (Secure Software Development Framework, SP 800-218)?

The NIST Secure Software Development Framework (SSDF), published as Special Publication 800-218, is a set of high-level secure-software-development practices that any organisation can fold into its existing development lifecycle to reduce vulnerabilities in released software and limit the damage from the ones that remain. It is a shared vocabulary of outcomes, not a rigid methodology.

What the SSDF is — and is not

The SSDF deliberately does not tell you which tools to buy, which stages to run, or how to structure your team. Instead it describes outcomes that secure development should achieve, phrased so that an Agile shop, a DevOps pipeline and a waterfall project can all claim them in their own way. Each practice is paired with example tasks and references to other standards, but the practice itself is the stable part. This outcome-based design is what lets the framework sit on top of whatever lifecycle you already run rather than forcing you to replace it.

The four practice groups

The SSDF organises its practices into four groups that span the whole lifecycle:

• PO — Prepare the Organization. Establish the foundations for secure development: define security requirements, assign roles and responsibilities, provide training, and put the processes, toolchains and criteria in place before code is written.
• PS — Protect the Software. Protect source code and releases from tampering and unauthorised access, and give consumers a way to verify the integrity and provenance of what they receive — the supply-chain-integrity dimension.
• PW — Produce Well-Secured Software. The core engineering work: secure design (including threat modelling), secure coding practices, code review, security testing, and shipping with secure default configurations.
• RV — Respond to Vulnerabilities. Find, analyse, remediate and learn from vulnerabilities discovered after release, including a process for intake, disclosure and root-cause analysis so the same class of flaw does not recur.

Read together, the groups form a loop: prepare the organisation, protect the artefacts, build the software securely, and respond when something slips through — feeding lessons back into preparation.

Why the SSDF exists

The SSDF is a response to the software supply-chain crisis. A run of high-profile compromises made it clear that insecure development practices in widely used software create systemic risk — one compromised build or dependency can cascade across thousands of downstream organisations. In 2021, US Executive Order 14028 on improving the nation's cybersecurity directed NIST to produce guidance on secure software development practices for software purchased by the federal government.

The SSDF is NIST's consolidated, vendor-neutral answer: a single baseline that agencies and their suppliers can reference instead of each inventing their own. By phrasing it as outcomes rather than mandates, NIST made it usable as both an internal improvement framework and a procurement reference.

How it maps onto your SDLC

Adopting the SSDF does not mean reorganising how you build software. Because it is outcome-based, you map each practice onto the lifecycle you already have and fill the gaps:

• Planning and design. Secure design and threat modelling (PW) and security requirements (PO) land here.
• Implementation. Secure coding practices and code review (PW), plus protecting the code repository itself (PS). Credential hygiene — catching leaked keys with a secret scanner — supports both PW and PS.
• Testing and integration. Security testing (PW) using static, dynamic and composition analysis, as covered in our DAST explainer.
• Build and release. Release-integrity and provenance protections (PS) that let consumers verify what they receive.
• Operations. Vulnerability intake, triage, remediation and disclosure (RV).

The point is coverage, not conformance to a prescribed shape: can you show that each SSDF outcome is achieved somewhere in your process?

Attestation and why it matters beyond government

Following Executive Order 14028, the US government introduced a requirement for software producers selling to federal agencies to attest that their development practices align with the SSDF, via a self-attestation form. Attestation is a formal declaration — backed by the producer's own assurance — that the secure-development criteria are met.

The ripple effect is the important part. Because attestation is a condition of selling to one of the largest software buyers in the world, SSDF-aligned practices have become a de facto expectation across much of the market, not just within federal supply chains. A vendor that cannot demonstrate SSDF-aligned development increasingly struggles with enterprise customers too. In that sense the SSDF has quietly become a baseline for commercial secure development, carried outward from government procurement.

The takeaway

The SSDF is NIST's outcome-based framework for building software securely, organised into four practice groups — Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. It exists because of the supply-chain crisis and Executive Order 14028, it maps onto any SDLC because it describes outcomes rather than tools, and through federal attestation it has become a baseline expectation well beyond government. Treat it as a checklist of outcomes to prove, not a process to copy.

Frequently asked questions

What is the NIST SSDF? Special Publication 800-218: a set of high-level, outcome-based secure-development practices organisations fold into any lifecycle to reduce and contain vulnerabilities in released software.

What are the four practice groups? Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV) — spanning readiness, artefact integrity, secure engineering and post-release response.

Why does it exist? As a response to the software supply-chain crisis and US Executive Order 14028 (2021), which directed NIST to define secure-development guidance for software sold to the federal government.

How does it map to an SDLC? It describes outcomes, not stages or tools, so Agile, DevOps and waterfall teams map each practice onto their existing lifecycle and close the gaps.

What is SSDF attestation? A formal self-declaration that a producer follows SSDF-aligned practices, required to sell software to US federal agencies — which has made SSDF a de facto market expectation beyond government.