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

The White House National Cybersecurity Strategy

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.

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 the National Cybersecurity Strategy

In response to high-profile cybersecurity events such as the SolarWinds proprietary software hack and the Log4Shell exploit on the open source software supply chain, the U.S. government raised the nation's cybersecurity efforts in an effort to protect U.S. digital infrastructure, businesses, and citizens. In 2021, the U.S. Congress authorized the creation the Office of the National Cyber Director (ONCD). One of the first responsibilities of the ONCD was to develop an overarching national cybersecurity strategy and in March 2023, the Biden-Harris administration released the National Cybersecurity Strategy. The strategy proposes a more active approach to improving cybersecurity by increasing regulation and mandatory requirements, something we've already seen with memorandum M-22-18 and the memo to follow, M-23-16. 

Since publication in March 2023, the White House published an update to the National Cybersecurity Strategy, the National Cybersecurity Strategy Implementation Plan

A liability shift from consumers to commercial producers of software

To quote the strategy:

“Companies that make software must have the freedom to innovate, but they must also be held liable when they fail to live up to the duty of care they owe consumers, businesses, or critical infrastructure providers.  Responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not on the end-users that often bear the consequences of insecure software nor on the open-source developer of a component that is integrated into a commercial product.”

This isn't the first time the U.S. government has issued a warning regarding the responsibility of businesses to protect customers from problematic cybersecurity events. In January 2022, the FTC reminded us, after Log4Shell, that it intends to “use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.”

Offering a safe harbor for organizations making headway on secure development practices

The shift in liability can be daunting and the hard reality is, implementing secure development practices takes time, but worry not, the strategy provides detail into the safe harbor. Directly from the strategy:

“To begin to shape standards of care for secure software development, the Administration will drive the development of an adaptable safe harbor framework to shield from liability companies that securely develop and maintain their software products and services. This safe harbor will draw from current best practices for secure software development, such as the NIST Secure Software Development Framework. It must evolve over time, incorporating new tools for secure software development, software transparency, and vulnerability discovery.”

How can my organization take steps towards meeting government cybersecurity compliance? 

One way to prepare now is to begin to assess the security policies your organization has in place for application development, and how you continuously audit and manage the health and security practices of the open source libraries you use in your applications. It's also recommended to catchup on the secure software development guidelines outlined by the National Institute of Standards and Technology (NIST) in the NIST Secure Software Development Framework (SSDF)

It's important to note while keeping the liability shift in mind, that the NIST SSDF states 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. 

Tidelift partners with maintainers to ensure their components meet government and industry standards (like many of those included in the new NIST guidelines), now and into the future, and pays them to do this important work. To learn how Tidelift can help your organization attest 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.