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

Government open source cybersecurity resource center

Understand the impact new government cybersecurity requirements in the US and around the world will have on your organization and learn how to stay in compliance

NEW GUIDE

The U.S. government is taking action to set higher cybersecurity standards. How will they impact your organization?

Government cybersecurity regulation resource center.

Executive summary: Most important government actions to understand

Executives building applications with open source software should familiarize themselves with the following critical government actions. Each of these is explained in more detail below.

White House National Cybersecurity Strategy Implementation Plan

As a follow-up to the National Cybersecurity Strategy from March 2023, the White House released the National Cybersecurity Strategy Implementation Plan in July 2023. This plan exists as a living document set to be updated annually and provides a roadmap for the ideas mapped out in the strategy delivered publicly in March 2023.

What you need to know

Organizations building applications with open source should look for impacts in the following areas:

  • The plan instructs the Office of the National Cyber Director (ONCD) to establish a new initiative it has dubbed OS3I (Open Source Software Security Initiative) and CISA to improve the baseline security level of open source software. The initial deadline set in the plan is Q1 2024.
  • The plan tasks the Department of Justice (DOJ) with building out an enforcement effort to investigate false claims around cybersecurity, and specifically calls out recovering damages from irresponsible vendors.
  • Lastly, the plan tasks CISA with the responsibility to work across government to reduce gaps in SBOM implementation and increase coordination, a follow-up to the requirement for software vendors to provide up to date software bills of materials (SBOMs).

Learn more

OMB M-23-16 updated guidance regarding M-22-18 requirements

The U.S. government Office of Management and Budget (OMB) 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 in September 2022. 

What you need to know

The dates for organizations to provide attestations around their secure development practices for critical software are adjusted as such:

  • Agencies shall collect attestation letters for “critical software” subject to the requirements of M-22-18, three months after OMB approval of the self-attestation form, or June 2024. 
  • Agencies shall collect attestation letters for all software subject to the requirements of M-22-18, six months after OMB approval of the self-attestation form or September 2024.

M-23-16 reiterates that software producers are responsible for attesting that the secure development practices used to build their products are aligned with the NIST SSDF guidelines. It also clarifies the penalty for non-compliance: agencies must discontinue use of software that does not meet the attestation requirements or have an approved plan of action and milestones (POA&M) for achieving compliance.

Learn more

CISA self-attestation form

On March 11, 2024, CISA released the final self-attestation form organizations selling software to the government will need to use to attest to the secure development practices they follow, as specified in OMB memorandum M-22-18.

What you need to know

  • The form requires software producers to make a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities.
  • It also requires software producers to maintain provenance for internal code and third-party components incorporated into the software to the greatest extent feasible.
  • Organizations will need to begin submitting their attestations per the adjusted deadlines in M-23-16: June 2024 for “critical software”, and September 2024 for all other software subject to the requirements.

Learn more

White House National Cybersecurity Strategy

The National Cybersecurity Strategy is the next step in a series of recent actions to improve cybersecurity for federal government agencies, the nation’s businesses, and citizens as a whole. This strategy will have an extensive impact on future policies and laws emerging from the government regarding cybersecurity.

What you need to know

Organizations building applications with open source should look for impacts in the following areas:

  • An increase in government regulation and mandatory requirements: The government is proposing a more overt, active approach to improving cybersecurity by increasing regulation and mandatory requirements.
  • Cybersecurity liability shifts from consumers to commercial producers of software: Software producers will be increasingly held liable for security issues in their products instead of end users or open source developers whose components are integrated into the software.
  • A safe harbor for organizations employing best practices: Those organizations that can systematically demonstrate that they are following best practices for secure development will find protection from liability.
  • Proactive U.S. federal government involvement in open source communities: The government will continue to invest in open source software and efforts that enhance its security.
Learn more

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

The Office of Management and Budget (OMB) guidance in M-22-18 is a direct follow-up to White House Executive Order 14028. It formalizes the NIST guidance provided in the NIST Secure Software Development Framework and NIST Software Supply Chain Security Guidance documents as the government requirements for developing secure software, and mandates 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.

What you need to know

Any organization that sells software to the government will be required to self-attest that their software complies with the NIST guidelines starting in 2024. In addition:

  • Going forward, federal agencies must only use software provided by software producers who can attest to complying with the NIST guidance.
  • Agencies will be required to obtain a self attestation from all software providers by June 2024 for critical software and September 2024 for all other software.
  • Self-attestation is the minimum level required, but some agencies may make risk-based determinations that a third-party assessment is required due to the criticality of the software.
  • Some U.S. agencies will require software producers to provide a software bill of materials (SBOM) and documented processes to validate code integrity.
Learn more

What is an attestation?

Attestation is the “issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.”

In this case, organizations selling software to the government will be required to self-attest that they conform with specific secure software development standards drawn from the NIST guidelines.

Source: Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e

NIST guidance on securing the software supply chain

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 its NIST Secure Software Development Framework and NIST Software Supply Chain Security Guidance documents.

What you need to know

According to OMB memorandum M-22-18, organizations will need to self-attest that they comply with these guidelines by as soon as June 2024. Key guidelines that impact organizations developing software with open source include:

  • Software suppliers to U.S. government agencies will be required to make a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities.
  • Software suppliers to U.S. government agencies will need to maintain provenance for internal code and third-party components incorporated into the software to the greatest extent feasible.
Learn more

White House Executive Order 14028 on Improving the Nation’s Cybersecurity

The White House issued Executive Order 14028 on Improving the Nation’s Cybersecurity in May 2021 in response to increasing digital threats like the one that impacted SolarWinds and its customers.

This order set in motion many of the other US government efforts to improve cybersecurity that are highlighted in detail on this page. It had many elements that specifically impacted organizations developing applications with open source, and set timelines for more detailed guidelines that are now beginning to emerge from NIST and the OMB.

What you need to know

Executive Order 14028 has numerous provisions that organizations using open source to develop applications should understand. At a high level, it states that organizations will need to begin to attest to the health, security, and provenance of the open source components that go into their applications. Among other stipulations, it recommends that organizations:

  • Maintain accurate and up-to-date data of their software code, components, and controls on internal and third-party software components, tools, and services present in software development processes, and perform audits and enforcement of these controls on a recurring basis.
  • Provide purchasers with a software bill of materials (SBOM) for each product directly or publish it on a public website.
  • Ensure and attest, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.
Learn more

The critical role of open source maintainers in complying with government cybersecurity guidelines

Organizations selling software or solutions to the government that include open source software components need to pay particular attention to federal self-attestation requirements outlined above as they continue to emerge. The critical question these organizations should be asking themselves is “how do I demonstrate the required ‘good-faith effort’ to maintain trusted source code supply chains for the third-party open source software components we use but do not produce ourselves?”

What you need to know

To comply with the requirements, organizations must better understand the security practices of the open source software they are building into their applications. Yet, the so-called open source software supply chain is not a traditional supply chain in that open source maintainers typically do not have a business relationship with their users and license their software “as-is” with no warranty.

Organizations will need to have visibility into their open source software supply chain to understand more about the components they are using and the security practices these projects follow.

How organizations using open source can comply with U.S. government requirements

Organizations will be required to make a good-faith effort to maintain trusted source code supply chains to address the security of not only the software they write, but also included third-party open source software components—which typically comprise over 70% of the code in a modern application. The hard reality is that doing the work to ensure apprpriate secure development practices are in place and correctly documented on open source projects takes time, and can get challenging to scale, especially considering most organizations typically rely on thousands of open source packages. 

Tidelift has been working to address these very challenges. To show how we help organizations meet the U.S. government requirements for the open source components being used in their applications, we’ve created a sample open source attestation report using the most comprehensive database of maintainer-validated security and maintenance attestations. Tidelift is uniquely positioned to deliver this report through its partnerships with open source maintainers, who are paid to ensure their projects follow important security and maintenance practices like those found in the NIST SSDF and keep those attestations up-to-date.  

Learn more about this open source attestation report or contact us to request a custom open source attestation report for the components being used in your organization.

 

Watch a demo on how Tidelift helps organizations meet government compliance requirements

Related reading

Webinar: how the NIST Secure Software Development Framework impacts open source software

Tidelift VP of product, Lauren Hanford, and Senior Product Marketing Lead, Kanish Sharma hosted a webinar to discuss the NIST Secure Software...

Tidelift advisory: Impact of new U.S. National Cybersecurity Strategy on organizations building apps with open source software

(March 2023) The U.S. government issued the long anticipated 2023 National Cybersecurity Strategy. This is the next step in a series of recent...

Introducing TACOS: Trusted Attestation and Compliance for Open Source

TACOS, in addition to being delicious, are now getting a new meaning as a framework for evaluating and attesting to the secure software development...

How the NIST Secure Software Development Framework impacts open source software, p.1

We performed a deeper analysis of the NIST framework that organizations will need to attest that they comply with, specifically to learn what these...

How the NIST Secure Software Development Framework impacts open source software, p.2

Learn more about the four categories of work highlighted by the NIST SSDF and how Tidelift helps organizations comply with this framework for the...

Securing the Software Supply Chain: Recommended Practices for Developers

(August 2022). The National Security Agency (NSA) partnered with the Cybersecurity and Infrastructure Security Agency (CISA) and the Office of the...

FTC warning to remediate Log4Shell vulnerability

(January 2022). In response to the fallout from the Log4Shell vulnerability, the United States Federal Trade Commission issued an alert warning...

US Cyber Safety Review Board report on the Log4Shell vulnerability

(July 2022). The U.S. Department of Homeland Security released the first report from the recently created Cyber Safety Review Board (CSRB), reviewing...

Log4Shell vulnerability

(December 2021). The Apache log4j vulnerability, often referred to as Log4Shell, was first reported in December 2021. This software supply chain...

SolarWinds vulnerability

(December 2020). In late 2020, a sophisticated cyber intrusion was uncovered that made use of a commercial (not open source) application made by the...

Open source and the unintended consequences of the EU’s Cyber Resiliency Act

On September 15, 2022 the EU unveiled a draft of the Cyber Resiliency Act (CRA), an eighty-seven page document detailing proposed new rules meant to...

How the NIST Secure Software Development Framework (SSDF) impacts open source software

In this recorded webinar, you will learn:

  • A breakdown of the four areas of work as categorized by the NIST framework 
  • What the NIST SSDF means for open source software maintainers (hint: more unpaid work)
  • Next steps to prepare for the impending NIST SSDF requirements and how Tidelift can help

WATCH NOW

How the NIST SSDF impacts open source software