The NIST Secure Software Development Framework (SSDF), published as Special Publication 800-218, has quietly become one of the most consequential documents in software compliance — because it is the standard federal software producers now attest to, and the reference other regimes borrow. Yet it is often described vaguely. This guide walks through what the SSDF actually is, organised the way the framework itself is: by its four practice groups.
What the SSDF is
The SSDF is a set of fundamental, sound secure software development practices, derived from established guidance and organised into a common vocabulary. Crucially, it is not prescriptive about tools or techniques. It describes outcomes — practices and tasks — and leaves implementation to you, which makes it applicable to any development methodology or technology stack.
Version 1.1 (SP 800-218) is the current core reference, with a companion profile (SP 800-218A) addressing generative-AI model development. The framework's practices are grouped into four families, each identified by a two-letter prefix.
PO — Prepare the Organization
The Prepare the Organization group is about setting up your people, processes, and technology to develop securely before writing code. It asks you to define security requirements for your software and infrastructure (PO.1), assign roles and responsibilities and train people to fulfil them (PO.2), and establish a secure, well-instrumented toolchain that produces artifacts and evidence (PO.3, PO.4). In practice this is where an organisation decides its remediation SLAs, its criteria for acceptable risk, and the tooling that will generate the evidence the other groups depend on.
PS — Protect the Software
Protect the Software focuses on protecting your code and release artifacts from tampering and unauthorised access. It covers protecting code from unauthorised change (PS.1), providing a mechanism for consumers to verify software integrity such as signing (PS.2), and archiving and protecting each release along with the data needed to reproduce and analyse it later (PS.3). This group is the SSDF's answer to SolarWinds-style pipeline tampering — it is not enough to write secure code if an attacker can alter it between commit and release.
PW — Produce Well-Secured Software
Produce Well-Secured Software is the largest group and the one developers feel most directly. It spans designing software to meet security requirements and mitigate risks (PW.1), reviewing the design (PW.2), reusing well-secured software such as vetted components rather than reinventing them (PW.4), writing source code following secure practices (PW.5), configuring build processes to improve security (PW.6), reviewing and analysing code for vulnerabilities (PW.7), and testing executable code (PW.8). PW.4 is where third-party component management — and by extension the SBOM — lives: you are expected to acquire and maintain well-secured components and track them.
RV — Respond to Vulnerabilities
Respond to Vulnerabilities recognises that no software ships perfect. It requires identifying and confirming vulnerabilities on an ongoing basis (RV.1), assessing and remediating them (RV.2), and analysing them to identify root causes and prevent recurrence (RV.3). This is continuous work: it applies to components after release, which is precisely why a one-time scan does not satisfy the intent. A newly disclosed CVE in a dependency you shipped last year is an RV obligation today.
The RV group is also where teams most often underestimate the operational burden. RV.1 assumes you have a reliable feed of vulnerability intelligence and a way to determine whether each disclosure affects your software — which is impossible without the component inventory PW.4 asks for. RV.2 then expects you to make a documented remediation decision, whether that is patching, mitigating, or accepting the risk with justification. Auditors and assessors reviewing an SSDF attestation look for exactly this chain of evidence: disclosure identified, exposure evaluated, action taken, and a date on each step.
Why it matters beyond NIST publications
The SSDF is the reference standard behind the U.S. federal secure software development attestation: producers selling to the government attest that they follow SSDF-aligned practices, using the form CISA and OMB published. Because federal procurement sets market norms, SSDF alignment increasingly appears in private contracts and maps neatly onto other frameworks' secure-development expectations.
SSDF readiness checklist
| Practice group | Evidence to have ready |
|---|---|
| PO — Prepare the Organization | Documented security requirements, roles, training records, toolchain |
| PS — Protect the Software | Access controls on code, artifact signing, release archiving |
| PW — Produce Well-Secured Software | Component inventory/SBOM, code review and SCA results, secure build config |
| RV — Respond to Vulnerabilities | Continuous vulnerability identification, remediation records, root-cause analysis |
How Safeguard helps
Safeguard produces evidence across the practice groups where software supply chain risk concentrates — PW and RV — and feeds the toolchain PO expects. Under PW.4, SBOM Studio maintains the inventory of third-party components you rely on, generated per build so "reuse well-secured software" is backed by a record of exactly what you reused. Software composition analysis covers PW.7's analysis of components for vulnerabilities and, critically, the ongoing RV.1 and RV.2 work of identifying and remediating them long after release.
The Safeguard CLI wires these checks into your build (PO.3, PW.6), so the evidence is generated automatically rather than assembled for an attestation. Griffin AI supports RV.2 by triaging findings against your code and prioritising genuinely exploitable issues, with root-cause context that supports RV.3. Our compliance pages map each capability to specific SSDF tasks so you can show which practice each one evidences.
The SSDF's genius is that it describes outcomes, not products. Meet the outcomes with evidence generated by your normal workflow, and attestation stops being a fire drill.
See how SSDF evidence falls out of your pipeline. Sign up free or read the Safeguard documentation to connect a project.