<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=705633339897683&amp;ev=PageView&amp;noscript=1">

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

As directed by M-22-18, any organization that sells software to the government will be required to self-attest that their software complies with the NIST guidelines as soon as late 2023. 

Learn what application development teams using open source need to know about U.S. government cybersecurity guidelines and how to stay in compliance.

Fill out the form to access the Tidelift guide to U.S. government cybersecurity requirements

Understanding OMB memorandum M-22-18 Enhancing the Security of the Software Supply Chain through Secure Software Development Practices

In September 2022, The Office of Management and Budget (OMB) announced memorandum M-22-18, a direct follow-up to White House Executive Order 14028. The memorandum formalizes the NIST guidance provided in the NIST Secure Software Development Framework (SSDF) and NIST Software Supply Chain Security Guidance documents as the government requirements for developing secure software, and mandates that federal government agencies comply with these guidelines. It also sets aggressive deadlines for compliance, both for the agencies themselves and for organizations that provide software to these agencies—organizations will need to self-attest that they comply with all of these guidelines by as soon as the end of 2023.

Since the announcement in September 2022, the OMB has published memorandum M-23-16, an update to the guidance originally published in M-22-18 that revises deadlines and provides more information regarding the penalties for non-compliance. You can read more about these updates on our blog.

What is the software supply chain and why does software supply chain security matter? 

The software supply chain is comprised of anything—tools, components, processes, from open source software to commercial software—that goes into the code in an organization's software development lifecycle (SDLC). Because of the wide breadth of the software supply chain and the components that go into any one application, there are many chances for using deprecated, insecure software.

Software supply chain security is about knowing where the components in your software supply chain come from and whether or not they're fit for use in your software application. Adhering to software supply chain security principles involves thinking proactively. Creating software bills of materials (SBOMs), knowing about the dependencies in the open source software you're using (transparency is key), and applying fixes and updates are just some of the strategies to addressing software supply chain security.

OMB M-22-18 and open source software supply chain security

What is the open source software supply chain?

Just like the broader software supply chain, the open source software supply chain casts a wide net—every line of code contributed to an open source project is a part of the open source software supply chain environment. As we've seen with incidents such as Log4Shell, the impact of a vulnerability goes beyond those directly using the Java-based log4j logging-utility, but extends to any third-party package using Log4j that is in use in an organization's applications. (To put it into numbers, according to data tracked by Tidelift, Log4j-core has over 3,600 dependent packages in the Java language ecosystem and over 20,900 dependent software repositories on public code collaboration platforms.)

What organizations building with open source SHOULD know

Protecting the software supply chain requires that organizations start to consider the role open source software plays in their applications. What open source is in use? Are dependencies being accounted for? Are the packages in use up-to-date, secure, and maintained?

Memorandum M-22-18 requires agencies to comply with NIST guidance and any subsequent updates (see next section for what compliance entails). Within the NIST SSDF itself, it discusses 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.

What does compliance look like?

Organizations selling to the government will need to self-attest that they comply with NIST SSDF guidelines as soon as late 2023 for critical software, and early 2024 for all other software (as set by the  U.S. government Office of Management and Budget's (OMB) memorandum M-22-18 and its follow-up, memorandum M-23-16). 

To learn how Tidelift can help your organization comply with government requirements pertaining to the open source components used to build your applications, download a sample of the Tidelift open source attestation report.

Stay up-to-date on U.S. government cybersecurity guidelines

More resources to help your organization prepare

Screenshot 2023-04-18 at 3.50.21 PM


The Tidelift open source attestation report

In December of 2021, Tidelift fielded our annual survey of technologists—including software developers, engineering executives and managers, architects, and devops pros—who build applications with open source.

Software transparency: SBOM in a world built on open source

Join Allan Friedman, Senior Advisor and Strategist at the Cybersecurity and Infrastructure Security Agency (CISA), at his 2023 Upstream keynote on the state of SBOMs today and how do they apply to open source.  

Upstream speaker Allan Friedman ON-DEMAND (1)


Social post - 5-1


How the NIST Secure Software Development Framework impacts open source software

Lauren Hanford, Tidelift VP of product, and Kanish Sharma discuss the NIST SSDF and share ways organizations can actually follow its guidance, specifically highlighting considerations for the open source software on which all modern software is built.