OMB memo reaffirms secure software development practices, extends timelines for attestation collection

The U.S. Office of Management and Budget (OMB) published Friday an update to a September 2022 memorandum (M-22-18) that focuses on enhancing the security of the software supply chain through secure software development practices. The latest document extends the timeline for the collection of attestations for critical software and non-critical software; clarifies the scope of the earlier memorandum; provides guidance on the use of plans of action and milestones submitted to federal agencies by software producers; and provides future updates to guidance.  

The OMB outlined that it “reinforces the requirements established in M-22-18, reaffirms the importance of secure software development practices, and extends the timelines for agencies to collect attestations from software producers. Additionally, this memorandum provides supplemental guidance on the scope of M-22-18’s requirements and on agencies’ use of Plan of Actions and Milestones (POA&Ms) when a software producer cannot provide the required attestation, but plans to do so. To the extent any provision of this memorandum may be read to conflict with any provision of M-22-18, this memorandum is controlling.” 

Pursuant to M-22-18, agencies must only use software that is provided by software producers who can attest to complying with government-specified minimum secure software development practices. 

Addressed to the heads of executive departments and agencies, the new memorandum, M-23-16, outlines that it is consistent with U.S. President Joe Biden’s Executive Order 14028 released in May 2021. It outlined that “M-22-18 requires each Federal agency to collect attestations from producers of software used by the agency if that software was developed after September 14, 2022, the effective date of M-22-18. Agencies are also required to collect attestations from producers of software developed prior to September 14, 2022, if that software is used by a Federal agency and either: (1) is modified by one or more major version changes after September 14, 2022, or (2) is a hosted service that deploys continuous updates.” 

In line with EO 14028, the National Institute of Standards and Technology (NIST) has released the NIST Secure Software Development Framework (SSDF), SP 800-218, and the NIST Software Supply Chain Security Guidance.

The memorandum defined that for the purposes of M-22-18 and this memorandum, ‘software’ includes firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software. It clarified that the memorandum modifies the deadlines by which agencies must collect attestation letters. 

The memorandum also outlined that agencies must collect attestations for critical software subject to the requirements of M-22-18 and this memorandum no later than three months after the M-22-18 attestation common form released by the Cybersecurity and Infrastructure Security Agency (CISA) that is approved by OMB under the Paperwork Reduction Act (PRA). “Six months after the common form’s PRA approval by OMB, agencies must collect attestations for all software subject to the requirements delineated in M-22-18, as amended by this memorandum,” it added.  

Addressing third-party components, the memorandum said that 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,” it added. 

The memorandum said that the minimum requirements delineated in the common form address the risk of integrating components from third parties. “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.” 

Accordingly, “agencies are not required to collect attestations from producers of third-party software components that are incorporated into the software end product used by the agency. This is true for both third-party open-source and proprietary components. A component, whether open-source or proprietary, only qualifies as a ‘third-party’ component if it was developed by an entity other than the producer of the software end product into which it is incorporated,” it added.

The document also said that agencies are not required to collect attestations from software producers for products that are proprietary but freely obtained and publicly available. “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. This memorandum further clarifies that no-cost, publicly available proprietary software is also out of scope for M-22-18 attestation collection.” 

It added that a significant number of core software applications, such as web browsers, to which federal agencies must have access are offered for use to members of the public at no cost. “Users of this software have no opportunity to negotiate with the producer, and therefore it will not be feasible for agencies to obtain attestations from the producers of such software. Agencies are, nevertheless, required to assess the risk in utilizing such software and take appropriate steps to minimize or eliminate identified risks. Though freely obtained, demonstrations or pilots of software products that are otherwise unavailable on a no-cost basis remain subject to M-22-18 attestation requirements, as amended,” the memorandum added.

The memorandum also specified that agency-developed software remains out of scope for M-22-18 and any attestation collection requirements. “If there are questions regarding whether software developed by Federal contractors should be considered agency-developed, agency CIOs are required to make that determination on behalf of the agency. Agency CIOs are in the best position to determine in a given case whether the agency’s specification and supervision of contract performance meet the standard articulated. If an agency must, under M-22-18 and this memorandum, obtain an attestation before using a given software application, then that application will remain subject to the attestation requirement even if it is deployed, configured, or modified by a Federal contractor on behalf of an agency,” it added.

The latest memorandum also 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.” 

It added that an agency must discontinue the 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 POA&M to the agency. Additionally, if the agency fails to submit an extension request, the POA&M is not considered valid, and the agency must discontinue the use of the software. 

“In instances where multiple agencies are affected by a software producer’s inability to attest to minimum requirements for one or more software products, OMB will prioritize consideration of agencies’ extension requests for software product(s) that share a common POA&M,” the memorandum said. “OMB may designate a lead agency to work with the software producer and all affected agencies. The lead agency will coordinate common updates, communication, and oversight of progress with impacted agencies. Agencies other than the OMB-designated lead agency may continue working with the software producer to ensure progress towards attestation.”

Lastly, the memorandum said that “additional clarifications and general updates on implementation of M-22-18 and this memorandum will be posted on the appropriate MAX.gov or successor site.”

Last month, the CISA announced that it will facilitate the 2023 CISA SBOM-a-Rama public event to build on existing community-led work around the Software Bill of Materials (SBOM) on specific topics. The security agency has facilitated the 2023 CISA SBOM-a-Rama event to support a community effort to advance SBOM technologies, processes, and practices.

Anna Ribeiro

Industrial Cyber News Editor. Anna Ribeiro is a freelance journalist with over 14 years of experience in the areas of security, data storage, virtualization and IoT.