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 Notes: Assume the phrase “NIST Guidance” refers to the guidelines in SP 800-218 and NIST’s Software Supply Chain Security Guidance unless otherwise noted.

This post was updated on June 12, 2023, with additional information on the draft version of the self-attestation common form and the timeline for software suppliers to complete self-attestations.

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 or CycloneDX.
  5. Software that's either a) developed by a federal agency or b) "freely obtained" (such as open source or freeware) directly by a federal agency doesn't require a self-attestation.

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. Under the original timeline, federal agencies were required to collect attestation forms for critical software by June 11, 2023 and for all other software covered by the memo by Sept. 13, 2023.

However, it took longer than expected for the draft version of the self-attestation form to be released; as such, the deadlines for federal agencices to acquire forms from their suppliers have also been pushed back.

On June 9, 2023, OMB published a new timeline:

  • No later than three months after the self-attestation form is approved: Agencies must collect attestations for critical software
  • No later than six months after the self-attestation form is approved: Agencies must collect attestations for all other software covered by the memo

However, as of this writing, the self-attestation form has not yet been approved, so the precise dates by which agencies must collect forms are still somewhat unclear.

Self-Attestation Form Details

On April 27, 2023, CISA released a draft version of the proposed attestation form along with a 60-day Request for Comment. (The goal of the Request for Comment is to gather public feedback on the content of the draft form.)

You can access the complete draft form on CISA's website, but a few of the highlights are as follows:

Secure Development Environments: Producers must attest to developing software in secure environments, including actions like enforcing multi-factor authentication, encrypting sensitive data, logging and auditing trust relationships used for access and authorization, and more.

Software Supply Chain Security: Producers are required to attest to using automated tools (or similar processes) to ensure trusted source code supply chains. Additionally, producers must develop a process to address security risks from third-party components.

Software Provenance: Producers must attest to maintaining provenance data for third-party and internal code. For context, NIST defines provenance, in part, as "the chronology of the origin, development, ownership, location, and changes to a system or system component."

Vulnerability Management Tools and Processes: Producers are required to attest to using automated tools (or "comparable" processes) to check for security vulnerabilities. Additionally, producers must make sure that these tools or processes are used on a regular basis and that they have a policy in place to remediate vulnerabilities before products are released. Finally, the producer also must operate a vulnerability disclosure program that "accepts, reviews, and addresses disclosed software vulnerabilities in a timely fashion."

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: