Press Release
Last Updated on January 18, 2024
The National Institute of Standards and Technology recently updated NIST SP 800-218, the Secure Software Development Framework (SSDF), now at Version 1.1. Cybersecurity experts in the US federal government considered this document so important that they mandated its revision in Executive Order 14028 from May 2021, on “Improving the Nation’s Cybersecurity.” The order also directed the Office of Management & Budget (OMB) to begin requiring SSDF compliance in federal contracts, per changes now being made in the Federal Acquisition Regulation (FAR).
The SSDF “makes recommendations for mitigating the risk of software vulnerabilities.” It is meant to be leveraged across the US government’s software supply chain, as well as with software used by critical infrastructure companies and other public firms. But there are already comprehensive, widely accepted standards already out there, like the Building Security in Maturity Model (BSIMM) and OWASP’s Application Security Maturity Model (SAMM). Why reinvent the wheel and create more hurdles for suppliers?
To compare SSDF with other software security standards and frameworks, a recent episode of The Virtual CISO Podcast features Elzar Camper, Pivot Point Security’s Director of Cyber Security Solutions & Practices. The show’s host is John Verry, Pivot Point Security CISO and Managing Partner.
Cross-referencing other frameworks
Elzar characterizes the SSDF as non-prescriptive, while OWASP SAMM and BSIMM as “maturity models” are much more prescriptive on what to do and how to do it. Rather than recapitulate all that proven guidance, the SSDF maps these popular maturity models to its task-level recommendations.
“The SSDF is a high-level framework of things you should do,” Elzar clarifies. “This is the concept, this is the practice, this is the task. But the references are really where the strength of the SSDF comes into play.”
The SSDF relates the general concept from the practice and the task to how you could achieve it and what it could look like at a high level. Then it maps to a number of other frameworks and standards to provide the implementation details.
John summarizes the relationship between the SSDF and other secure software frameworks: “The SSDF is the what and the why, and then it gives you references to things like OWASP and BSIMM for potential ways how.”
Building quality in upfront
Elzar emphasizes another advantage of the SSDF: it’s broadly applicable and aligns readily with other guidance teams may be using.
“Organizations that have a mature SDLC, they’re not going to have to reinvent the wheel or change anything,” describes Elzar. “It’s basically just a mapping exercise.”
Elzar adds: “Anytime a new standard comes out, I always hold my breath for a second. Are we making this overly complicated? Are we going to make organizations jump through additional hoops that are going to increase costs and things like that? While the SSDF is going to make organizations do mapping exercises or gap assessments, I think it’s well intentioned and I think it has to happen.”
“The idea of shifting left has to happen from the standpoint of information security,” underscores Elzar. “Proactively trying to get in front of vulnerabilities within software is extremely important. I don’t see how else, outside of doing this, you can start to reduce the backend cost of penetration testing and vulnerability assessments. All these things are still important, but that’s not where the investments should really be. You need to start shifting left and invest in building quality code from the beginning.”
What’s next?
To listen to the complete podcast episode with Elzar Camper, click here.
Is your SaaS development environment secure? This podcast could be a real eye-opener: EP#33- Ryan Buckley – The Secrets to Keeping Your SaaS Secure
