On September 14, 2022, the U.S. federal government’s Office of Management and Budget (OMB) published a memo with new guidance for federal agencies related to software supply chain security. The memo directs government agencies to require software suppliers to self-attest that they have adhered to NIST Guidance for secure software development. Agencies must obtain this self-attestation for a piece of new software before using it.

“NIST Guidance” refers to guidelines in two publications: The Secure Software Development Framework (SSDF) SP 800-218 and Software Supply Chain Security Guidance Under Executive Order (EO) 14028. (We’ll provide more information on these documents later in this post.)

The memo elaborates on the Biden Administration's 2021 cybersecurity executive order, which called on the federal government to, “make bold changes and significant investments (in cybersecurity) in order to defend the vital institutions that underpin the American way of life.”

At FOSSA, we specialize in helping companies reduce the security and license compliance risks that can come with open source software. Open source is a major part of the software supply chain for the vast majority of modern applications, so it’s only natural for us to explore the ramifications of this memo for government agencies and the private sector.

Editor’s Note: Assume the phrase “NIST Guidance” refers to the guidelines in SP 800-218 and NIST’s Software Supply Chain Security Guidance unless otherwise noted.

An Overview of “NIST Guidance” for Secure Software Development

Before we dive into the specifics of the self-attestation memo, let’s briefly touch on the secure development processes that software suppliers must attest to following — i.e. “NIST Guidance.”

As mentioned, NIST Guidance includes the practices outlined in the following two documents:

  • SP 800-218
  • Software Supply Chain Security Guidance Under Executive Order (EO) 14028

These documents build on Section 4 of the Cybersecurity Executive Order, which, in part, required the U.S. federal government to “issue guidance identifying practices that enhance the security of the software supply chain.”

It’s important to note that these publications define secure software development practices from two different viewpoints

  • SP 800-218 addresses Section 4e from the perspective of a software producer. It outlines secure development practices software suppliers must follow, such as data encryption, automation to identify and remediate vulnerabilities, multi-factor authentication, and more
  • Software Supply Chain Security Guidance Under Executive Order (EO) 14028 addresses these requirements through the lens of a software purchaser — i.e. a federal agency. It’s intended to help agencies make sure they acquire software that has been developed in accordance with secure development practices.

Secure Software Self-Attestation Memo Scope and Requirements

The memo applies to all federal government agencies. It requires these agencies to use only third-party software developed in accordance with NIST Guidance. This includes firmware, operating systems, applications, cloud-based software, and products containing software.

The memo covers new software (developed after the effective date of the memo) and existing software that’s “modified by major version changes.” Since it is aimed at securing the software supply chain, it does not apply to agency-developed software, though agencies are expected to follow secure software development practices.

This self-attestation must include:

  • The name of the software producer
  • A description of the software products included
  • A statement of attestation

Special Cases

There are a few exceptions to the memo’s self-attestation requirement:

  1. In cases where the software producer can’t attest to compliance with part or all of NIST’s Guidance, it must identify the gaps and develop a plan to mitigate risk. The agency can then make a risk analysis to evaluate whether to use the software.
  2. In cases where there is a higher level of risk due to the criticality of the software that is being acquired, a third-party assessment may be required.
  3. A third-party assessment is an acceptable replacement for self-attestation if the software producer is unable to complete a self-attestation. The third-party assessment should be conducted by a “FedRAMP Third Party Assessor Organization (3PAO) or one approved by the agency."
  4. For critical software, a software bill of materials (SBOM) may also be required by the agency, and the agency must retain the SBOM or link to it in cases where the software producer posts it publicly. These SBOMs must be generated in a format such as SPDX.

Self-Attestation Memo Timeline

The memo establishes a timeline for agencies to build new processes and implement new policies to achieve compliance with the NIST Guidelines. Here are a few of the key milestones.

  • Within 90 days: Inventory all software covered by the memo
  • Within 120 days: Develop a process to communicate these new requirements to vendors, and develop a centralized system for self-attestation forms
  • Within 270 days: Collect attestation forms for critical software
  • Within 365 days: Collect attestation forms for all software covered by the memo

Also, within 120 days of the memo’s release, CISA is required to create a standardized self-attestation form that can be used by multiple agencies. And, within 180 days, OMB will establish requirements for a centralized system for attestations and artifacts.

How To Fulfill the Memo’s Requirements

Although this memo is directed toward federal agencies, it’s also quite relevant to private enterprises. For one, organizations that provide software to the federal government will now be required to attest to following NIST Guidance for secure software development.

Additionally, there’s been a global trend toward requiring increased assurance from vendors about product security in the private sector, and action like this certainly won’t change that.

Realistically, software suppliers (especially large ones) will likely need a mix of tools, people, and processes to meet NIST’s guidelines. And, software composition analysis solutions like FOSSA are an important part of the equation.

For example: