On 17 December 2025 NIST released the initial public draft of SP 800-218 Rev. 1, which is SSDF Version 1.2. Comments closed on 30 January 2026, and we did not find a final version at the time of writing. The draft adds two practices to the framework, PO.6 and PS.4, and removes the Executive Order 14028 references, including the prior version's Appendix A.
The SSDF is a set of outcomes, not a checklist. NIST says no example is required and the examples are not the only way. For a small team that is good news, because you choose the lightest action that meets each outcome.
What's affected
The draft keeps the four groups of SSDF 1.1:
- Prepare the Organization (PO): people, processes and technology are ready.
- Protect the Software (PS): all components are protected from tampering and unauthorized access.
- Produce Well-Secured Software (PW): releases have minimal security vulnerabilities.
- Respond to Vulnerabilities (RV): residual vulnerabilities are found and fixed, and root causes addressed.
What is new in 1.2, per its change log: practices PO.6 (a continuous improvement plan) and PS.4 (reliable software updates), reworded tasks RV.1.2 and RV.3.3, and added examples under PW.1.1, PW.1.3, PW.4.4, PW.5.1, PW.8.2, PW.9.1, RV.1.2 and RV.2.2.
How to check if you're exposed
Run a one hour gap review. For each practice ID below, write down what you already do and where the evidence lives. Blank cells are your backlog.
| Practice | A small team's version | Evidence |
|---|---|---|
| PO.1 requirements | One page listing security requirements for code, tools and open source use, reviewed at least yearly (the draft's own example) | The page, with a date |
| PO.2 roles | Named owner for security decisions, training for developers | Role list, training record |
| PO.4 criteria | Written release gate: no known critical findings without a recorded decision | Gate config, exceptions log |
| PO.5 environments | Separate dev, build and production access; MFA on the code host | Access list |
| PO.6 improvement (new) | Quarterly review of tooling and of decisions not to patch | Meeting notes |
| PS.1 protect code | Branch protection, least privilege, no shared accounts | Repo settings export |
| PS.2, PS.3 release integrity and archive | Published hashes or signatures, each release archived with its SBOM | Release page, archive |
| PS.4 updates (new) | Test updates like customer installs, stage rollouts, support rollback | Release checklist |
| PW.1, PW.2 design | Lightweight threat model for new features, reviewed | Design notes |
| PW.4 reuse | Track every third party component, verify it against your criteria | SBOM, scan results |
| PW.7, PW.8 review and test | Code review for every change, security tests in CI | Pull request history, CI logs |
| PW.9 defaults | Secure configuration by default | Config baseline |
| RV.1 to RV.3 | Intake, triage, fix, and learn from root causes | Ticket queue, post mortems |
What to do now
- Pick the six rows where you have no evidence and turn each into one ticket this month.
- Put recurring work on the calendar: weekly dependency and advisory review (PW.4.4, RV.1.1), monthly access review (PS.1), quarterly process review (PO.6).
- Add the new practices to your release template: update testing, staged rollout, rollback plan (PS.4.1 to PS.4.3).
- Publish a vulnerability disclosure policy, because RV.1.3 asks for a policy and roles, and the draft's example is a disclosure program that is easy for researchers to find.
- Keep evidence where an outsider can read it: PS.3.2 asks that provenance data for every component of a release be collected and shareable, for example in an SBOM.
How to avoid this trap
- Do not copy a 200 line policy from the internet. If you cannot show you do it, delete the sentence.
- Do not treat a draft as final. Track the revision, because tasks can still change.
- Do not map every practice to a tool. Several are people and review habits.
Why it matters
OMB rescinded the federal attestation memos in January 2026, yet the same memo still lists NIST SP 800-218 as a reference for agencies. The framework outlives the form. A small team that can show one row of evidence per practice can answer a customer's SSDF question from evidence it already has.
Try it yourself
Do the one hour gap review above for one product. Then compare your table to the control mapping walkthrough.
Click through it at your own pace, or open it full screen.
Quick check
Which two practices does the SSDF 1.2 draft add?
PO.6, defining and implementing a continuous process improvement plan, and PS.4, reliable software updates.
Does the draft require specific tools for each practice?
No. NIST says the notional examples are not required and are not the only feasible options.
