Implementing the Executive Order

Executive Orders set directions and requirements for the executive agencies to implement into their own rules. These agency rules need to go through regular administrative practices, such as "notice and comment" periods before they can become effective.

Based on a preliminary memo sent last year, organizations were required to provide attestations regarding their secure development practices for critical software by June 11, 2023. However, the final version of the self-attestation form, which is currently open for public feedback until late June, has not yet been released. This raised concerns about how organizations could meet the attestation requirement without a finalized form.

Last Friday, the Office of Management and Budget released Memo M-23-16 clarifying these questions. The memo extends the compliance dates by at least 3 months for critical software and 6 months for all other software. It is important to note that these timeframes will commence 3 months and 6 months after the approval of the attestation form, which is expected to occur after the comment period ends in late June. The table below presents the updated schedule outlined in M-23-16:

Requirement	Actions following publication	Responsible Body
Agencies shall collect attestation letters for "critical software" subject to the requirements of M-22-18, as amended by this memorandum.	3 months after OMB PRA approval of common form	Agencies
Agencies shall collect attestation letters for all software subject to the requirements of M-22-18, as amended by this memorandum.	6 months after OMB PRA approval of common form	Agencies
OMB will begin to collect metrics on agency approval of POA&Ms, as well as the number of extensions and waivers in place at each agency.	Within 1 year of issuance of this memorandum	OMB

Accordingly, mandatory attestation compliance dates for critical software are expected to fall around late 2023, while compliance for all other software is anticipated to be in early 2024.

Attesting Security Practices of Third-Party Code, Including Open Source

M-23-16 reinforces the requirement for software producers to provide attestations regarding the security practices employed in the development of their products. This includes adherence to the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) guidelines, specifically when it comes to third-party open source dependencies incorporated into their software and services. The memorandum states:

"Attestations must be collected from the producer of the software end product used by an agency because the producer of that end product is best positioned to ensure its security. An attestation provided by that producer to an agency serves as an affirmative statement that the producer follows the secure software development minimum requirements, as articulated in the common form. These minimum requirements include several best practices regarding how software producers should address and maintain the security of code. These naturally extend to and guide the utilization of third-party software components, both open-source and proprietary, and reflect best practices for minimizing risk from such components, as articulated in NIST's SSDF."

There are some exceptions, such as when agencies procure open source packages for themselves, but in general software producers will be obligated to provide attestations for all third-party open source dependencies integrated into their products, even if those dependencies constitute a significant portion of the overall codebase. While this aligns with traditional compliance practices for open source, companies have sometimes been lax about compliance because there was more limited enforcement from the broader community. In contrast, now each supplier will be responsible and accountable per their contracts.

The time for action

Many companies are not ready to fully declare their open source dependencies. The memo does provide for a transitional mechanism (a "Plan of Action and Milestones") for suppliers that won't be able to immediately be compliant, but the clock is ticking. As stated in the memo:

“This memorandum makes an adjustment to M-22-18’s alternative to attestation. First, the producer of a given software application must identify the practices to which they cannot attest, document practices they have in place to mitigate associated risks, and submit a POA&M to an agency. If the agency finds the documentation satisfactory, it may continue using the software, but must concurrently seek an extension of the deadline for attestation from OMB. Extension requests submitted to OMB must include a copy of the software producer’s POA&M.”

If your business is a supplier to the U.S. government, directly or indirectly, the time to develop compliance capabilities is now.