How The Office of Management and Budget (OMB) memorandum M-23-16 impacts open source 

Understanding OMB memorandum M-23-16, updated guidance regarding M-22-18 requirements

In June 2023, the U.S. OMB announced memorandum M-23-16, an update to memorandum M-22-18 Enhancing the Security of the Software Supply Chain through Secure Software Development Practices, released in September 2022. M-23-16 extends the deadlines presented in M-22-18 by a minimum of 3 months for critical software and 6 months for all other software.

M-23-16 reiterates that software producers are responsible for attesting that the secure development practices used to build their products follow the NIST Secure Software Development Framework (SSDF) guidelines, specifically including third-party open source dependencies that are part of their products and services. The memorandum also clarifies what the penalties are for non-compliance and offers a plan of actions and milestones (POA&M) organizations can submit in the meantime as proof of a planned pathway towards meeting compliance. 

Revised M-22-18 deadlines 

The original date for organizations to provide attestations around their secure development practices for critical software was June 11, 2023 (and September 2023 for all other software). However, timelines were adjusted to provide for an ample amount of time for public feedback on the proposed draft of CISA's self-attestation form, with the request for comments closing on June 26, 2023. The new dates proposed by M-23-16 center on the OMB's approval of the self-attestation form. Three months after OMB approval, agencies must collect attestations for critical software subject to the requirements of M-22-18 and M-23-16. Six months after OMB approval, agencies must collect attestations for all software subject to the requirements delineated in M-22-18. What's expected is that the dates to meet these requirements will be late 2023 for critical software, and early 2024 for all other software.

Penalties and how to extend the compliance deadline with a POA&M

In previous U.S. government cybersecurity initiatives, penalties for non-compliance have been only implied, if not unclear. Memorandum M-23-16 clarifies the penalties:

“The [federal] agency must discontinue use of the software if the agency finds the software producer's documentation unsatisfactory or if the agency is unable to confirm that the producer has identified the practices to which it cannot attest; documented practices they have in place to mitigate associated risk; and submitted a Plan of Actions and Milestones to the agency."

In short, if an organization provides software to the U.S. government and cannot provide satisfactory documentation to show their software complies with the mandatory requirements outlined in the NIST SSDF, the federal agency must discontinue use of the software. The impact of these penalties will likely be felt all across the software supply chain—keep in mind that the U.S. government is the largest buyer of goods and services in the world, and that’s as true for IT as it is for other domains. 

Plan of action and milestones (POA&M)

One saving grace is that, because obtaining attestations is a large ask for some, M-23-16 introduces the concept of a plan of action and milestones (POA&M). Organizations can apply for an extension by showing a completed POA&M. From the memorandum: 

“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.”

The POA&M doesn’t relieve software producers from the self-attestation requirements, but it does allow them to submit a plan for how they are working towards compliance to be submitted for review and approval by a federal agency.

How can organizations build their attestation strategy?

One way to prepare is to begin to assess the compliance strategy your organization has in place for application development. Create a software bill of materials (SBOM) to understand the software in use at your organization. Outline how you and your team can start to document how your organization continuously audits and manages the health and security practices of the open source libraries used in your applications. It's also recommended to review the secure software development guidelines outlined by NIST in the NIST SSDF as well as making sure to stay up to date on the latest U.S. government cybersecurity initiatives. 

It's important to reiterate that the NIST SSDF states that organizations will need to verify that open-source software components comply with the requirements throughout their life cycles, meaning organizations will need to attest to the software development practices followed by the third-party components in their software applications. 

Tidelift partners with maintainers to ensure their components meet government and industry standards (like many of those included in the new NIST guidelines), now and into the future, and pays them to do this important work. To learn how Tidelift can help your organization attest to the open source components used to build your applications, download a sample of the Tidelift open source attestation report.