TL;DR — the NIST SSDF in one paragraph
The NIST Secure Software Development Framework (SSDF), published as SP 800-218, is a set of secure development practices in four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities. It is methodology-agnostic, so it maps onto whatever SDLC you already run. It is voluntary in theory but effectively required to sell software to the US government, and it has become the common language for enterprise security reviews and software supply chain assurance in 2026.
What is the NIST Secure Software Development Framework (SSDF)?
The NIST Secure Software Development Framework (SSDF) is a set of high-level, methodology-agnostic secure development practices published by the US National Institute of Standards and Technology as Special Publication 800-218. Rather than prescribe tools or a life cycle, the SSDF describes the outcomes of good secure development and groups them into four practice families. Version 1.1 defines 19 practices broken into 42 tasks, each with references to established sources such as OWASP and BSIMM. Because it is outcome-based, the same framework fits an Agile team, a DevOps pipeline or a Waterfall programme.
The framework matters most where software carries regulatory, financial or safety weight, which is why regulated organisations building with our secure enterprise software development teams treat SSDF conformance as a baseline for entering federal and large-enterprise markets. The SSDF does not replace your development process; it gives you a shared vocabulary to demonstrate that the process is secure. If you want the delivery process the framework sits on top of, our secure software development life cycle guide walks through the phases; here we focus on the NIST framework itself — what it demands and how to prove you meet it.
Why the SSDF exists: EO 14028 and the software supply chain
The SSDF exists because attacks moved from individual applications to the software supply chain, and the US government needed one standard for what "secure development" means. High-profile compromises of build systems and widely used components showed that a single tampered dependency or pipeline could reach thousands of downstream organisations at once. In May 2021, US Executive Order 14028 directed NIST to define secure development practices for software sold to the federal government, and the SSDF (SP 800-218, finalised February 2022) is the result.
That origin explains the framework's shape. It puts heavy weight on protecting the build pipeline and verifying third-party components — the exact links attackers exploit — rather than only on the application code a developer writes. It also explains why the SSDF became a procurement instrument: because the federal government is the largest single software buyer, a framework tied to its purchasing quickly becomes a de facto industry expectation. For the runtime controls that complement framework-level practices, our web app security best practices guide covers what to harden in the application itself.
The four SSDF practice groups: PO, PS, PW, RV
The NIST SSDF organises all its work into four practice groups, and understanding them is the fastest way to understand the framework. Each group answers a different question: are you set up to develop securely, is your software and its build protected, is the software itself produced securely, and can you respond when something is found? Version 1.1 spreads 19 practices and 42 tasks across these four groups. The table summarises what each one covers.
| Practice group | What it covers | Example activities |
|---|---|---|
| PO — Prepare the Organization | People, processes and tools are ready to develop securely | Define security requirements, train developers, set up secure toolchains and roles |
| PS — Protect the Software | Code and build systems are protected from tampering and their integrity is verifiable | Access-controlled source storage, artefact signing, provenance and integrity verification |
| PW — Produce Well-Secured Software | The largest group: build software with minimal vulnerabilities | Secure design and threat modelling, secure coding, third-party and SBOM review, testing before release |
| RV — Respond to Vulnerabilities | Find, disclose and remediate vulnerabilities after release | Vulnerability intake and disclosure, root-cause analysis, timely patching |
Read in order, the groups tell a story: PO gets the organisation ready, PS protects the code and pipeline, PW produces the software securely, and RV closes the loop when a vulnerability surfaces. Most of the day-to-day engineering effort — threat modelling, secure coding, dependency review, testing — lives in PW, which is why it holds the most practices. PS is the group most directly born of supply chain attacks: it is where signing, provenance and build-system protection live. Do not treat the practices as a maturity ladder; they are outcomes to achieve continuously, not stages to pass once.
What changed in 2025–2026: attestation and EO 14306
The biggest recent change is that the enforcement mechanism around the SSDF was loosened in 2025, while the obligation to follow the framework stayed. After EO 14028, CISA released a Secure Software Development Attestation Form in March 2024, and OMB memoranda M-22-18 and M-23-16 required federal agencies to collect that attestation from their software producers. Then, in June 2025, Executive Order 14306 removed the requirement for CISA to centrally validate attestations and struck the associated Federal Acquisition Regulation update.
The practical effect for software producers in 2026 is subtle but important: the centralised validation step is gone, but the expectation that you conform to the SSDF and can produce auditable evidence is not. Agencies can still request the attestation form, and enterprise buyers increasingly ask for the same evidence regardless of any federal mandate. NIST has also continued to develop the framework — a companion profile, SP 800-218A, extends the SSDF to AI systems, and work on SP 800-218 Rev. 1 refreshes the practices. Treat the version numbers and the attestation mechanics as a moving target; treat the four practice groups as the stable core you build policy around.
SBOM: proving what is in your software
A software bill of materials (SBOM) is the single artefact that most directly demonstrates several SSDF practices, so it is worth calling out on its own. An SBOM is a machine-readable inventory of every component and dependency in a build — the ingredient list for your software. The SSDF's Produce Well-Secured Software (PW) practices require you to acquire, verify and track third-party and open-source components, and the Respond to Vulnerabilities (RV) group requires you to react when one of them is found to be vulnerable. An SBOM is what turns both from aspiration into something you can prove.
The concrete payoff shows up on the worst day. When a serious vulnerability is disclosed in a popular library, the question every buyer and regulator asks is "are you affected, and where?" Without an SBOM, answering means an audit under pressure. With one generated and retained per release, it is a lookup. That is why an SBOM per release — in a standard format such as SPDX or CycloneDX — has become a baseline expectation for federal and enterprise buyers assessing SSDF conformance, not an optional extra.
Who must comply with the NIST SSDF?
Any organisation that produces software for the US federal government is, in practice, expected to conform to the NIST SSDF — and a growing set of enterprise buyers expect it too. The framework is voluntary as a NIST publication, but the procurement rules built on top of it make conformance a condition of doing business in several markets. The groups most affected are below.
- Federal software producers. Companies selling software, or software-as-a-service, to US agencies must provide a secure software development attestation, backed by SSDF-aligned practices and evidence.
- Vendors to federal contractors. If your software is embedded in a product a prime contractor sells to the government, the SSDF expectation typically flows down to you.
- Enterprise SaaS and platform vendors. Large enterprise buyers increasingly reference the SSDF in security questionnaires and vendor reviews, independent of any federal tie.
- Regulated-industry software. Producers in finance, healthcare and critical infrastructure use the SSDF alongside sector rules to evidence secure development to auditors.
If none of these describe you today, the framework is still worth adopting as a well-structured baseline — but the urgency scales with how close you are to federal or large-enterprise buyers. For the neighbouring assurance frameworks buyers ask about, see our guide to SOC 2 Type II for SaaS startups, which pairs naturally with an SSDF programme.
How to implement the SSDF: a step-by-step path
The fastest way to adopt the SSDF is to map your current process to it first, then close the gaps — not to rebuild your development life cycle around the framework. Most teams already do much of what the SSDF asks; the work is making it explicit, consistent and evidenced. These are the practical steps, in order.
- Map your current practices to the four groups. Take PO, PS, PW and RV and note, honestly, what you already do for each. This gap analysis is the whole project in miniature and usually shows you are further along than expected.
- Assign an owner to each practice. Every SSDF practice needs a named role accountable for it. Unowned practices are the ones that lapse under deadline pressure.
- Protect the pipeline (PS). Lock down source and build systems, control access, and sign your artefacts so their integrity and provenance can be verified. This is the group most attackers target and the one buyers scrutinise most.
- Automate PW in the pipeline. Wire secure coding checks, static analysis, dependency and SBOM generation into CI/CD so they run on every change rather than in a quarterly review.
- Stand up vulnerability response (RV). Publish an intake and disclosure route, and set patching SLAs by severity so response is a defined process, not an improvisation.
- Write it down as policy and collect evidence. Document each practice, the tool or gate that enforces it, and where the evidence lives. This documentation is what an attestation and an audit rest on.
Run those steps and the SSDF stops being a compliance burden and becomes a description of how you already work. The build process the automation attaches to is covered in our custom software development process guide, and the engineering habits that satisfy PW sit in our software development best practices guide.
SSDF vs the secure SDLC and other frameworks
The SSDF is a framework of outcomes; a secure SDLC is your process, and other standards serve adjacent purposes — so they complement rather than compete. Teams new to the space often ask whether the SSDF replaces their secure SDLC, OWASP SAMM or SOC 2. It does not. You run a secure SDLC day to day, use the SSDF as the common attestation language, and reach for maturity models or audit standards when you need to measure or certify. The table places each one.
| Framework / standard | What it is | Where it fits |
|---|---|---|
| NIST SSDF (SP 800-218) | Outcome-based secure development practices in four groups | The attestation language for federal and enterprise buyers |
| Secure SDLC | Your delivery process with security built into each phase | How you actually develop, day to day |
| OWASP SAMM | A maturity model for software assurance | Measuring where you are and planning improvement |
| SOC 2 / ISO 27001 | Independent audit and certification of controls | Proving your controls to buyers via a third party |
The clean mental model is layered: your secure SDLC is the practice, the SSDF is how you describe and attest to it, and OWASP SAMM or SOC 2 measure or certify it. Because the SSDF explicitly draws on OWASP and BSIMM, adopting it does not mean discarding work you have already done under those models — it means expressing it in the language federal and enterprise procurement now expects.
SP 800-218A: the SSDF for AI systems
If you build AI or generative-AI systems, NIST SP 800-218A extends the SSDF to cover the risks that traditional software does not have, without replacing the core framework. Released in 2024 as a companion profile, SP 800-218A keeps the same four practice groups and layers on tasks specific to AI model development — the threats that emerge when your software is trained rather than only coded. You keep the SSDF you already implement and add these practices on top.
In practice, the additions cluster around data and models. Training-data integrity and provenance become part of Protect the Software; model poisoning, data poisoning and model exfiltration become threats to model in Produce Well-Secured Software; and monitoring for model-specific abuse extends Respond to Vulnerabilities into production. If you are shipping AI features, pair this with our generative AI integration services for the engineering side and the EU AI Act compliance checklist for the regulatory side in the European market.
NIST SSDF compliance checklist
Most SSDF programmes fail on the mundane: a practice with no owner, a policy never wired into the pipeline, or an attestation with no evidence behind it. This checklist keeps the essentials visible:
- Map every practice to an owner. Each of the four groups' practices needs a named role, or it becomes nobody's job when the schedule tightens.
- Protect and sign your build (PS). Access-controlled source, a hardened pipeline and signed artefacts are the supply chain controls buyers scrutinise first.
- Automate secure checks in CI/CD (PW). Static analysis, dependency scanning and SBOM generation that run on every change beat any quarterly manual review.
- Generate and retain an SBOM per release. It is the artefact that answers "are we affected?" in minutes instead of days.
- Run a real vulnerability response (RV). A published intake and disclosure route plus patching SLAs by severity make response a process, not an improvisation.
- Document policy and keep the evidence. An attestation is only as good as the policy, the release it ran on, and the sign-off behind each claim.
- Track the framework version. Confirm you are mapping to the current SP 800-218 revision, and add SP 800-218A if you build AI systems.
FAQ
What is the NIST Secure Software Development Framework (SSDF)?
The NIST Secure Software Development Framework (SSDF) is a set of high-level, methodology-agnostic secure development practices published by NIST as Special Publication 800-218. It organises secure software work into four practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). Version 1.1 defines 19 practices and 42 tasks. Because it describes outcomes rather than tools, it maps onto Agile, DevOps and Waterfall alike, and it has become the reference framework US federal software producers attest against.
What are the four practice groups of the NIST SSDF?
The NIST SSDF has four practice groups. Prepare the Organization (PO) sets up people, processes and tools, including security requirements and developer training. Protect the Software (PS) guards code and build systems from tampering and verifies software integrity and provenance. Produce Well-Secured Software (PW) is the largest group and covers secure design, threat modelling, secure coding, third-party and SBOM review, and pre-release testing. Respond to Vulnerabilities (RV) covers finding, disclosing and remediating vulnerabilities after release.
Is NIST SSDF compliance mandatory in 2026?
The NIST SSDF is voluntary guidance, but conformance is effectively required to sell software to the US federal government. Under OMB memoranda M-22-18 and M-23-16, agencies must obtain a secure software development attestation from producers whose software they use. Executive Order 14306 in June 2025 removed CISA's central validation of those attestations and struck the related Federal Acquisition Regulation update, but the underlying obligation to follow the SSDF and provide auditable evidence remains. Enterprise buyers increasingly ask for the same evidence even without a federal mandate.
What is the difference between the NIST SSDF and a secure SDLC?
A secure SDLC is your own delivery process with security built into each phase; the NIST SSDF is a framework of outcome-based practices you map that process against. The SSDF does not prescribe phases, tools or a methodology — it defines what good secure development looks like as practices and tasks, so you can demonstrate that your Agile or DevOps SDLC already achieves them. In practice, teams run a secure SDLC day to day and use the SSDF as the common language for audits, enterprise security reviews and federal self-attestation.
What is NIST SP 800-218A?
NIST SP 800-218A is a companion profile to the SSDF, released in 2024, that adds secure development practices and tasks specific to AI and generative-AI model development. It extends the same four practice groups to cover risks traditional software does not face, such as training-data integrity, model provenance, and model and data poisoning. Teams building AI systems keep the core SSDF and layer SP 800-218A on top rather than adopting a separate framework.
How does SBOM relate to the NIST SSDF?
A software bill of materials (SBOM) is one of the concrete artefacts the SSDF's Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV) practices call for. PW requires you to acquire, verify and track third-party and open-source components; an SBOM is the inventory that makes that possible and lets you answer, quickly, whether a newly disclosed vulnerability affects your software. Generating and retaining an SBOM per release is now a baseline expectation for federal and enterprise buyers assessing SSDF conformance.
Last updated 30 July 2026. Framework references are to NIST SP 800-218 (SSDF v1.1), SP 800-218A for AI, work on SP 800-218 Rev. 1, US Executive Orders 14028 and 14306, OMB M-22-18 and M-23-16, and the CISA Secure Software Development Attestation Form, cited as general guidance. Attestation mechanics and framework versions change — verify the current NIST publication and procurement rules for your situation, and treat this as a starting point, not legal advice.
