31 December, 2025
For the past couple of decades, organizations have increasingly invested in security. Unfortunately, they often invest too late and in the wrong areas. Too late, because most security efforts focus on patching, penetration testing, and more recently scanning. These practices add value, but they come late in the lifecycle. Security needs to be built into software systems from the start. Wrong, because organizations tend to focus on the cyber side of security while ignoring application security.
Surprisingly, the growing number of data breaches has had only a limited impact on overall security posture. Security budgets still flow mainly into penetration tests, long running bug bounty programs, and a wide range of security scanning tools, each with clear strengths and weaknesses. This approach is now under pressure. Directives and regulations like the Cyber Resilience Act (CRA) increasingly push organizations toward a more structured and systematic way of working.
For the US, Executive Order 14028 and Executive Order 14306 place application security firmly in the spotlight. OMB Memorandum M-22-18 enforces these directives through federal procurement. It effectively makes them mandatory for software producers selling to US federal agencies. To comply, suppliers must adopt the NIST Secure Software Development Framework, also known as SSDF. SSDF version 1.1 has been available for some time. In a previous blog, we explored the framework in detail.
NIST has recently released a draft of SSDF version 1.2. In this blog post, we take a closer look at the key changes and what they mean in practice.
Key takeaways
-
Version 1.2 introduces only limited changes compared to SSDF 1.1.
-
The Prepare the Organization section now includes a new Practice PO.6 with three tasks. These reinforce the idea that security is an ongoing journey, not a fixed end state.
-
The Protect the Software section adds a new Practice PS.4. It places stronger emphasis on continuous testing.
-
Several notional implementation examples have been refreshed and expanded with new examples.
Note: This analysis is based on the Initial Public Draft of SSDF 1.2 released in December 2025.
What is NIST Secure Software Development Framework?
The NIST Secure Software Development Framework, or SSDF, defines a structured approach to application security. It guides organizations in building security into the software development lifecycle. Teams apply security practices from design through deployment. This approach leads to more secure and resilient software.
SSDF structure
SSDF organizes its guidance into four practice groups. These are Prepare the Organization, Protect the Software, Produce Well Secured Software, and Respond to Vulnerabilities. Each group focuses on a specific aspect of secure software development.
Every practice group contains multiple practices. Each practice breaks down into clear and actionable tasks. These tasks describe what teams need to do to meet security objectives. This layered structure helps organizations adopt SSDF step by step and at their own pace.
Key facts about NIST SSDF
SSDF remains descriptive by design. It allows organizations to adapt practices to their environment, size, and risk profile. For each task, SSDF provides notional implementation examples. These examples illustrate possible approaches but do not prescribe a single solution.
The framework also references related standards and guidance. These references support teams that want to deepen their implementation or align SSDF with existing security programs.
As I have mentioned previously, SSDF also plays a regulatory role in the United States. Software producers that sell to US federal agencies must align with SSDF. This requirement raises the baseline for application security and reduces systemic risk across government software supply chains.
Why was NIST released SSDF 1.2?
NIST released SSDF 1.2 in response to Executive Order 14306. This executive order calls for stronger and more up to date guidance on secure software development. It explicitly asks NIST to refresh practices, procedures, controls, and implementation examples related to software security and delivery.
SSDF 1.1 already provided a solid foundation. However, evolving threats, modern development practices, and software supply chain risks required sharper guidance. Executive Order 14306 directs NIST to close these gaps and to clarify areas that raised concern in earlier versions of the framework.
SSDF 1.2 reflects this direction. It refines existing practices, adds targeted new ones, and updates implementation examples. The goal remains the same. Help organizations build secure and reliable software, while keeping pace with real world development and delivery models.
NIST SSDF 1.2: key updates
Continuously improve processes (PO.6)
SSDF 1.2 introduces a new practice under Prepare the Organization. The practice named Define and Implement a Continuous Process Improvement Plan (PO.6) focuses on continuous process improvement across the entire software development lifecycle. It formalizes an idea many teams already recognize: security is a journey, not a destination.
- PO.6.1, requires teams to continuously update development environments. New threats emerge. Tooling evolves. Development pipelines change. This task ensures that security controls and configurations keep pace with these changes instead of falling behind.
- PO.6.2 focuses on making organizations search more proactively towards preventing software errors rather than reacting to them.
- PO.6.3, strengthens vulnerability response. Teams must review how they handle vulnerabilities and revisit past decisions. This creates feedback loops between incidents, remediation, and future prevention.
This practice and tasks make absolute sense. They tell us that security is not a static checklist, but a continuous and living system. If compliance is your thing, you will have to demonstrate that you are continuously adapting your security program based on measurable improvements. If you are familiar with OWASP SAMM this practice essentially matches with all activities from maturity level 3 that focus on feedback loops and continuous improvements.
Implement a robust and reliable updates processes (PS.4)
Practice PS.4 addresses how organizations deliver software updates. It treats updates as a core security capability.
- PS.4.1 requires teams to thoroughly test every release. SSDF 1.2 references the Produce Well-Secured Software (PW) group.
- PS.4.2 introduces tiered release strategies. Techniques such as canary releases, staged rollouts, and test deployments reduce blast radius. Teams can detect issues early and limit impact before updates reach all users.
- PS.4.3 requires robust rollback mechanisms. When an update fails, teams must be able to revert quickly and safely. This reduces downtime and limits security exposure during incidents.
- PS.4.4 focuses on the update infrastructure itself. Update engines and delivery pipelines must remain reliable and secure. Compromised or fragile update mechanisms create systemic risk across the software supply chain.
From a critical perspective, the wording of this practice could be improved and be more explicit about security. PS.4.1 clearly ties update testing back to the PW practices, where risks, threats, and security requirements already exist. However to me it seems that the remaining tasks focus mainly on functional reliability rather than security outcomes. PS.4.3, for example, would benefit from explicitly addressing security driven rollbacks. Teams often discover vulnerabilities after release through fast feedback mechanisms such as DAST scans or runtime monitoring. PS.4.4 also emphasizes fault tolerance, but the link to availability is weak and implicit.
10 new notional examples
NIST SSDF 1.2 also expands several notional implementation examples. More specifically, PW.1.1 received one additional example. PW.1.3 and PW.5.1 each gained two new examples. PW.4.4, PW.8.2, and RV.1.2 each gained one. PW.9.1 received two new examples. The updates remain limited in scope and do not represent a major evolution of the framework.
Draft status and scope
NIST SSDF 1.2 is currently a draft. All observations and interpretations in this blog refer to the Initial Public Draft released in December 2025.
I have submitted feedback to NIST on this draft. My comments focus mainly on wording improvements in the newly introduced practice PS.4, especially around making the security intent more explicit.
As with any draft standard, the final version of NIST SSDF 1.2 may still change.
Conclusion
I see NIST SSDF 1.2 as a minor refinement and improvement over its predecessor SSDF 1.1. The newly added practice reinforces a simple and clear message: secure software development requires a continuous and consistent approach. Organizations can no longer treat SSDF as a one time compliance exercise. Even in draft form, SSDF 1.2 signals where regulators and buyers expect software security programs to go next.
Managing this level of structure and evidence quickly becomes complex. This is where our tool SAMMY can help. SAMMY provides a unified way to manage application security practices, track SSDF alignment, and demonstrate progress over time. It turns SSDF from a document into an operational system. The support for SSDF 1.2 is not yet in SAMMY, but we plan to add it as soon as the framework gets a final release version.
