NIST SSDF (SP 800-218): the four practice groups, explained

The Secure Software Development Framework (SSDF) is NIST Special Publication 800-218, "Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities," published in February 2022. Unlike a certification scheme, it is written as a set of named outcomes, not a pass/fail control catalogue: NIST's SSDF project page describes the goal as helping organisations "reduce the number of vulnerabilities in released software, reduce the potential impact of exploitation of undetected vulnerabilities, and address root causes" of vulnerabilities, while giving software producers and acquirers a shared vocabulary for secure-development conversations.

The four practice groups

NIST's SSDF project page organises every practice under four groups, each with its own stated purpose:

Group	Abbreviation	Purpose, as stated by NIST
Prepare the Organization	PO	"Ensure that the organization's people, processes, and technology are prepared to perform secure software development"
Protect the Software	PS	"Protect all components of the software from tampering and unauthorized access"
Produce Well-Secured Software	PW	"Produce well-secured software with minimal security vulnerabilities in its releases"
Respond to Vulnerabilities	RV	"Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities"

Read in order, the four groups form a lifecycle rather than a checklist: PO gets the organisation ready before any code is written, PS keeps the source and build pipeline itself trustworthy, PW is where the bulk of day-to-day secure-coding, design and testing practices sit, and RV closes the loop once a vulnerability is found after release, whether by the producer, a researcher or a customer.

Why it exists: Executive Order 14028

NIST's SSDF project page states that SP 800-218 includes explicit mappings from Executive Order 14028, "Improving the Nation's Cybersecurity," Section 4(e) clauses, to the SSDF practices and tasks that address each provision. That mapping is what ties a voluntary NIST framework to US federal software procurement in practice: agencies and the vendors that sell software to them use the SSDF as the reference point for the secure-development practices EO 14028 calls for. This guide did not independently re-verify, against a primary OMB or federal-procurement source this run, the specific mechanics of any self-attestation requirement tied to EO 14028; several secondary sources describe a mandatory producer self-attestation tied to SSDF conformance, but that detail is to be confirmed against official OMB/CISA guidance before being treated as settled here.

SP 800-218A: the generative AI profile

In July 2024, NIST published SP 800-218A, "Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile." It is explicitly a companion, not a replacement: NIST states it "should be used in conjunction with" SP 800-218, adding practices, tasks, recommendations, considerations, notes and informative references specific to the development lifecycle of AI models. NIST developed it to fulfil an Executive Order requirement for a companion resource to the SSDF covering generative AI and dual-use foundation models, aimed at producers of AI models, producers of AI systems built on those models, and the organisations acquiring them.

How SSDF differs from CISA's Secure by Design

SSDF and CISA's Secure by Design guidance are both frequently cited in the same breath, but they are structurally different things. SSDF is NIST's named set of practices and tasks (PO, PS, PW, RV) that a team can map its own lifecycle against, with a direct line to EO 14028's federal procurement requirements. Secure by Design is CISA-led guidance built around three principles and a voluntary pledge to seven measurable goals, with no PO/PS/PW/RV structure of its own; see CISA Secure by Design: principles and the pledge, explained. A software or firmware team can, and arguably should, work to both: SSDF for a lifecycle-mapped set of practices, and Secure by Design for the organisational principles and a public commitment customers can point to.

How this connects to a firmware SBOM

Several SSDF practices under Produce Well-Secured Software (PW) concern third-party and open-source component review, which is exactly what a software bill of materials evidences for a given release. For firmware, where source code is frequently unavailable to the team doing the security review, building that component inventory from the compiled binary is its own discipline; see firmware SBOM: building one when you don't have the source.

A workable starting point

1. Map your existing lifecycle to PO/PS/PW/RV before adding new process. Most teams already do pieces of several groups; the SSDF's value is naming the gaps, not replacing what already works.
2. Treat PW as the biggest group and budget accordingly. NIST's own practice list concentrates the largest share of day-to-day secure-coding, design review and testing practices under Produce Well-Secured Software.
3. Don't assume self-attestation mechanics without checking the current federal guidance. EO 14028's procurement link to SSDF is confirmed by NIST's own mapping; the attestation process details are not independently confirmed in this guide and change as OMB and CISA guidance is updated.
4. If you build or ship AI models, read SP 800-218A alongside SP 800-218, not instead of it.

SoftWSP's firmware SBOM and vulnerability-handling work maps directly onto several SSDF practices under Protect the Software and Respond to Vulnerabilities, whether or not your organisation sells to the US federal government: see device firmware security and PSIRT as a service.

This guide is general information, not legal advice.