What is the NIST Secure Software Software Development Framework and Why Should We (as a Software Vendor) Care?

Last Updated on January 19, 2024

If you sell software to the US federal government, you know that cybersecurity compliance requirements are both evolving and increasing. Among the top areas of focus, as directed in section 4 of Executive Order 14028, “Improving the Nation’s Cybersecurity,” is regulating and enhancing the security of software purchased by the government. NIST 800-218, the Secure Software Development Framework (SSDF) version 1.1, provides “recommendations for mitigating the risk of software vulnerabilities” during the software development lifecycle (SDLC).

To explain why the SSDF is so important for all orgs in the US government software supply chain, Elzar Camper, Pivot Point Security’s Director of Cyber Security Solutions & Practices, headlines a recent episode of The Virtual CISO Podcast. Hosting the show is John Verry, Pivot Point Security CISO and Managing Partner.

4 practices and 42 tasks

As Elzar describes, the SSDF outlines what organizations can do to improve the integrity of the software they develop. Consisting of 4 practices and 42 tasks, it is intended to be used across sectors and within any SDLC methodology, for developing everything from IoT devices to customer-facing web apps to critical business systems.

The SDLC is also designed to be implemented using a phased approach if desired.

“It allows you to set future targets,” Elzar explains. “If your organization initially looks at the four practices and the 42 tasks, and you say, ‘Okay, we’re able to achieve 20 of these in this year,’ then you start to roll in additional tasks as the maturity of your SDLC progresses.”

Unlike some other cybersecurity standards (e.g., CMMC), the SSDF doesn’t define discrete maturity levels. However, the SSDF cross-references a number of other popular software security standards, such as OWASP SAMM or BSIMM.

“This gives that … high-level approach of things organizations can do to really give a third party or the government an understanding of how a piece of software was built,” notes Elzar.

Prepare the Organization

Elzar describes each of the 4 SSDF practices. The first is “Prepare the Organization,” which includes 13 tasks. These cover things like documenting your security requirements and creating the policies, procedures and standards that address the question, “What does your organization need to do to build secure software and maintain the integrity of the software?”

“Prepare the Organization” also includes SDLC roles and responsibilities, communication, and other interactions with third parties (clients, subcontractors, etc.). The SSDF cross-references NIST 800-181, “The National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework.”

“It actually identifies different tasks associated with different parts of the standard,” Elzar says. “So, [for] a software developer, security analyst, etc., it tells you the actual task that individual is going to need to do as part of their job to help the organization meet that practice.”

This practice also underscores the importance of executive support to operationalize your software security program.

Protect the Software

Practice #2 in the SSDL is “Protect the Software.”

“This really focuses on the integrity of the software [during development],” Elzar states. “How is the software being built? Where is the software stored? What access do people have to that repository? How are you doing hashes for released files? How is the software checked out?”

Protect the Software also covers the software bill of materials or SBOM. Is an SBOM available for the software? And is it updated every time the software is released?

“An SBOM can give you a really good understanding of the different third-party libraries and open-source technologies that are associated with a piece of software,” highlights Elzar. “What versions are they? Are they vulnerable? If so, how do you identify them proactively? That’s where the SBOM comes into play.”

An SBOM should be a living, breathing document that tracks third-party code across versions, so users know what libraries are used in the version they’re running. The SBOM should also flag what third-party code has known vulnerabilities—and that process should be automated if possible, so it can scale.

How much detail needs to be in an SBOM? Do you have to give away your competitive “secret sauce”?

“When you’re dealing with the government, they’re going to draw the line,” relates Elzar. “They’re going to tell you exactly what they want from you [in terms of an SBOM].”

Produce Well-Secured Software

SSDF practice #3 is “Produce Well-Secured Software,” which includes 16 tasks. This practice focuses on delivering secure software with minimal security vulnerabilities. It includes tasks like risk modeling and threat modeling, as well as secure coding practices. It also covers the use of off-the-shelf security services/modules, such as encryption, log management or identity management.

“Don’t reinvent the wheel,” Elzar offers. “Use what’s out there if it’s been vetted and has eyes on it on a regular basis.”

This practice also supports efforts to automate secure coding practices. Manual security tasks might not be practical in SDLCs (e.g., DevOps environments) where new releases take place daily or multiple times per week.

“They’re really trying to push people towards the idea that you can have a person doing it—which is fine for some organizations—or if you can, when you can, try to automate as much as possible because you want to make sure that you’re not slowing down the process,” reports Elzar. “You’re speeding it up. But you’re also speeding it up while you’re ensuring the integrity of the software.”

Respond to Vulnerabilities

SSDF practice #4 is “Respond to Vulnerabilities.” This includes tasks like monitoring the vulnerability databases, gathering threat intelligence (hopefully leveraging automation), updating your SBOM, and tracking and disclosing vulnerabilities to customers and other stakeholders in line with your policy.

“It’s not just tracking and saying, ‘Okay, we do track it,’” clarifies Elzar. “It’s how are you going to respond to it? How are you going to handle inquiries from your customers? How are you going to handle releases, things like that? And then are you doing things like root cause analysis? Are you not just identifying the vulnerabilities and fixing them, but are you looking at what went wrong somewhere in the SDLC, somewhere in your process, standards, or procedures to say, ‘Okay, we had another cross-site scripting vulnerability. This is the third one we’ve had this year. Is it a training issue? Do we need better coding practices? What is really the problem and why does this continue to happen?’”

This practice also draws a feedback loop for continuous improvement. It recommends continuously reviewing and updating your SDLC to make sure you’re being proactive when you find problems. It’s also about moving your software security maturity level forward.

What’s next?

To hear the complete show with Elzar Camper, click here.

How does OWASP SAMM compare with the NIST SSDF? This blog post gives you an overview: What is OWASP SAMM and Why Should We (as an Org that Develops Software) Care?