On June 9, 2023, the U.S. government Office of Management and Budget released memorandum M-23-16 as an update to the guidance for enhancing the security of the software supply chain originally published in OMB memorandum M-22-18 last September.
In this advisory, we’ll share the highlights of the updated guidance and how it impacts organizations building applications with open source.
The original date for organizations to provide attestations around their secure development practices for critical software was June 11, 2023, and the proposed draft of the long-awaited self-attestation form is still in its 60 day window for public feedback until late June. Because of this, many people were wondering how organizations could be expected to provide attestations given that the attestation form was not even final yet.
M-23-16 extends the dates for compliance by a minimum of 3 months for critical software and 6 months for all other software. We say “a minimum” because the new clocks start ticking 3 months and 6 months after the approval of the attestation form, which presumably can’t be until after the comment period ends in late June. The table below shows 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 |
Assuming the CISA form is approved without delay, mandatory attestation compliance dates will likely fall somewhere around late 2023 for critical software, and early 2024 for all other software.
One of the key questions being asked within many organizations regarding these attestation deadlines is what the penalties are for organizations that either choose to or are not able to provide attestations for their agency customers.
Around this, M-23-16 is also very clear (emphasis ours):
“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."
So organizations should take these attestation requirements very seriously or risk losing the U.S. government, the largest buyer of goods and services in the world, as a customer.
Most importantly, M-23-16 reiterates that software producers are responsible for attesting that the secure development practices used to build their products follow the NIST SSDF guidelines, specifically including third-party open source dependencies that are part of their products and service. From the memo, again emphasis ours:
“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.
When software producers responsibly implement industry-leading development practices, which include minimizing risk from third-party code, the burden of accounting for secure software development practices is appropriately placed on the producer of the end product rather than Federal agencies.”
In other words, software producers must provide attestations for all third-party open source dependencies that go into their products and solutions (which often make up 70% or more of the code in a software product). Software producers can’t push the burden of vetting open source dependencies back onto federal agencies just because those dependencies are open source.
The memo does clarify that federal agencies don’t have to source their own attestations for open source software freely and directly obtained by agencies, where there is not a paid software producer in the middle:
“Open-source software freely and directly obtained by Federal agencies is outside the scope of NIST’s guidance for agencies on software supply chain security… Agencies are, nevertheless, required to assess the risk in utilizing such software and take appropriate steps to minimize or eliminate identified risks.”
The example is given of an open source web browser that would not require attestations if acquired free of charge and directly by a federal agency, versus an open source dependency in a commercial application—which would require attestations.
Consistent with the U.S. national cybersecurity strategy, this avoids placing an untenable “unfunded mandate” on non-compensated open source maintainers, which is appropriate.
And thirdly, federal agency CIOs are given the discretion to determine whether federal contractor-developed software is “[a]gency-developed software,” and thus excluded from the attestation requirements.
The bottom line: all software that is either hosted (such as software-as-a-service) with continuous updates, or that has any major version changes after September 14, 2022 will be expected to comply with the attestation requirements.
Many organizations that produce software used by U.S. government agencies have approached the topic of mandatory secure software development self-attestations with apprehension. How are they expected to go from zero to 100% attestation coverage on such a short timeline, for sprawling software code bases that already exist in the real world?
The memo fleshes out a mechanism of “Plans of Action and Milestones” (POA&M), which was only briefly mentioned in the prior M-22-18 guidance, as a temporary bridge to allow software suppliers to come into compliance with the attestation requirements:
“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 mechanism doesn’t relieve software producers from the self-attestation requirements, but it does allow them to submit a plan for how they are going to come into compliance over time, for review and approval by a federal agency.
This is good news, because without reducing the urgency for software suppliers, it provides a believable and viable path to compliance.
These deadline extensions are a welcome relief for organizations selling software to the government that were unsure or unable to complete the attestation requirements in time. However, this new memorandum makes it abundantly clear that the government continues to take these attestation requirements seriously.
That means that your organization needs to begin taking them seriously too—if you are not already—and should be building out your compliance strategy now, paying particular attention to the additional complexities around providing attestations for open source code that your organization uses, but did not create.
The hard reality is that doing the work to ensure these secure development practices outlined in the NIST SSDF are in place on open source projects takes time. And with Tidelift’s recent survey of open source maintainers demonstrating that the majority of maintainers are unpaid and that time and money rank highest among reasons that maintainers aren’t willing to align to government and industry standards, it is unrealistic to expect that maintainers are going to be offering up the necessary information required to attest to their development practices without being compensated for the work.
Yet, organizations using open source in the applications they sell to the government will have a responsibility to ensure all of the components in their applications are using secure development practices, so how do we ensure the work gets done?
Tidelift continuously collects and measures open source development practices aligned with the NIST SSDF, and pays maintainers to validate their packages conform to these secure development practices. We deliver this data to our customers through reporting, APIs, and other capabilities as part of the Tidelift Subscription.
If you are looking for quantitative data about the impact paying open source maintainers can make on your organization’s ability to meet government attestation requirements, this talk from Tidelift VP of product Lauren Hanford is a great place to start.
And if you’d like to learn more about how Tidelift can help your organization comply with secure software development attestation requirements: