NIST SP 800-218 Secure Software Development Framework
Version 1.1, February 2022. Referenced in Executive Order 14028. Four practice groups: Prepare, Protect Software, Produce Well-Secured Software, and Respond to Vulnerabilities.
| Jurisdiction | United States |
|---|---|
| Category | Technical Standards |
| Status | Active |
| Effective date | |
| Latest development |
Analysis
NIST SP 800-218 (Secure Software Development Framework – SSDF v1.1) is a NIST Special Publication that defines a set of fundamental secure software development practices, organized into four practice groups, and is explicitly referenced in Executive Order 14028 as a core framework for improving the nation’s cybersecurity.NIST SP 800‑218 FinalNIST SSDF Project PageExecutive Order 14028 (White House)
Key Requirements (SSDF v1.1 Practice Groups and Core Tasks)
According to NIST SP 800‑218 v1.1, the SSDF consists of four practice groups: Prepare the Organization (PO), Protect Software (PS), Produce Well‑Secured Software (PW), and Respond to Vulnerabilities (RV).NIST SP 800‑218 FinalNIST SSDF Project PageNIST SP 800‑218 Draft PDF (historical)**
Note: SSDF is not a prescriptive “compliance” standard, but a set of recommended practices that can be mapped into organizational policies, contracts, and regulations, including EO 14028.NIST SP 800‑218 FinalNIST SSDF Project PageCheckmarx SSDF Overview
1. Prepare the Organization (PO)
- Establish and maintain secure development governance
- Organizations are expected to define roles, responsibilities, and policies for secure software development, and integrate SSDF practices into the SDLC.NIST SP 800‑218 FinalNIST SSDF Project PageCISA SSDF Overview
- PO practices include identifying and documenting security requirements for development infrastructures and processes (e.g., PO.1.1, PO.1.2).NIST SP 800‑218 Draft PDF (historical)NIST SSDF Project PageSecure by Design SSDF Overview
- Implement and maintain secure environments for software development (PO.5)
- SSDF v1.1 explicitly adds PO.5 “Implement and Maintain Secure Environments for Software Development” as a new practice compared to v1.0.NIST SSDF Project PageNIST SP 800‑218 FinalNIST SSDF News (Update to v1.1)
- This includes hardening development and build environments, controlling administrative access, and monitoring for compromise.NIST SP 800‑218 FinalCISA SSDF OverviewNIST SSDF Project Page
2. Protect Software (PS)
- Secure code, artifacts, and supply chain components
- PS practices focus on protecting software during and after development, including configuration management, access controls, and integrity protection for code repositories and build artifacts.NIST SP 800‑218 FinalCISA SSDF OverviewNIST SSDF Project Page
- SSDF v1.1 adds PS.3.2 to collect and share provenance data for all components of software releases, supporting software supply chain transparency and integrity.NIST SSDF Project PageNIST SP 800‑218 FinalSecure by Design SSDF Overview
3. Produce Well‑Secured Software (PW)
- Integrate security requirements and design into development
- PW practices cover secure requirements, design, implementation, verification, and release processes, including threat modeling, secure coding, and security testing.NIST SP 800‑218 FinalCISA SSDF OverviewNIST SSDF Project Page
- SSDF v1.1 adds PW.1.2 to track software security requirements, risks, and design decisions, ensuring traceability across the SDLC.NIST SSDF Project PageNIST SP 800‑218 FinalSecure by Design SSDF Overview
4. Respond to Vulnerabilities (RV)
- Detect, triage, and remediate vulnerabilities in released software
- RV practices require organizations to receive, analyze, and address vulnerability reports from users, acquirers, and public sources, and to update software in a timely manner.NIST SP 800‑218 FinalCISA SSDF OverviewNIST SSDF Project Page
- For example, task RV.1.1 includes gathering information from acquirers, users, and public sources about potential vulnerabilities in software and third‑party components.Checkmarx SSDF OverviewNIST SP 800‑218 FinalNIST SSDF Project Page
Relationship to Executive Order 14028
- EO 14028 Section 4(e) mapping
- NIST SP 800‑218 includes Appendix A, which maps Executive Order 14028 Section 4(e) clauses to SSDF practices and tasks that help address each clause.NIST SSDF Project PageNIST SP 800‑218 FinalNIST SSDF News
- NIST explicitly states that SSDF is intended to support NIST’s responsibilities under EO 14028 for improving the nation’s cybersecurity.NIST SSDF NewsGovDelivery EO 14028 SSDF BulletinExecutive Order 14028 (White House)
Compliance Challenges
Although SSDF is a framework of recommended practices, organizations frequently adopt it as a de facto compliance baseline in response to EO 14028, federal acquisition requirements, and industry expectations.NIST SSDF Project PageCISA SSDF OverviewCheckmarx SSDF Overview
Common Challenges
- Integrating SSDF into existing SDLCs and DevOps pipelines
- NIST notes that SSDF practices are high‑level and agnostic to specific SDLC models, and must be tailored and mapped to existing processes.NIST SP 800‑218 FinalCISA SSDF OverviewNIST SSDF Project Page
- Industry commentary highlights that organizations struggle to translate SSDF practices into concrete DevSecOps workflows and tooling.Checkmarx SSDF OverviewSecure by Design SSDF OverviewCISA Secure by Design Initiative
- Supply chain visibility and provenance (PS.3.2)
- Collecting and sharing provenance data for all release components (PS.3.2) requires robust SBOM generation, dependency tracking, and third‑party attestation.NIST SSDF Project PageNIST SP 800‑218 FinalCISA SSDF Overview
- EO 14028 and related guidance push for SBOM adoption; industry reports show many organizations lack mature SBOM processes and tooling.Executive Order 14028 (White House)NTIA SBOM Guidance ArchiveCISA SBOM Overview
- Securing build and development environments (PO.5)
- Implementing PO.5 is challenging due to complex CI/CD systems, shared infrastructure, and the need for least‑privilege administration.NIST SSDF Project PageNIST SP 800‑218 FinalCISA SSDF Overview
- Analyses of supply‑chain attacks (e.g., SolarWinds) show that compromised build environments can undermine traditional application‑level security controls, driving SSDF adoption.Executive Order 14028 (White House)CISA Alert on SolarWinds CompromiseSecure by Design SSDF Overview
- Operationalizing vulnerability response (RV) at scale
- RV requires continuous intake, analysis, and remediation cycles; many organizations lack coordinated product security incident response teams (PSIRTs) or mature processes.NIST SP 800‑218 FinalCISA SSDF OverviewNIST SSDF Project Page
- CISA’s Secure by Design initiative and industry case studies highlight gaps in vulnerability disclosure and patch management practices.CISA Secure by Design InitiativeCISA Secure by Design Principles DocumentCheckmarx SSDF Overview
Real‑World Examples and Case Studies
- SolarWinds / software supply chain compromises
- EO 14028 cites large‑scale supply‑chain incidents (including SolarWinds) as drivers for federal emphasis on secure development and supply‑chain risk management, which SSDF directly supports.Executive Order 14028 (White House)CISA SolarWinds AlertNIST SSDF Project Page
- Industry analyses point out that organizations struggled with provenance, build environment security, and timely vulnerability response, all directly addressed by SSDF practices.CISA Secure by Design InitiativeSecure by Design SSDF OverviewCheckmarx SSDF Overview
- Federal agency SSDF adoption under EO 14028
- NIST’s GovDelivery bulletin indicates SSDF v1.1 was shaped by a June 2021 workshop and public feedback to support EO 14028 Section 4(e), reflecting significant federal stakeholder input and highlighting adoption challenges across agencies.GovDelivery EO 14028 SSDF BulletinNIST SSDF NewsNIST SSDF Project Page
Implementation Best Practices
Actionable Steps for Implementing SSDF
- Perform a gap analysis against SSDF practices
- Map existing SDLC, DevOps, and security processes to SSDF PO, PS, PW, and RV practices to identify gaps and prioritize remediation.NIST SP 800‑218 FinalNIST SSDF Project PageCISA SSDF Overview
- NIST provides an Excel table of SSDF 1.1 practices and tasks to support such mapping work.NIST SSDF Project PageNIST SP 800‑218 FinalSecure by Design SSDF Overview
- Embed SSDF into governance, contracts, and supplier requirements
- NIST recommends that organizations express secure development requirements to third‑party suppliers using SSDF conventions and acquire software that meets SSDF practices.CISA SSDF OverviewNIST SP 800‑218 FinalNIST SSDF Project Page
- SSDF Appendix A provides mappings to EO 14028 Section 4(e), which can inform procurement and contractual language.NIST SSDF Project Page[
Recent developments
- — Industry commentary from Black Duck says SSDF is a **best-practices framework rather than a regulation** with a fixed enforcement date. The post reflects common industry interpretation that organizations adopt SSDF to strengthen software supply-chain security and align with broader compliance programs. (source)
- — NIST’s SSDF project page notes that **SP 800-218A is finalized** and that SP 800-218 remains the foundational SSDF reference. The page also summarizes the key SSDF v1.1 changes, including a secure development environment practice and provenance-sharing tasks. (source)
- — NIST’s final SP 800-218 page confirms SSDF **Version 1.1** is the published baseline and records its document history. This remains the authoritative final version until Revision 1 is completed. (source)
- — NIST’s SSDF project page says it has finalized **SP 800-218A**, the community profile for generative AI and dual-use foundation models. That update extends SSDF concepts to AI-specific development workflows. (source)
- — NIST released the **initial public draft of SP 800-218 Revision 1 (SSDF Version 1.2)** and opened public comments through 2026-01-30. The draft says it adds new and improved practices, tasks, and examples for secure and reliable software development. (source)
- — NIST announced **Draft SSDF 1.2 Available for Comment**, highlighting the new revision and its public review period. This is the most direct recent policy update for the framework. (source)
- — NIST published **SP 800-218A**, describing secure software development practices for generative AI and dual-use foundation models. The release explicitly augments SSDF v1.1 with AI-specific recommendations and references EO 14110. (source)
- — NIST updated the SSDF to **SP 800-218 Version 1.1** and stated it replaced the earlier 2020 white paper. The publication includes mappings to Executive Order 14028 clauses. (source)
Related regulations
- Framework Convention on Artificial Intelligence, Human Rights and Democracy — Technical Standards, Active
- OECD Framework for Classifying AI Systems — Technical Standards, Active
- IEEE P7003: Algorithmic Bias Considerations — Technical Standards, Active
- IEEE P2863: Organizational Governance of Artificial Intelligence — Technical Standards, Active
- ISO/IEC 23894: Information Technology — Artificial Intelligence — Risk Management — Technical Standards, Active
- Harmonized Standards for EU AI Act Compliance — Technical Standards, Active
- NIST AI Risk Management Framework (AI RMF 1.0) — United States, Active, effective 2023-01-26
- Blueprint for an AI Bill of Rights — United States, Active
Put it into practice
- Generate the policy: NIST CSF policy generator (generatepolicy.com)
- Buy the policy pack: Vendor Risk Management Bundle (cyberpolicy.shop)
- Build it yourself: TPRM Program Kit (ciso.diy)
Browse all regulations · Compliance deadlines · Latest updates