Yesterday, the U.S. government’s Office of Management and Budget (part of the Executive Office of the President) released memorandum M-22-18 on Enhancing the Security of the Software Supply Chain through Secure Software Development Practices including detailed requirements that organizations will need to comply with in order to continue to sell software to the government.
This memo follows directly from last year’s White House Executive Order 14028 on Improving the Nation’s Cybersecurity. From the new OMB memo (emphasis ours):
“Executive Order (EO) 14028, Improving the Nation’s Cybersecurity (May 12, 2021), focuses on the security and integrity of the software supply chain and emphasizes the importance of secure software development environments. The EO directs the National Institute of Standards and Technology (NIST) to issue guidance ‘identifying practices that enhance the security of the software supply chain.’ […] This memorandum requires agencies to comply with the NIST Guidance and any subsequent updates.”
In this post, I’ll share the key pieces of this memo that impact organizations building applications with open source software.
1. U.S. government agencies will only be able to use software that meets NIST guidance for secure software development practices
Earlier this year, as directed by Executive Order 14028, the National Institute of Standards and Technology (NIST) published specific guidance on secure software development standards (including for third-party software), in two parts:
- The NIST Secure Software Development Framework (SSDF), SP 800- 218 (Feb 2022)
- NIST Software Supply Chain Security Guidance (Feb 2022)
Now via this new memorandum, the Office of Management and Budget is directing all federal executive agencies to comply with those NIST guidelines:
“Federal agencies must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance.”
The memo clarifies that this requirement applies quite broadly including "third-party software" and specifically including "applications and application services (e.g. cloud-based software) as well as products containing software.”
What do the referenced NIST standards have to say about open source software, specifically? The NIST Secure Software Development Framework discusses:
- Establishing one or more software repositories to host sanctioned and vetted open-source components
- Defining policies for securing software development processes, including for open-source and other third-party software components
- Verifying that open-source software components comply with the requirements throughout their life cycles
- Future work to likely include collaboration with the open source community
These requirements are particularly important to understand for organizations using open source in their applications, because those organizations will be asked to attest to comply with secure development practices for software that they did not even write themselves if they would like to continue to sell it to the government.
This will not be an insignificant hurdle to overcome and will require new approaches as we have previously discussed in Tidelift’s take on the U.S. Cyber Safety Review Board Report on Log4Shell vulnerability.
2. U.S. agencies will be required to obtain a self attestation from all software providers
In order to sell software to the government, organizations will need to provide specific documentation “self attesting” that their software meets these NIST standards and follows secure development practices.
Further, the NIST self attestation requirements are the minimum requirement, and agencies may also make the determination that additional third-party attestation is required for certain critical software.
Seemingly in recognition that third-party open source software is a particularly challenging area, the OMB memo calls out a specific role for third party assessment relating to open source:
“A third-party assessment [...] shall be acceptable in lieu of a software producer’s self-attestation, including in the case of open source software or products incorporating open source software.”
While it's great to see this recognition of the challenges of validating secure software development practices for community-created open source software projects, the hard reality is that any compelling third-party assessment must necessarily involve the actual upstream open source maintainers, not just an arms-length reviewer, as we have previously discussed in Log4Shell highlights the need to proactively cooperate with open source maintainers at scale.
3. Many U.S. agencies will require software producers to provide a software bill of materials (SBOM) and documented processes to validate code integrity
The OMB memo specifies that agencies may require a software bill of materials (SBOM) from third party providers, “based on the criticality of the software” as determined by the earlier OMB memorandum M-21-30, which in turn defined critical software as:
“any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:
- is designed to run with elevated privilege or manage privileges
- has direct or privileged access to networking or computing resources
- is designed to control access to data or operational technology
- performs a function critical to trust
- operates outside of normal trust boundaries with privileged access”
By that definition, this SBOM requirement will apply very broadly indeed.
The new OMB memo specifically stipulates that software producers may demonstrate their conformance with these NIST guidelines in part by producing a software bill of materials (SBOM) that complies with the NTIA SBOM requirements released in July 2021.
Agencies may also require further validation of the integrity of the source code, including the use of tools and processes that check for known and potential vulnerabilities, or evidence that the software producer participates in a vulnerability disclosure program.
Satisfying the SBOM requirement will be particularly challenging for applications that rely on community-led open source software projects, which in 2022 is almost every application. How can organizations provide the necessary incentives to partner with individual contributors in open source communities? We’ve previously explored this topic in Software bills of materials are important—but they won't work at scale if we don't pay the maintainers.
Emerging solutions like the Tidelift Subscription, which provides a direct incentive alignment with upstream open source maintainers, will be necessary to achieve the goal of these requirements.
4. The U.S. will create a government-wide repository for sharing software attestations and artifacts
Finally, one of the most interesting directives to come out of this memo is that the Office of Management and Budget will be leading the creation of a government-wide repository to collect this information:
“Within 180 days from the date of this memorandum, OMB, in consultation with CISA and the General Services Administration (GSA), will establish requirements for a centralized repository for software attestations and artifacts, with appropriate mechanisms for protection and sharing among Federal agencies.”
This is a particularly important development when it comes to open source, because it means that the government will likely be creating a catalog of open source components that meet the NIST guidance.
Here, the OMB memo is following emerging industry practices. Tidelift’s research has found that the best practice of centrally managing a repository of approved open source components is growing rapidly. IDC also reports that 67% of organizations are using internally curated repositories today (moderate, extensive, or strategic use), growing to 82% in 12 months. And emerging solutions like the Tidelift Subscription provide commercial off-the-shelf solutions for building catalogs of curated open source.
Bottom line: meeting the U.S. government’s latest software requirements means working with open source maintainers
As an organization building applications using open source components, the bottom line here is clear. Any organization wanting to sell software to the government will need to ensure the open source components they are using in that software meet these expanded government requirements.
The challenge is, who is going to do the work to ensure the open source projects meet those standards?
That’s where Tidelift can really help. Tidelift partners with maintainers to ensure their components meet the standards that enterprises expect (many of which are documented in the NIST guidance), now and into the future, and pays them to do this important work.
If you want to continue to sell your organization’s software to the government, you need to attest that the open source components in your applications meet those standards, and that means having a business relationship with maintainers behind those components.
Want to learn more about how Tidelift’s partnerships with open source maintainers can help you ensure your software is complying with the new government requirements outlined in this OMB memo?
50 Milk St, 16th Floor, Boston, MA 02109