Defending Fire: A Need for Policy to Protect the Security of Open Source

Open-source software has served as an important catalyst for much of modern digital technology, scaling small innovations into widely used features in weeks instead of years. Yet the past few years have shown that open source is at risk. One of the most consequential cybersecurity incidents in recent memory, Log4j, exploited a vulnerability in a critical open-source logging tool used by millions of apps across the planet. This incident highlights the dichotic relationship between society’s collective dependence on open-source code and the lack of investment in its security. To preserve the future of the software ecosystem, the United States and its partners and allies must expand existing cybersecurity policy efforts to better address and mitigate risk to open-source tools and core libraries.

Open-source software is software that is developed by “an interacting, self-governing group involved in creating innovation with members contributing toward a shared goal of developing.” This software is widely used and performs numerous functions critical to the health and operation of the internet. Sharing information and tools is common practice across open-source development. However, these efficiencies create risk. The collaborative nature of open-source software can be both a benefit and a drawback, with open-source developers placing their trust in the tools and code of others without the time or ability to verify that these resources are adequately secure. The success of open source is such that this risk management model is no longer commensurate with the risk borne by this code. 

In the past few years, there has been a higher volume of attacks, with an increased level of sophistication targeting open-source software. These incidents have included operations targeting the enabling tools and core infrastructure that help foster and maintain open-source environments—an especially sinister tactic. Since 2010, there have been at least 43 recorded incidents targeted at open-source software—with the majority of these attacks targeting core open-source tools and core libraries. 

One pernicious example of this risk is the 2021 Travis CI exploit. Travis CI is a continuous integration (CI) tool that allows multiple developers to rapidly test and incorporate overlapping code changes for projects hosted on GitHub into a single project. From Sept. 3 to Sept. 10, a vulnerability in Travis CI would have allowed attackers to exfiltrate secure environment variables, such as signing keys and access credentials, potentially compromising thousands of open-source projects. The vulnerability was discovered and reported on Sept. 7 by Felix Lange and Péter Szilágyi of Ethereum. Travis CI patched the reported vulnerability only after facing three days of pressure from multiple organizations that relied heavily on the tool. Travis CI’s response was limited to silently patching the vulnerability without a formal incident report, a lack of a postmortem analysis, and no notification for Travis CI users that their sensitive data may have been exfiltrated. 

Travis CI is just one of many notable examples of software supply chain vulnerabilities that target developer tools, repositories or infrastructure in the open-source ecosystem. In November 2018, an attacker inserted malicious code into a widely used JavaScript library. This gave the attackers access to any software that integrated that library, eventually resulting in the compromise of Copay, a cryptocurrency wallet app, and the theft of users’ funds. In September 2021, a researcher found a vulnerability in the NPM package “pac-resolver,” which enables remote code execution. This vulnerability was widely circulated and could have compromised vital open-source projects if an attacker inserted malicious code or decided to steal information from an infected machine. 

However, the best example has occurred the most recently. The Log4J tool is a Java-based logging utility that helps developers track and record a wide range of systems found in software products and services. On Dec. 9, 2021, it was reported that the open-source logging tool could be manipulated to achieve remote code execution. The vulnerability compromised hundreds of thousands of organizations because of the Java language’s widespread use, the wild popularity of the Log4j tool with some 400,000 GitHub downloads, and the application’s deep access to systems connecting millions of devices. Many organizations are still unaware of that fact, even today. 

These incidents constitute a troubling pattern of criminal and state abuse of open-source code. These tools represent critical choke points in the open-source ecosystem and a ripe target for attackers to gain access to potentially thousands of targets. This low-investment, high-return model is what makes software supply chain attacks such a significant source of cybersecurity risk, and open-source developers’ tools and repositories are juicy targets even against that backdrop. 

The security of Log4j, however, and many of these other projects do not reflect how vital this software is. Log4j serves as a cornerstone for Java- and Apache-based applications, and Travis CI is used by hundreds of thousands of developers globally. Because open-source software is utilized on such a large scale, vulnerabilities within the development ecosystem leave vast numbers of projects, and their end users, at risk. Repositories, package managers, and critical digital infrastructure facilitate the sharing of information and collaboration among contributors to complete projects, but they also have the potential to play host to critical and systemic security vulnerabilities. 

President Biden’s Executive Order 14028, “Improving the Nation’s Cybersecurity,” addressed some of the most pressing software supply chain security issues but was limited in scope to the cybersecurity of the federal government and only began to address the open-source risk. Efforts to retroactively secure the open-source software supply chain are a good start, but current initiatives are insufficient and more must be done. Here are three places to start; one for Congress, one for the Department of Homeland Security and one for the federal government more holistically.

First, funding. The private sector grudgingly began to fund open-source security efforts after discovery of the 2014 Heartbleed vulnerability in a web cryptographic library. Since then, private-sector investment has grown slowly through efforts like the Linux Foundation’s Open Source Security Foundation and Google’s recently established Secure Open Source (SOS) pilot rewards program. To date, however, outside of targeted bug bounty programs, the U.S. government’s investment has not matched up and its funding to secure open-source projects continues to be insufficient. To better address these risks and keep pace with industry, Congress should pass the Critical Technology Security Centers. It currently sits as a proposed amendment to H.R. 4521,the America COMPETES Act of 2022, before the House Committee on Science, Space, and Technology. The legislation proposes a center for open-source software security, among others, and would allow the Cybersecurity and Infrastructure Security Agency (CISA) director to prioritize investments by the Department of Homeland Security into the most impactful open-source projects, tools and potential targets. The open-source software security center would finally give the U.S. government an adequately resourced and purpose-built organization to help secure open-source tools and support open-source projects to remediate existing vulnerabilities, preemptively identify and mitigate future vulnerabilities, and raise the standard of security for open-source projects.

Second, CISA should lead federal prioritization of vulnerability mitigation and patch enforcement efforts, not only for vulnerabilities in the open-source supply chain but also for the platforms and infrastructure that coordinate and support the open-source ecosystem. Package managers (NPM, RubyGems), CI tools (Travis CI), and other platforms have the ability to expand the reach of malicious users by an order of magnitude and to compromise otherwise secure applications due to the vast number of developers who depend on their code and infrastructure. CISA should lead a coordinated federal-private sector effort to identify these critical nodes in the open-source ecosystem and funnel funding and tooling toward securing them. 

Third, the ongoing Federal Acquisition Regulations (FARS) reform effort established in Executive Order 14028, combined with CISA and Office of Management and Budget binding operational directives, can make the federal government a leading motivator for these repositories to provide better security tools to their users and stronger enforcement of good security practices. Future federal acquisition processes should favor products using open-source code supported by infrastructure—repositories, tooling, and core libraries—with significant security investment and development teams over projects left out to dry.

The software supply chain that modern society depends on is rife with vulnerabilities. Executive Order 14028 charted an effective, if incomplete, path forward, and federal cybersecurity policymakers must prioritize the security of open-source development tools and infrastructure. Without adequate investment and judicious policy intervention, critical nodes in the open-source ecosystem might pose more risk than benefit to developers across the world. Collaboration remains the coin of this realm, and efforts like these to mitigate risks are a means of ensuring that collaboration continues to flourish. It is hard to imagine a more significant drag on the innovative potential of the technology community or threat to the value of software in the federal enterprise should these risks accelerate and the harsh realities of the Log4j response become all too commonplace.