On June 9, 2023, the White House Office of Management and Budget (OMB) issued Memorandum M-23-16, which delays implementation of a key secure software attestation requirement. The delay was necessary because the Cybersecurity and Infrastructure Security Agency (CISA) has not finalized the form which will be used for the attestation. The attestation requirement will now be effective after final publication of the form: three months after publication for “critical software” and six months after publication for all other software.

Background

On September 14, 2022, OMB issued guidance concerning a key requirement of Executive Order (EO) 14028, which directs federal agencies to enhance the security and integrity of the federal software supply chain. EO 14028 was the impetus for the National Institute of Standards and Technology (NIST) to release its Secure Software Development Framework (SSDF),SP 800- 218, and Software Supply Chain Security Guidance. It was also the basis for the Software Bill of Materials guidance published by the Commerce Department and the National Telecommunications and Information Administration in 2022.

The EO states that federal agencies can only use software provided by producers who attest to their compliance with government-specified standards drawn from the NIST SSDF. The September OMB Memo originally directed agencies to collect attestations for “critical software”¹ by June 11, 2023, and for all other software by September 14, 2023.

Memorandum M-23-16, which extends this deadline, is not directly binding on the private sector, but it does direct federal agencies to promulgate standards, adopt new procurement regulations (including Federal Acquisition Regulation (FAR) and Defense Federal Acquisition Regulation Supplement regulations containing contractually binding federal contracts clauses), and issue other requirements which will ultimately impact federal contractors.

Revised Timeline for the Attestation Requirement

The attestation requirement will apply to software:

1. developed after September 14, 2022,
2. modified by major version changes after September 14, 2022, or
3. is a hosted service that deploys continuous updates.

This requirement will be implemented through an attestation form being developed by CISA, which released the draft form for comment on April 27, 2023.

Memorandum M-23-16 sets new deadlines for attestation collection and relates them to publication of the final attestation form:

• The deadline for agencies to require attestations for critical software is now three months after publication of the final Attestation Form.
• The deadline for all other software will be six months after publication of the final Attestation Form.
• OMB has not specified a date for publication of the final Attestation Form.

Clarifying the Attestation Requirements

In addition to updating the timeline for implementation, Memorandum M-23-16 also clarifies the intended scope of the attestation requirements in several respects.

Attestations Must Address Risks Related to Third-Party Components

First, the Memorandum emphasizes that the supplier attestations will be required to address the entirety of the software end product, including any third-party components. The onus will be on suppliers to account for risks related to “third-party” components, whether those components are proprietary or open source in origin. The collection and submission of attestations covering components from third parties falls to the producer of the software end product; contracting agencies will not be required to “reach out” further down the supply chain.

Companies Do Not Need to Provide Attestations for Freely Obtained and Publicly Available Proprietary Software

Second, the Memorandum clarifies that agencies will not be required to collect attestations for products that are proprietary but freely obtained and publicly available. There are a significant number of essential software applications, such as browsers, which agencies could not feasibly obtain attestations for as users have no opportunity to negotiate with the producer. The agencies themselves must assess and minimize risks related to such software.

Agency-Developed Software Remains out of Scope, but Software Developed by a Contractor on Behalf of an Agency May Be Covered

Agency-developed software is excluded from attestation requirements, as originally announced in Memorandum M-22-18. However, Memorandum M-23-16 specifies that the attestation requirement may apply to software developed on behalf of an agency by a contractor. Agency CIOs will make determinations regarding whether software developed by contractors should be considered agency-developed (and thus exempt from attestation collection requirements).

Limited Allowance for Plans of Action and Milestones

Memorandum M-23-16 continues to allow for the use of a Plan of Action and Milestones (POAM) “as an alternative,” when software producers are unable to provide the attestation. However, before using software that is accompanied by a POAM rather than an attestation, agencies must seek OMB authorization. The request to OMB, characterized as a request for an “extension” of the attestation deadline, must be accompanied by a copy of the POAM, and must be based on information demonstrating that the software producer has:

• identified the practices to which they cannot attest;
• documented the practices they have applied to mitigate associated risks; and
• submitted a satisfactory POAM.

Government contractors should expect all new solicitations to include the attestation requirement immediately after release of the FAR clause. Software developers should also expect that the government will begin modifying existing contracts, including blanket purchase agreements and GSA schedule contracts, to include the attestation requirement. To ensure eligibility for new awards, and to reduce the risk of disruption of existing contracts, contractors should review the NIST standards, determine if their products qualify as critical software, and assess their ability to comply with the attestation requirements included in the draft attestation form. In addition, developers who rely on third parties for software development should begin efforts to assess and collect information from those parties to support future attestation requirements.

^[1]For purposes of EO 14028, NIST defines “critical software” to include all software that 1) is designed to run with elevated privilege or manage privileges; 2) has direct or privileged access to networking or computing resources; 3) is designed to control access to data or operational technology; 4) performs a function critical to trust; or 5) operates outside of normal trust boundaries with privileged access.