Most software development life cycles say little about security, so vulnerabilities, tampered builds and weak release integrity reach customers by default. NIST SP 800-218, the Secure Software Development Framework (SSDF), is a set of high-level practices that can be added to any life cycle model, from waterfall to continuous delivery. It has also become the common vocabulary that buyers use to ask suppliers how their software is built. This guide explains the structure of SSDF version 1.1, the AI profile in SP 800-218A, the draft version 1.2, and what happened to the US federal attestation requirement in 2025 and 2026. It is for application security leads, DevSecOps engineers and supplier assurance teams.
Key takeaways
- SSDF is outcome based, not prescriptive. It defines what a producer should achieve in four practice groups (PO, PS, PW, RV) and leaves the tooling and method to the organisation.
- Version 1.1 is still the final text. SP 800-218 Rev. 1 (SSDF version 1.2) was released as an initial public draft on 17 December 2025 and, as checked on 24 October 2026, NIST lists it as a draft, not a final publication.
- The federal attestation mandate has gone, the framework has not. OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16; agencies may still use the CISA attestation form, and M-26-05 still points agencies to SP 800-218.
- Build and pipeline identities are inside scope. PO.5 and PS.1 require protected development environments and least-privilege access to all forms of code, which in practice means CI/CD service accounts, deploy keys, tokens and signing keys.
- Evidence is the real deliverable. Task PO.3.3 asks for toolchains configured to generate artefacts that show the practices are followed; without that evidence an SSDF claim is a policy statement.
What it is and who it applies to
NIST published SP 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, as final on 3 February 2022. It superseded the April 2020 white paper CSWP 13. The stated aims are to reduce vulnerabilities in released software, limit the impact of flaws that are not found, and address root causes so they do not recur. NIST also positions it as a shared language between software producers and acquirers.
- Producers: anyone who writes, builds or ships software, including internal development teams, SaaS providers, open source maintainers and firmware teams. SSDF has no certification scheme and no auditor accreditation.
- Acquirers: buyers who want a structured way to ask how a supplier builds software.
- AI model producers: SP 800-218A (final, 26 July 2024) is an SSDF Community Profile for generative AI and dual-use foundation models, written for producers of AI models, producers of AI systems that use them, and acquirers of those systems. It is used alongside SP 800-218, not instead of it.
- US federal suppliers: see the attestation section below for the current position; the obligation now depends on the individual agency's policy and contract.
Status of the documents (checked 24 October 2026)
| Document | Status | Notes |
|---|---|---|
| SP 800-218 (SSDF v1.1) | Final, 3 February 2022 | The current reference text. Practice IDs used in this guide come from it. |
| SP 800-218A (AI Community Profile) | Final, 26 July 2024 | Adds AI-specific tasks and High, Medium or Low priorities. Built on v1.1. |
| SP 800-218 Rev. 1 (SSDF v1.2) | Initial public draft, 17 December 2025; comments closed 30 January 2026 | Adds PO.6 and PS.4 and renumbers several tasks. Treat as direction of travel until NIST publishes the final. |
| EO 14306 (6 June 2025) | In force | Amended EO 14144: NCCoE industry consortium on SSDF implementation by 1 August 2025, preliminary SSDF update by 1 December 2025, final update within 120 days of that. |
| OMB M-22-18 and M-23-16 | Rescinded by OMB M-26-05, 23 January 2026 | Replaced by agency-level, risk-based software and hardware assurance policies. |
Check csrc.nist.gov for v1.2 status before quoting its IDs in a contract.
Structure and key requirements
Each SSDF practice has an ID, a short outcome statement, tasks (numbered, for example PO.5.1), notional implementation examples, and informative references to other standards such as BSIMM, OWASP SAMM, SP 800-53, SP 800-161, ISO/IEC 27034, ISO/IEC 29147, ISO/IEC 30111, the NTIA SBOM work, OWASP ASVS, OWASP SCVS and the PCI Secure Software Lifecycle standard.
| Group | Practices in v1.1 | What it covers in practice |
|---|---|---|
| PO: Prepare the Organization | PO.1 Define security requirements for software development; PO.2 Implement roles and responsibilities; PO.3 Implement supporting toolchains; PO.4 Define and use criteria for software security checks; PO.5 Implement and maintain secure environments for software development | Secure coding and third-party requirements, training and ownership, the CI/CD and security tool estate, release gates, and hardening of build systems and developer endpoints |
| PS: Protect the Software | PS.1 Protect all forms of code from unauthorized access and tampering; PS.2 Provide a mechanism for verifying software release integrity; PS.3 Archive and protect each software release | Repository access control, signing and hashes, provenance and retention of released versions |
| PW: Produce Well-Secured Software | PW.1 Design to meet security requirements; PW.2 Review the design; PW.4 Reuse existing, well-secured software; PW.5 Secure coding practices; PW.6 Configure compilation, interpreter and build processes; PW.7 Review or analyse human-readable code; PW.8 Test executable code; PW.9 Secure settings by default (PW.3 was moved into PW.4) | Threat modelling, dependency selection and SCA, secure coding standards, compiler hardening flags, SAST and code review, DAST and fuzzing, secure defaults |
| RV: Respond to Vulnerabilities | RV.1 Identify and confirm vulnerabilities on an ongoing basis; RV.2 Assess, prioritise and remediate; RV.3 Analyse root causes | Intake from users and researchers, a disclosure policy, triage and fix, and feeding root causes back into PO and PW |
Tasks that most often decide an assessment
- PO.3.1 to PO.3.3: specify which tools each toolchain must include and how they integrate, operate them securely, and configure them to generate artefacts that show secure development practices.
- PO.5.1 and PO.5.2: separate and protect each environment involved in development (source, build, test, distribution), and harden development endpoints using a risk-based approach.
- PS.1.1: store all forms of code, including source, executables and configuration as code, based on least privilege so only authorised people, tools, services and the like have access.
- PW.4.1 and PW.4.4: acquire well-secured third-party components and verify they keep meeting requirements across their life cycle. This is where SBOM, SCA and dependency health signals such as the OpenSSF Scorecard fit. See the SBOM Guide and the OpenSSF Scorecard Guide.
- PW.6.1 and PW.6.2: use compiler, interpreter and build tool features that improve executable security and keep approved configurations for them.
- PW.7 and PW.8: decide where code review, static analysis and executable testing are needed, then scope, run, document and triage. See the Application Security Guide.
- RV.1.1 to RV.1.3: gather vulnerability information from acquirers, users and public sources, look for undetected vulnerabilities, and maintain a disclosure and remediation policy. See the Bug Bounty and Vulnerability Disclosure Guide.
What the draft v1.2 changes
- PO.6 Define and implement a continuous process improvement plan: new practice with tasks PO.6.1 to PO.6.3, responding to EO 14306.
- PS.4 Ensure software updates are robust and reliable: new practice with tasks PS.4.1 to PS.4.4, covering the update mechanism itself.
- Renumbering: the former PW.3.1 becomes PO.1.3, the former PW.4.3 becomes PW.1.3, and PW.4.5 is folded into PW.4.1 and PW.4.4. The four groups stay the same. Keep a crosswalk if your control library uses v1.1 IDs.
SP 800-218A for AI models
The AI profile keeps the SSDF structure and adds tasks marked as not part of SSDF 1.1, each with a priority:
| ID | Addition | Priority |
|---|---|---|
| PO.5.3 | Continuously monitor software execution and behaviour in development environments | High |
| PS.1.2 | Protect training, testing, fine-tuning and aligning data from unauthorised access and modification | High |
| PS.1.3 | Protect model weights and configuration parameters; risk-proportionate measures such as encryption, hashes, signatures, multiparty authorisation and air-gapped environments | High |
| PW.3.1 | Analyse data for poisoning, bias, homogeneity and tampering before use | High |
| PW.3.2 | Track the provenance of training and related data, and document data without known provenance | Medium |
| PW.3.3 | Include adversarial samples in training and testing data | Medium |
Note that PW.3 means different things in 800-218A (AI data integrity) and in v1.1 (a retired practice). Label which document an ID comes from. See the AI Supply Chain and AI-BOM Guide.
Attestation: what changed
CISA and OMB released the Secure Software Development Attestation Form on 11 March 2024 under M-22-18 and M-23-16. Producers selling to federal agencies signed it to attest to a subset of SSDF-derived practices, submitting through CISA's Repository for Software Attestations and Artifacts (RSAA) or by email. OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security, rescinded both memoranda on 23 January 2026. Under M-26-05:
- Agency responsibility: agency heads remain accountable for software and hardware on their networks and must set their own assurance policies based on risk and mission.
- Inventory: agencies must continue to maintain a complete inventory of software and hardware.
- Optional tools: agencies may still use the attestation form and may require a current SBOM on request (for cloud platforms, of the runtime production environment).
- References: the memo lists SP 800-218, CISA's draft 2025 Minimum Elements for an SBOM and CISA's HBOM framework as sources for agencies.
- Still open: FAR Case 2023-002 on supply chain software security remains open, so a future FAR rule could change the picture again.
For suppliers, expect agency-specific questionnaires and clauses instead of one form; an SSDF evidence pack still answers most of them.
Identity and NHI requirements
SSDF never uses the term non-human identity, but several tasks cannot be met without governing the machine credentials in the software factory. The SolarWinds compromise shows why: attackers with stolen credentials reached the build environment and used SUNSPOT to inject SUNBURST into Orion builds, which were then signed like any other update. See the SolarWinds supply chain compromise.
| SSDF task | Identity implication | Concrete control |
|---|---|---|
| PO.5.1 separate and protect environments | Each environment has its own service accounts and secrets | Distinct CI runners and cloud roles per environment; no shared deploy credential across test and production |
| PO.5.2 harden endpoints | Developer laptops hold PATs, SSH keys and cloud CLI tokens | Short-lived SSO-issued tokens, hardware-backed SSH keys, secret scanning on endpoints and repos |
| PS.1.1 least privilege for all code | "Tools, services and the like" are named alongside people | Scope bot and app tokens to single repositories; review deploy keys and GitHub App installations quarterly |
| PS.2 release integrity | The signing key is the most valuable NHI in the pipeline | Keys in HSM or KMS, or keyless signing bound to a workload identity; separate signing identity from build identity |
| PO.3.2 operate toolchains securely | CI/CD systems hold credentials for every downstream system | OIDC federation from pipeline to cloud instead of stored keys; minimal GITHUB_TOKEN permissions |
| 800-218A PS.1.3 model weights | Access to weights is often via service identities | Indirect access only, multiparty authorisation for export, logging of every read |
See the CI/CD Pipeline Identity Security Guide, the Workload Identity Federation Guide and the Code Signing Security Guide.
Implementation steps
- Scope and baseline (weeks 1 to 4): list the products and pipelines in scope, then score each SSDF task as met, partly met or not met with a named owner. Start with the products sold to regulated customers or with the widest deployment.
- Fix the environment first (PO.5, PS.1): inventory CI/CD service accounts, tokens, deploy keys and signing keys; remove standing admin access to build systems; move pipeline to cloud authentication to OIDC federation.
- Define gates (PO.4): write the release criteria, for example no unresolved critical SAST findings, no dependency with a known exploited vulnerability, signed artefact present. Run each new gate in report-only mode for two to four weeks to measure failure rates before enforcing.
- Roll out tools in rings (PO.3, PW.4, PW.7, PW.8): pilot SCA, SAST and secret scanning on two or three willing teams, tune rules, then expand. Keep a documented exception path with expiry dates so teams are not blocked indefinitely.
- Add release integrity (PS.2, PS.3): sign artefacts, publish hashes, generate SBOM and provenance at build time, and archive each release with its evidence. See the SLSA and Build Provenance Guide.
- Stand up vulnerability response (RV): publish a security contact and disclosure policy, set remediation targets by severity, and run root cause reviews on repeat classes of flaw.
- Collect evidence automatically (PO.3.3): store pipeline logs, scan results, approvals and signatures for each release in a retained location so a questionnaire can be answered from records.
- Roll back safely: if an enforced gate blocks critical delivery, revert it to report-only through configuration rather than deleting it, record the exception, and set a date to re-enable. Never roll back signing or least-privilege changes without a security sign-off.
Small versus large organisations
- Small teams: use the controls built into the source platform (branch protection, secret scanning, dependency alerts, artefact attestations) and a single short SSDF self-assessment. Focus on PO.5, PS.1, PS.2 and RV.1.
- Large organisations: map SSDF into the central control library, assign practice owners, use an ASPM layer to aggregate findings, and track per-product maturity. See the Application Security Posture Management (ASPM) Guide.
Evidence and assessment
| Practice | Evidence an assessor expects |
|---|---|
| PO.1, PO.2 | Secure development policy, secure coding standard, RACI, training records for developers |
| PO.3, PO.4 | Toolchain inventory, gate definitions, sample pipeline run showing gates evaluated |
| PO.5 | Environment diagram, access reviews for build systems, inventory of pipeline credentials with owners and expiry |
| PS.1 | Repository permission exports, branch protection settings, deploy key and app token listing |
| PS.2, PS.3 | Signature and hash for a recent release, verification instructions, provenance file, release archive retention |
| PW.4 | SBOM per release, SCA results, component approval criteria |
| PW.7, PW.8 | SAST and DAST reports with triage decisions, code review records |
| RV.1 to RV.3 | Published disclosure policy, vulnerability tickets with timestamps, root cause records |
Metrics that show it is working
- Task coverage: percentage of SSDF tasks rated met per product, tracked quarterly.
- Signed releases: percentage of releases with a verifiable signature and provenance.
- Pipeline credential hygiene: percentage of CI/CD credentials that are short-lived or federated, and count of long-lived tokens older than 90 days.
- Remediation time: median days to fix critical and high vulnerabilities in released software.
- Recurrence: repeat vulnerabilities of the same class after a root cause review (RV.3).
To detect drift, monitor branch protection and pipeline changes, new deploy keys, and signing key use outside release jobs.
Mapping to other frameworks
| SSDF area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| PO.1, PO.2 requirements and roles | SA-3 System Development Life Cycle, SA-8 Security and Privacy Engineering Principles | PR.PS-06 | A.8.25 Secure development life cycle |
| PO.3, PO.4 toolchains and criteria | SA-15 Development Process, Standards, and Tools | PR.PS-06 | A.8.25, A.8.29 Security testing in development and acceptance |
| PO.5, PS.1 environments and code access | SA-10 Developer Configuration Management, AC-6 Least Privilege, IA-5 Authenticator Management | PR.PS-01, PR.AA-05 | A.8.4 Access to source code, A.8.31 Separation of environments |
| PS.2, PS.3 release integrity | CM-14 Signed Components, SI-7 Software, Firmware, and Information Integrity, SR-4 Provenance | PR.PS-06 | A.8.32 Change management |
| PW.4 third-party components | SR-3 Supply Chain Controls and Processes | GV.SC-05, GV.SC-07 | A.5.21 Managing ICT supply chain security |
| PW.5 to PW.8 coding and testing | SA-11 Developer Testing and Evaluation | PR.PS-06 | A.8.28 Secure coding, A.8.29 |
| RV.1 to RV.3 response | RA-5 Vulnerability Monitoring and Scanning | ID.RA-01, ID.IM-01 | A.8.8 Management of technical vulnerabilities |
CIS Controls v8.1 Control 16 (Application Software Security) covers similar ground at safeguard level. On the threat side, the practices in PO.5, PS.1 and PS.2 are the main defences against MITRE ATT&CK T1195.002 Compromise Software Supply Chain, and PW.4 addresses T1195.001 Compromise Software Dependencies and Development Tools. For a wider crosswalk method see the Control Mapping Guide and the NIST SP 800-53 Guide; for EU product obligations see the EU Cyber Resilience Act Guide.
Common pitfalls
- Treating SSDF as a document exercise: a policy that cites every practice but no pipeline evidence fails the first serious customer review. Build evidence capture (PO.3.3) in from the start.
- Ignoring the build environment: teams invest in SAST and forget that whoever controls the build can ship anything, signed. SolarWinds showed source review does not catch build-time injection.
- Long-lived pipeline tokens: a PAT or registry token created years ago still works after a project moves to modern publishing. In the Ultralytics PyPI compromise, two malicious releases were uploaded with a long-lived PyPI token left over after the move to Trusted Publishing.
- Assuming the attestation rescission ends the obligation: agencies can still request the form, SBOMs and SSDF-based evidence through contract terms, and the open FAR case may add rules.
Practitioner checklist
- Confirm which SSDF version and which 800-218A tasks your policies and contracts cite, and recheck NIST's page for v1.2 status.
- Run a task-level self-assessment for each in-scope product with named owners.
- Inventory every CI/CD credential, deploy key, bot token and signing key, with owner and expiry.
- Replace stored cloud keys in pipelines with OIDC federation and scope workflow tokens to read by default.
- Sign releases and generate SBOM and provenance at build time; publish verification instructions.
- Define release gates and pilot them in report-only mode before enforcing.
- Publish a vulnerability disclosure policy and set remediation targets by severity.
- Store evidence per release so supplier questionnaires are answered from records.
Standards and references
- NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
- NIST: SP 800-218 Rev. 1 (Initial Public Draft), SSDF Version 1.2
- NIST: SP 800-218A Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
- NIST: Secure Software Development Framework project
- OMB: M-26-05 Adopting a Risk-based Approach to Software and Hardware Security
- The White House: Executive Order 14306, Sustaining Select Efforts to Strengthen the Nation's Cybersecurity
- CISA: Secure Software Development Attestation Form
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Software Supply Chain Security Guide · Secure Software Development Lifecycle (SSDLC) Guide · CI/CD Security Guide · Secrets Management Guide. This guide summarises NIST SP 800-218, related US federal policy and its status as checked on 24 October 2026, and is not legal advice.