Today, the U.S. government issued the long anticipated 2023 National Cybersecurity Strategy. This is the next step in a series of recent actions (which we’ve summarized on our government open source cybersecurity resource center) to improve cybersecurity for federal government agencies, the nation’s businesses, and citizens as a whole.
In this advisory, we’ll share the key details of the National Cybersecurity Strategy, including some early impressions regarding how this strategy may impact organizations building applications with open source software.
In the wake of recent high-profile cybersecurity events like the SolarWinds breach, the ransomware attack on Colonial Pipeline, and most recently the Log4Shell supply chain vulnerability, the U.S. government has increasingly focused on creating policy that helps improve the nation’s digital defenses while also helping protect businesses and citizens impacted by cybersecurity threats.
To that end, the U.S. Congress authorized the creation of the Office of the National Cyber Director (ONCD) in 2021. One of the first critical responsibilities of the ONCD was to develop an overarching national cybersecurity strategy. This strategy, revealed this week publicly for the first time, will have an extensive impact on future policies and laws emerging from the government regarding cybersecurity. It was produced with extensive involvement and collaboration from industry leaders and cybersecurity experts, both inside and outside the administration.
For organizations developing applications with open source, the direct impacts of this new strategy might not be felt immediately. But leaders should pay close attention to the broad strokes of what is included so that they may prepare their organizations and development teams in advance of sweeping change to come.
Here are a few of the most important details that Tidelift feels are likely to impact organizations developing applications with open source most directly.
One of the highest-level impacts organizations are likely to see coming out of the new strategy is that the government is proposing a more overt, active approach to improving cybersecurity by increasing regulation and mandatory requirements. For application development teams, the recently released NIST Secure Software Development Framework version 1.1 and the requirements under OMB memorandum M-22-18 that organizations selling software the the U.S. government must self-attest that they comply with the NIST framework by as soon as June 2023 (for critical software) are examples of this active approach already underway.
Expect more of this sort of proactive government regulation to come, along with more “teeth” in the way of mandatory requirements that organizations wanting to sell software to the government will need to meet during the contracting process. For organizations using open source in their applications, now is the time to begin looking closely at the components they use in their open source software supply chain to better understand not just existing vulnerabilities, but the cybersecurity practices followed by the open source maintainers behind those components.
Thankfully, Tidelift is in a position to help with this. We partner directly with open source maintainers to validate that their projects meet key industry and government standards, including many of those required in the new NIST guidelines (learn more).
In parallel to the increasing focus on regulation, one of the elements of this new policy that all software development teams should be watching closely—whether they sell software to the government or not—relates to the effort to shift liability to hardware and software vendors.
Quoting the National Cybersecurity 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.”
The legislative details of how the National Cybersecurity Strategy will be implemented by the administration and Congress are still playing out. But all software teams, especially those that collect sensitive consumer or business data in industries like financial services or healthcare should remember the $700 million fine that the Federal Trade Commission levied on Equifax after its failure to patch a vulnerability in the Apache Struts open source project that caused the leak of millions of sensitive consumer data records. Or the reminder that the FTC issued last year, 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.”
Companies that develop software products and services are not without protection from liability. Those organizations that can systematically demonstrate that they are following best practices for secure development, for example as articulated in the NIST Secure Software Development Framework v1.1, will find a safe harbor from liability. Quoting the National Cybersecurity 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 organizations demonstrate that they are following the prescribed best practices, particularly for third-party open source software incorporated into their products and services? Partnering with independent upstream open source maintainers to establish systematic assurance that open source packages are following the secure development practices (for example, through platforms like Tidelift) will be an essential part of the solution. Attesting to these open source development practices will be a critical part of creating a shield against this liability.
To its credit, the U.S. government isn’t sitting back—it’s leaning forward to get more actively engaged in software development practices, specifically including open source software communities. Again quoting the National Cybersecurity Strategy:
“To further incentivize the adoption of secure software development practices, the Administration will encourage coordinated vulnerability disclosure across all technology types and sectors; promote the further development of SBOMs; and develop a process for identifying and mitigating the risk presented by unsupported software that is widely used or supports critical infrastructure. In partnership with the private sector and the open-source software community, the Federal Government will also continue to invest in the development of secure software, including memory-safe languages and software development techniques, frameworks, and testing tools.”
From Tidelift’s perspective, one of the best ways for the federal government and private industry to invest in the development of secure open source software is to proactively cooperate with open source maintainers behind the components our government, citizens, and businesses rely on and pay them to validate that their projects meet secure software development standards like the NIST SSDF and other industry standards like the OSSF scorecards project.
For more examples of how partnering with maintainers proactively can have a positive security impact, read Paying it forward: How paying maintainers improves the software supply chain for everyone.
Because this strategy represents a long-term vision for cybersecurity, many of the impacts on organizations developing applications with open source may not become immediately clear.
But 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.
That’s where Tidelift can really help. 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.
In addition, we provide organizations with the tools they need to track open source usage across the applications, and set policies and standards internally that open source components must meet. We then enable organizations to create their own catalogs of approved components that meet those standards, and allow any developer across the organization to pull components from that approved list.
This allows you to have a firm grasp of the security profile of all of your organizations applications—including both open source and non-open source components. By proactively doing the work to document these practices, you may be able to better meet government self-attestation requirements, to quickly produce a software bill of materials (SBOM) that shows your applications “ingredients” when it is requested, or simply to document your security practices so you can speed up remediation when the inevitable incident does occur.
What is most clear is that more government regulation to improve cybersecurity is inevitable. It will have impacts on all organizations building applications with open source, no matter their industry. If you’d like to keep up with the latest information from Tidelift subscribe to our newsletter or visit the government open source cybersecurity resource center.