What does the Federal Guidance on Securing the Software Supply Chain Mean for Developers?

Last month, the National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), and Office of the Director of National Intelligence (ODNI) released the final installment of its Securing The Software Supply Chain series. 

Part one provided guidance for developers and was released in August 2022. Part two provided guidance for suppliers in October 2022. And the third part, provided guidance for customers. In this blog, we’ll take a look at Part One, specifically section 2.1: Secure Product Criteria and Management. 

What is the Securing the Software Supply Chain Guidance from ESF Partners, NSA, and CISA Software?

The guidance comes from the Enduring Security Framework (ESF)—a public-private cross-sector working group led by NSA and CISA that provides cybersecurity guidance to address high priority threats to the nation’s critical infrastructure. 

It is the result of investigations into Solar Winds, an attack which revealed the need to create a set of industry and government evaluated best practices focusing on the needs of the software supplier. Up to 80% of the code today is inherited from third parties. Generally, accepting third party code should not continue without additional testing and assurance that that code is secure.

Common methods of compromise used against software supply chains include exploitation of software design flaws, incorporation of vulnerable third-party components into a software product, infiltration of the supplier’s network with malicious code prior to the final software product being delivered, and injection of malicious software that is then deployed by the customer. 

Guidance for Developers

In response to ongoing attacks against the infrastructure of the United States, the White House released an Executive Order on Improving the Nation’s Cybersecurity (EO 14028) in 2021. It established new requirements to secure the federal government’s software supply chain involving systematic reviews, process improvements, and security standards for both software suppliers and developers, in addition to customers who acquire software for the Federal Government. 

To address this, part one of the new guidance includes security requirements planning, designing software architecture from a security perspective, adding security features, and maintaining the security of software and the underlying infrastructure.

Where Mayhem Fits In

In the above diagram, fuzz testing provided by Mayhem would fall between DAST and Pen Test in the test segment under developers. “Developers should perform unit- and system-level security tests that are validated by QA,” the report states. “This allows QA to perform further security testing to cover a broader and deeper set of tests with less duplication of effort.” 

In addition to Static Analysis and Software Composition Analysis, the report explicitly cites: “Fuzzing should be performed on all software components during development to ensure that they exhibit expected behavior with different inputs. Results should be documented, and any anomalies or vulnerabilities should be addressed.”

In another blog we’ll take a deeper look at NIST 800-218, which is heavily referenced in the Securing The Software Chain series part one. Specifically, we’ll look at the call to use fuzz testing and where that fits into your development life cycle.