<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.

Timeline for mandated federal agency cybersecurity actions

Over the next year, US government agencies are required to comply with more stringent cybersecurity requirements that will also require organizations providing software or services to the federal government to self attest that their software also meets these requirements.

What you need to know

Here are some key dates that organizations should be aware of (some of which have already passed). Note that organizations will be required to self-attest that their software meets NIST standards by late 2023 (for critical software) and early 2024 (for all other software). These are the dates that agencies are accountable for. There are additional action items applicable to the Office of Management and Budget (OMB) and the Cybersecurity and Infrastructure Security Agency (CISA).

December 13, 2022

By this date, federal agencies will have inventoried all software subject to OMB memorandum M-22-18 (more on this below), and flagged software deemed as critical.

January 12, 2023

By this date, federal agencies will develop a process to communicate requirements to vendors and ensure that vendor attestation letters can be collected in a central agency system.

March 13, 2023

By this date, federal agencies will have assessed training needs and developed plans for the review and validation of attestation documents.

April 27, 2023

CISA proposes a self attestation form and provides a 60 day window for public feedback on the draft.

June 26, 2023

Deadline for public feedback on the proposed CISA attestation form.

3 months from OMB approval of attestation form

By this time, agencies must collect attestations for critical software subject to the requirements of M-22-18 and M-23-16.

6 months from OMB approval of attestation form

By this time, agencies must collect attestations for all software subject to the requirements delineated in M-22-18.

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. 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.

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. M-23-16 extends the dates for compliance by a minimum of 3 months for critical software and 6 months for all other software.

What you need to know

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 2023. The M-22-18 dates change are adjusted as such:

  • Previously set to be June 11th, 2023, agencies shall collect attestation letters for “critical software” subject to the requirements of M-22-18, as amended by this memorandum three months after OMB approval of the self-attestation form.
  • Previously set to be September 14th, 2023, agencies shall collect attestation letters for all software subject to the requirements of M-22-18, as amended by this memorandum six months after OMB approval of the self-attestation form.
  • 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.

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. 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

Proposed CISA self-attestation form

CISA released a proposed draft of the long-awaited 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. This is not the final document— CISA is providing a 60 day window (as of April 27, 2023) for public feedback on the draft. 

What you need to know

  • The proposed self-attestation form makes it clear that organizations will be required to make formal attestations not only about the software they write, but also included third-party open source software components.
  • After the proposed form is approved, organizations will need to begin submitting their attestations per the adjusted deadlines in M-23-16.

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 as soon as late 2023. 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 late 2023 for critical software and early 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 all of the secure software development standards outlined in 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 all of these guidelines by as soon as June 2023. Key guidelines that impact organizations developing software with open source include:

  • Agencies will be expected to verify that open source software components comply with NIST guidelines throughout their life cycles.
  • Software producers selling to these agencies will need to self-attest that they comply with secure development practices for software they deliver to the government, which means that they may also need to attest to the secure development practices of the open source projects they may bring into that software.
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 attest to the security practices of open source software we use but do not produce ourselves?”

What you need to know

To comply with self-attestation 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 attestation requirements

Organizations will be required to make formal attestations not only about 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 these 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 self-attestation 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