NIST SSDF Version 1.2: What’s new
The National Institute of Standards and Technology (NIST) has recently published a new Draft of the Secure Software Development Framework (version 1.2), and is now open for comments (deadline set for January 30th 2026).
The full document is freely available.
The NIST SSDF (800-218) is a core set of high-level secure software development practices that can be integrated into each SDLC implementation that not only helps software producers to address security concerns early in the software lifecycle, but it also provides guidance through examples on how to shape the security culture of the company.
We believe this is one of the most important aspects of this framework. At DCODX we help companies close their gaps against NIST SSDF.
What is really new?
NIST SSDF Version 1.2 reflects several changes that are largely driven by shifts in U.S. federal cybersecurity policy under the Trump administration. One of this is the famous EO14306
Executive Order 14306 demand
This is because in Executive Order 14306 (published in June), the Trump administration explicitly directed NIST to update the Secure Software Development Framework.
- Two entirely new practices have been added:
PO.6 – Continuous Improvement
PS.4 – Secure and Reliable Updates
PO.6 – Continuous Improvement
PO.6 is what we think the greatest addition to the standard. In the previous version (1.1) continuous improvements were hidden and not explicitly referenced as dedicated control. For example the Introduction of version 1.1 notes that an organization “can define their future target practices as part of its continuous improvement process,” but this is descriptive very generic guidance (that does not really say anything) that does not guide the organization.
Continuous improvements is for example something like:
- adding new security tools to improve early detection.
- improving logging to detect attacks and errors.
- implement Zero-Trust for the development and deployment environment.
PS.4 – Secure and Reliable Update
This is also an explicit reference to what previously was hidden in other paragraphs. For example in version 1.1:
PO.1 includes examples referencing lifecycle policies and end-of-life notifications, but not secure update execution.
PW focuses on build-time and release-time security, not post-release update delivery.
RV addresses vulnerability remediation but does not address the security properties of the update mechanism itself (for example authenticity, integrity, rollback safety etc.)
PS.4 also focuses on giving the full capability to the end-customer to decide how, when and where to update. From the standard:
Implement robust and reliable software update strategies, preferably allowing customers to control any updates to the software package and application configurations.
This control fills the lifecycle gap between vulnerability discovery (RV) and software protection (PS) that was present in Version 1.1.
- More changes are present and listed in the document
Conclusion
This new update reflects not only the EO demand, but also the continuous threats coming from supply chain attacks (see our research on the NPM PhantomRaven packages) . Expanded mappings to newer NIST SP 800-53 controls, particularly Configuration Management and program-level controls, also reflect a growing recognition that modern software risk often originates from misconfigured repositories, CI/CD pipelines, and automation, not just vulnerable code.
At DCODX we have opensourced GitArmor to help SMEs to assess their SCMs and software development process against out of the box security policies-as-code
At the same time, SSDF 1.2 remains intentionally high-level and non-prescriptive. It still does not define specific metrics, maturity targets, or tooling requirements, which means organizations must translate outcomes into concrete controls, automation, and enforcement mechanisms themselves.
If you’re starting with NIST SSDF, or already using it as a guide, we can help turn it into something concrete, measurable, and actionable. Get in touch!
