March 22, 2022

Last Updated on January 19, 2024

Based on hard lessons learned from the SolarWinds attack plus “smell the coffee” guidance like the Biden administration’s May 2021 Executive Order 14028 on cybersecurity, these realities are undeniable:

  • The world runs on software. Even the hardware that runs our software is now software.
  • That software—from our development environments to the running application to the underlying “infrastructure as code”—leaves us vulnerable to cyber-attack.
  • Software supply chains in both private and public sectors are increasingly being targeted by sophisticated adversaries as well as opportunistic hackers.
  • A big reason why is that so few software development lifecycle models/processes address software security in a comprehensive or effective way.

In specific response to directives in EO 14028, the National Institute of Standards and Technology (NIST) just published the “final” version 1.1 of its Special Publication (SP) 800-218, Secure Software Development Framework (SSDF): Recommendations for Mitigating the Risk of Software Vulnerabilities, following a public comment period.

Why do we need another framework to tell organizations how to do what they’ve consistently not prioritized for reasons like cost, time-to-market and/or lack of secure coding skills? And what makes the new SSDF so important to US government contractors and their suppliers that sell software?

New federal regulations are coming

According to NIST, the SSDF incorporates “… a set of fundamental, sound, and secure software development practices based on established secure software development practice documents … Following the SSDF practices should help software producers reduce the number of vulnerabilities in released software, reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of vulnerabilities to prevent recurrences.”

But why should SaaS vendors, internal software development teams and software buyers leverage the NIST SSDF versus accepted guidance like the OWASP ASVS, ISO 27034, the Building Security In Maturity Model (BSIMM), the BSA Framework for Secure Software and others?

Simple: SSDF compliance is about to be mandated for US government agencies and their supply chain partners.

How the SSDF will drive secure software development

According to Section 4 of EO 14028:

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.

This means that by May 2022, the Federal Acquisition Regulation (FAR) Council will draft new regulations mandating vendors selling software to the USG to comply with the SSDF. That especially includes “critical software” like cloud-based services, development/DevOps tools, and more.

When will new FAR (and presumably DFARS) clauses appear in contracts? Probably by late 2022 or early 2023 at the latest. Further, the EO authorizes the FAR changes to include removing non-compliant software from a wide range of contracts where it is currently specified.

What will SSDF compliance look like?

Based on experience with other USG compliance efforts like CMMC and DFARS/NIST 800-171, the initial primary driver for SSDF compliance is likely to be major USG contractors that must “flow down” SSDF requirements to subcontractors so they can attest to compliance themselves. This will quickly make SSDF compliance a competitive differentiator in the USG supply chain marketplace.

What’s to stop organizations from proclaiming SSDF alignment, since the framework isn’t prescriptive and NIST has no audit or enforcement mechanisms? The False Claims Act, enforced by the US Department of Justice (DoJ), provides—and has recently resulted in—onerous penalties for any person or company that knowingly makes false claims in the marketplace, especially when that marketplace includes the USG.

In other words, claims of SSDF “alignment” need to be accompanied by credible evidence and artifacts, whether the attestations are based on in-house or third-party assessments.

How can the NIST SSDF benefit software security?

The SSDF consolidates and cross-references longstanding best-practice recommendations in a way that is understandable to both business and technical stakeholders. Its high-level, customizable, sector-agnostic approach enables cross-department (and producer/consumer) communications to help define strategic goals and assess current gaps.

Another benefit of the SSDF is that it maps EO 14028’s software supply chain directives to three key initiatives it supports:

  • Critical software definition and security measures (e.g., a software bill of materials (SBOM) to help secure open-source software components)
  • The recommended minimum standard for vendor or developer verification of code
  • Cybersecurity labeling for consumers regarding Internet of Things (IoT) devices and software

While there has long been a perception that software teams need to “push security left” and implement a secure software development lifecycle end-to-end, this has been easier said than done—especially given the rapid pace of DevOps and the resource/skills challenges many SMBs face.

NIST has architected the SSDF to help firms of all sizes align and prioritize their secure software development activities with business goals, identified risks and resource constraints. NIST calls the SSDF “outcome-based” and designed it to simplify comparing current software security practices with SSDF practices. From there, teams can better decide which practices to implement, and how.

What are the SSDF practices?

The SSDF’s practices fall into four categories:

  • Prepare the Organization (PO): Ensure that your people, processes, and technology are ready to perform secure software development.
  • Protect the Software (PS): Protect all components of the software from tampering and unauthorized access.
  • Produce Well-Secured Software (PW): Produce secure software with minimal security vulnerabilities.
  • Respond to Vulnerabilities (RV): Identify outstanding vulnerabilities in deployed releases and respond appropriately to address them, as well as to prevent similar vulnerabilities from occurring in the future.

NIST recommends balancing risk against cost, feasibility, and applicability when deciding which practices to implement. Whether a control can be automated and whether it is an advanced capability with dependencies on more basic controls are further considerations.

Overall, NIST considers that, “The SSDF’s practices, tasks, and implementation examples represent a starting point to consider; they are meant to be changed and customized, and to evolve over time.”

The SSDF is not a checklist you should follow, but instead provides guidance for planning and implementing a risk-based approach to secure software development.

What’s Next?

With the guidelines in EO 14028 now taking shape in the form of guidance like the NIST SSDF, secure software development is rapidly becoming a mandated priority on a massive scale that will impact the entire security industry.

As a first step to assessing where you are today and where you want to go, security leaders in the USG supply chain should carefully review both EO 14028 (especially Section 4, aka “The SolarWinds section”) and the final SSDF.

For expert advice on how best to achieve “provable alignment” with the SSDF, contact Pivot Point Security. We offer a range of SSDF related services to help you get started, strategize and fill skills gaps as you move ahead.