What is the NIST SP 800-218 (Draft) “Secure Software Development Framework” and Why Should We (as an Org Selling Software to the USG) Care?

Last Updated on January 19, 2024

One of the most significant sections of the recent Executive Order on Improving the Nation’s Cybersecurity is Section 4: Enhancing Software Supply Chain Security. This emphasis reflects the fact that vulnerable software or insecure design is the root cause of many cyber security issues today. (Arguably the actual root cause is the global education system when it comes to software engineering or the understandable obsession with time-to-market, but let’s not “go there” in this post.)

There’s a lot in Section 4 (it’s 2,110 words), but I want to highlight a few things that underscore why you should pay attention to the new NIST SP 800-218 (Draft) “Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities.”

Forthcoming regulations for software vendors

First, take a look at how the US government plans to enforce secure software development practices for contractors:

Section 4(n): Within 1 year of the date of this order, the Secretary of Homeland Security, in consultation with the Secretary of Defense, the Attorney General, the Director of OMB, and the Administrator of the Office of Electronic Government within OMB, shall recommend to the FAR Council contract language requiring suppliers of software available for purchase by agencies to comply with, and attest to complying with, any requirements issued pursuant to subsections (g) through (k) of this section.

If all goes according to plan, in May 2022, the Federal Acquisition Regulation (FAR) Council will begin drafting new regulations that mandate contractors selling software to the US government to comply with the SSDF, with a priority on “critical software” as defined in Definition of Critical Software Under Executive Order (EO) 14028, dated October 13. 2021:

EO-critical software is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:

• is designed to run with elevated privilege or manage privileges.
• has direct or privileged access to networking or computing resources.
• is designed to control access to data or operational technology.
• performs a function critical to trust; or,
• operates outside of normal trust boundaries with privileged access.

The definition applies to software of all forms (e.g., standalone software, software integral to specific devices or hardware components, cloud-based software) purchased for, or deployed in, production systems and used for operational purposes. Other use cases, such as software solely used for research or testing that is not deployed in production systems, are outside of the scope of this definition.

The Definition of Critical Software Under Executive Order (EO) 14028 also includes a preliminary list of software categories considered to be EO-critical.

When is this happening?

Another interesting fact noted in Definition of Critical Software Under Executive Order (EO) 14028 is:

NIST “recommends that the initial EO implementation phase focus on standalone, on-premises software that has security-critical functions or poses similar significant potential for harm if compromised.” Subsequent phases may address other categories of software such as:

• software that controls access to data.
• cloud-based and hybrid software.
• software development tools such as code repository systems, development tools,
• testing software, integration software, packaging software, and deployment software.
• software components in boot-level firmware; or
• software components in operational technology (OT).

Who will be impacted first?

Reading between the lines, I suspect NIST knows this will be a challenging task for many SMBs and is initially focusing on larger contractors before pivoting to smaller markets. However, in my opinion, Prime Contractors will be the initial driving force pushing subcontractors to attest to and be compliant with the SSDF via flow-down requirements. I also believe marketing and sales departments will rightfully promote their compliance with SSDF and use it to their advantage against competing firms.

Aligning with the SSDF

The SSDF is broken up into four practices: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. I was happy to note that the SSDF is flexible, customizable, provides high-level guidance, and is mapped to many well-known existing software security frameworks and standards from the Open Web Application Security Project (OWASP) and others. The SSDF also provides tasks and implementation examples per each practice, with much more information available in the references.

The Cybersecurity Executive Order did not specify who must attest to SSDF compliance. But a NIST-sponsored webinar held on November 8, 2021, stated that attesting to SSDF compliance represents a claim made to the market (and ultimately the US government—don’t forget about the False Claims Act) that must be supported by appropriate evidence and artifacts. The expectation is that some organizations will do first-party attestations and other will hire a third-party firm.

Changes are difficult in any department or organization. But adding security to the software development lifecycle (SDLC) could be one of the most challenging shifts, especially for SMBs.

What’s Next?

I highly recommend that organizations providing software to the US government review Section 4 of the Cybersecurity Executive Order alongside NIST SP 800-218 (DRAFT) v1.1, and begin the process of aligning to the practices outlined in the SSDF. Security must be viewed strategically as a business enabler versus a showstopper. Be proactive, take your time and do it right.

Here are some blog posts that provide further detail about the Cybersecurity Executive Order and  the Open Web Application Security Project (OWASP) for further reading:

The Cyber Executive Order: 5 Coming Changes for Federal Agencies – Pivot Point Security

OWASP ASVS Levels: Which is Right for My Application? – Pivot Point Security