NIST SSDF (SP 800-218)

The four practice groups

The SSDF organizes its practices into four groups. Each practice states an outcome, and NIST is explicit that it is not a checklist: it is a basis for planning based on risk.

Group	Goal	Examples
Prepare the Organization (PO)	People, processes and tools are ready	Define security requirements, assign roles, secure the development environment
Protect the Software (PS)	Code and releases are safe from tampering	Protect all forms of code, verify release integrity, archive each release
Produce Well-Secured Software (PW)	Few vulnerabilities in what you release	Design for security, reuse well-secured software, review and test code
Respond to Vulnerabilities (RV)	Find remaining flaws and deal with them	Identify vulnerabilities continuously, prioritize and fix them, analyze root causes

The practices that touch your supply chain

• PO.3, supporting toolchains, and PO.5, secure environments. Your CI system is part of what you must protect. See the CI/CD pipeline security checklist.
• PS.3, archive and protect each release. This includes collecting provenance data for the components of each release, and the SSDF names the SBOM as a way to do that.
• PW.4, reuse well-secured software. Third-party components should be vetted and kept up to date, which is where software composition analysis fits.
• RV.1, identify vulnerabilities on an ongoing basis. This is an ongoing duty, not a release gate, so it calls for monitoring what you already shipped.
• RV.2, assess, prioritize and remediate. See how to prioritize vulnerabilities.

Is the SSDF mandatory?

Not in itself. It is a NIST publication, not a law. For a few years it mattered directly to US federal suppliers, because OMB memos M-22-18 and M-23-16 required them to attest to practices drawn from it. That changed on January 23, 2026: OMB memo M-26-05 rescinded both and moved to a risk-based approach. Agencies may still use the common attestation form and NIST's standards, but they are no longer required to, so suppliers should expect requirements to vary by agency.

Outside federal procurement, the SSDF remains useful as a shared language. Customers borrow from it in security questionnaires, and it maps to other standards.

SSDF versions

• Version 1.1, SP 800-218, published in February 2022, is the current final version.
• Version 1.2, SP 800-218 Revision 1, was published as a draft in December 2025.
• SP 800-218A is a community profile that extends the SSDF to generative AI and dual-use foundation models.

How to adopt the SSDF

1. Map what you do today. Go through the practices and record where you already meet them, and with what evidence.
2. Rank the gaps by risk. The SSDF expects you to apply it according to your own risk, so not every practice deserves the same depth.
3. Automate the evidence. Evidence that comes out of the pipeline stays current without extra work. Evidence written by hand goes stale.
4. Assign owners. Each practice needs someone responsible. Most will sit with engineering rather than security.
5. Review at set intervals. Update the mapping as your tools change and as version 1.2 progresses.

SSDF, SLSA and the CRA

The SSDF says what a secure development program should achieve. SLSA goes deep on one part of it, build integrity. The EU Cyber Resilience Act is a law with obligations of its own. Work done for one carries over to the others, because all of them expect you to know what is in your software and to handle vulnerabilities in it.

Where CRACI fits

The SSDF is a broad program, and no tool covers it. CRACI supplies evidence for the practices that depend on the build and on what shipped: SBOMs from each GitHub Actions job, isolated jobs and egress control in the build environment, ongoing monitoring of shipped software, and triage of what it finds. CRACI does not make you conformant, and the mapping and attestation stay with you. See software supply chain security with CRACI.

NIST SSDF: frequently asked questions

What is the NIST SSDF?

The Secure Software Development Framework, published as NIST SP 800-218. It is a set of practices for building secure software, organized into four groups: prepare the organization, protect the software, produce well-secured software and respond to vulnerabilities.

What does SSDF stand for?

Secure Software Development Framework.

Is the SSDF mandatory?

No. It is guidance, not law. US federal suppliers used to have to attest to practices from it, but OMB memo M-26-05 rescinded that requirement in January 2026. Agencies may still ask for attestations.

What is the latest version of the SSDF?

Version 1.1 (SP 800-218, February 2022) is the current final version. Version 1.2 was published as a draft in December 2025, so check NIST's site for its status.

What is the difference between the SSDF and SLSA?

The SSDF covers secure development as a whole, across people, process and technology. SLSA goes deep on build integrity and provenance. They work well together.

Does the SSDF require an SBOM?

It asks you to collect and share provenance data for the components of each release, and names an SBOM as one way to do it. It describes outcomes rather than mandating a specific tool.