SSDF 1.2 sees AppSec as a journey

The National Institute of Standards and Technology is tweaking a key tool that has helped development organizations produce more secure code, shifting its focus to securing the broader software development lifecycle (SDLC).

Although the changes proposed in version 1.2 of NIST’s Software Security Development Framework (SSDF) are less sweeping than those adopted in the previous update, they signify a clear shift in guidance, from “write secure code” to “operate secure software.”

Jeff Williams, CTO and co-founder of Contrast Security, called it “a surprisingly practical move” that reflects a more realistic view of how application security (AppSec) works in the real world. 

Previous frameworks and maturity models were heavily focused on a ‘fix everything in development’ philosophy. We need a framework that recognizes that fixing everything is a fool’s errand and that organizations need to balance secure development with protecting applications in production.

Jeff Williams

Here’s what your application security team needs to know about SSDF 1.2.

See webinar: AI Redefines Software Risk: Develop a New Playbook

A new era for the SSDF

Tim Freestone, chief strategy and marketing officer at Kiteworks, said the extension of the SSDF is long overdue, and the ramifications are profound.

Security doesn’t end when code ships — it’s a continuous operational discipline that extends throughout software’s entire lifecycle. This shift means development teams can no longer consider their security obligations complete at deployment. They must ensure software stays secure after it ships through ongoing monitoring, update management, and continuous improvement mechanisms.

Tim Freestone

Freestone said that organizations that follow version 1.2’s recommendations will need to invest in capabilities they may have previously considered optional: comprehensive observability, real-time intrusion detection with AI-based anomaly detection, automated patching infrastructure, and the ability to respond rapidly to new vulnerabilities. 

And, he added, the change will require “breaking down traditional silos between development, operations, and security teams and moving from point-in-time compliance to continuous validation and operational resilience.”

A broader scope of responsibility

Rosario Mastrogiacomo, chief strategy officer at Sphere Technology Solutions, said that with SSDF 1.2, security “must extend into operations, deployment, and post-release maintenance.” 

It also places greater emphasis on identity, access control, and infrastructure hygiene as part of overall software security.

Rosario Mastrogiacomo

Avi Hein, senior product marketing manager at Checkmarx, said SSDF 1.2 takes into account the increasing complexity of software, cloud environments, and identity-centric threats. “It expands the focus beyond secure coding to include secure operation, aligning guidance with today’s real-world risks,” he said, changing the story “from attestation to evidence.” 

SSDF 1.1 focused largely on what teams should do to write secure code. It let organizations treat security as a compliance checkbox — pass an audit, sign the form, move on.

Avi Hein

Hein said that what SSDF 1.1 didn’t address was the reality that security posture degrades without continuous measurement. “SSDF 1.2 shifts to how organizations must operate software securely over time,” he said.

Version 1.2 formalized that with a proposed new practice under the topic “Prepare the Organization.” That practice — PO 6.0, “Define and Implement a Continuous Process Improvement Plan” — focuses on continuous process improvement across the entire SDLC.

Organizations now need to generate ongoing evidence of improvement, not just point-in-time attestation, Hein said. “1.2 requires proving we’re getting better over time,” he said.

However, “you cannot comply with SSDF 1.2 using tools alone,” he said. “You need process maturity. PO 6.0’s continuous improvement mandate requires regular assessment and gap analysis. You can’t improve what you don’t measure.”

AppSec needs continuous updating

Writing in a blog post, Aram Hovsepyan, founder and CEO of Codific, said PO 6.0 formalizes an idea that many teams already recognize: Security is a journey, not a destination. SSDF 1.2 recommends that teams continuously update development environments, he wrote. 

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.

Aram Hovsepyan

Kat Cosgrove, head of developer advocacy at Minimus, said updating development environments is essential because “everything from the IDE to the operating system is a potential way for bad actors to wreak havoc on your systems or the systems of your users.” 

Ensuring that everything stays up to date is a relatively low-effort way to make attacking you more effort than it’s worth.

Kat Cosgrove

PO 6.0 also stresses the importance of proactively preventing software errors, said Kiteworks’ Freestone. “The advantages of proactively hunting for software errors rather than waiting for them to manifest are both economic and strategic,” he said.

Research demonstrates that fixing defects discovered during implementation costs six times more than addressing them during design, while errors found after product launch can be 100 times more expensive. For organizations deploying software at scale, these multipliers translate to millions in potential savings.

Tim Freestone

Beyond cost reduction, proactive detection prevents the accumulation of security debt — unresolved, highly exploitable vulnerabilities that linger for years because reactive remediation keeps teams from keeping pace with threats, Freestone added. “Perhaps most critically, proactive approaches enable detection of unknown unknowns through anomaly detection that identifies suspicious behavior patterns manual testing would miss, protecting business continuity and customer trust before issues become incidents.”

Finding blind spots

Codific’s Hovsepyan said PO 6.0 also strengthens vulnerability response by recommending that teams review how they handle vulnerabilities — and that they revisit past decisions. “This creates feedback loops between incidents, remediation, and future prevention,” he wrote.

Sphere Technology’s Mastrogiacomo said reviewing past decisions can reveal blind spots and process weaknesses. “It helps teams understand what worked, what didn’t, and how to improve future incident response. This kind of reflection is critical for maturing vulnerability management and ensuring decisions stay relevant over time,” he said.

Proactively hunting for vulnerabilities lets organizations find them before malicious actors do, said David Lindner, Contrast Security’s CISO and data privacy officer.

The advantage is control. Finding a vulnerability internally allows the organization to choose the best path forward, whether that is a code fix, a configuration change, or relying on application detection and response, or ADR, to monitor and mitigate the risk in the runtime environment.

David Lindner

Organizations can measure the effectiveness of being more proactive, he said, by tracking the vulnerability escape rate. “This metric identifies how many security vulnerabilities escaped the internal processes and were only discovered once the software was live,” he said. “By measuring the number of vulnerabilities found in the wild per month or quarter, the organization can validate its controls. A declining escape rate proves that the proactive tools are working.”

Software needs continuous updating

The proposed new version of the SSDF also treats software updates as a core security capability. It asks teams to thoroughly test every software release, introduces tiered release strategies, recommends robust rollback mechanisms, and advises that update engines and delivery pipelines be kept reliable and secure.

Testing every software release will be challenging for many organizations. “Software testing is difficult. Really difficult,” Contrast Security’s Williams said. “Think of a massive enterprise application environment like Facebook or Citi. It’s almost impossible to create a test environment that looks like production.”

Writing automated tests is difficult and expensive — although AI can help. And keeping those tests up to date with changes is also a massive effort. So many companies simply don’t do nearly as much testing as you would think.

Jeff Williams

Checkmarx’s Hein noted that tiered releases can reduce risk. By using canary deployments, teams can treat production as a final validation environment because test environments never perfectly replicate real-world conditions, he said. “The tiered release requirement means deploying to 1% to 5% of your users first, monitoring for anomalies, then progressively expanding,” he said. “If issues surface, you’ve contained impact to a fraction of your user base.”

This isn’t just about bugs. It’s about detecting security issues that only manifest under production traffic patterns, real user behaviors, or specific configurations your test environment didn’t cover. If you’re going to fail, better to fail in front of 1,000 users, not 1 million.

Avi Hein

Recent attacks highlight risk from updates

Erik Shreve, team lead for applied systems engineering at Carnegie Mellon University’s Software Engineering Institute, said the CrowdStrike-related outages of July 2024 demonstrated the inherent risks of software updates. “A faulty update can result in a large-scale denial of service. Robust rollback mechanisms allow organizations to expeditiously restore their systems to an operational state and then perform an update once the vendor has corrected the issue.”

But Shreve sees continuity between versions 1.1 and 1.2 of the SSDF.

While the SSDF update includes additional guidance for the operation of software, I would not describe this as a shift away from prior guidance, as the scope of the SSDF previously included the operational and maintenance phases of the software development lifecycle. However, the update strengthens the recommended practices and tasks supporting those phases.

Erik Shreve

If followed, these additional guidelines should help organizations avoid incidents and reduce the time to respond to incidents, Shreve said.