Over the past few months, we’ve had many people across our customer base and broader community ask us questions about the new U.S. government requirements around cybersecurity, and how these impact organizations developing applications with open source.

So this week, we are happy to share that we’ve created a new government open source cybersecurity resource center to help organizations better understand these new policies, get a clear view into upcoming deadlines and requirements, and get recommendations on how organizations building applications with open source can ensure they stay in compliance.

Check it out now, or read on to learn more of the background about what these new government actions entail and who might be impacted.

A bit of background

Over the past few years, we’ve seen an increasing and ever-more-ominous set of threats to software security emerge. One of the first to make news outside of IT circles was the Heartbleed vulnerability in 2014. A few years later, an unpatched vulnerability in Apache Struts caused Equifax to expose sensitive data of millions of U.S. consumers (and the FTC would later reach a $700 million settlement with Equifax for damages caused by this breach).

But perhaps the vulnerability that put cybersecurity clearly in the higher echelon of urgent issues to be addressed by government action was the one that impacted SolarWinds and its customers—including many U.S. federal government agencies—in 2020. This vulnerability was what is known as a software supply chain attack, a particularly pernicious type of vulnerability because it doesn’t just impact one organization, but has the potential to impact ANY organization making use of the piece of software that it impacts, greatly increasing the potential attack surface.

While the SolarWinds software supply chain attack was not via an open source vulnerability, we’ve seen a barrage of open source-related software supply chain related vulnerabilities over the last few years as well. The recent one most covered by the media was Log4Shell, a vulnerability impacting a popular open source logging tool used by millions of organizations. But over the past year, we’ve also seen additional supply chain vulnerabilities emerge like Spring4Shell, and most recently, Text4Shell. 

Log4Shell in particular had a significant financial impact. For example, one federal cabinet department reported that they dedicated 33,000 hours to the vulnerability response. Each vulnerability continues to highlight the need for organizations to implement proactive approaches to maximizing the health and security of the open source powering their applications.

The U.S. government is now taking action to set higher cybersecurity standards

These continued vulnerabilities have exposed the nation's critical infrastructure to potential attacks by bad actors. The government has taken notice and in May, 2021 the White House issued Executive Order 14028. This order set in motion many of the other US government efforts to improve cybersecurity that are highlighted in our government open source cybersecurity resource center.

As directed by the Executive Order, the National Institute of Standards and Technology (NIST) published specific guidance on secure software development standards (including for third-party software) in the following documents:

• The NIST Secure Software Development Framework (SSDF), SP 800- 218 (Feb 2022)
• NIST Software Supply Chain Security Guidance (Feb  2022)

Additionally, in September of 2022, the Executive Office of the President, Office of Management and Budget announced memorandum M-22-18. Per this memorandum, 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 June 2023 (for critical software). 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 2023 for critical software and September 2023 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.

The impact on organizations building applications with open source

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?”

After all, it will be tough enough for many organizations to ensure they are meeting all thirty plus pages of the NIST requirements for their own, internally-developed software. But most open source software is created and maintained by volunteer maintainers, many of whom have not historically had the time or incentives to ensure their projects meet these rigorous new standards.

The critical role of open source maintainers

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. Because many open source maintainers are volunteers, expecting them to do more work to ensure their components meet these new standards is not a given.

The questions organizations should be asking themselves are:

• How do we attest to the security practices of open source software we use, but is produced and maintained by volunteer maintainers?
• Do the volunteer maintainers have all the support they need to understand these new guidelines and practices?
• Are they able to commit the time and effort needed to do the work of implementing the necessary guidelines and practices?

Tidelift partners directly with open source maintainers and pays them to ensure their projects meet an ever-growing body of common security and maintenance standards, including many of those recommended in the NIST guidelines.

To learn more about how Tidelift works directly with open source maintainers and pays them to ensure their projects meet important industry standards, including many of those required under the new government guidelines, take a tour of the Tidelift Subscription or schedule a demo today.

And be sure to bookmark the government open source cybersecurity resource center to keep abreast of the latest information and details, including upcoming deadlines and more information on how these regulations impact organizations developing applications with open source.