How to ‘harden’ open-source software

The US federal government and several European governments have renewed their concern about the security of open-source software. Following the December 2021 revelation of log4shell, a severe and easily exploitable vulnerability in the popular open-source package log4j, federal and industry efforts have been made to improve open-source software security.

The Senate’s Committee on Homeland Security and Government Affairs proposed the Securing Open Source Software Act, which empowers the US Department of Homeland Security to understand the government’s dependence and critical infrastructure on open-source software. The US Office of the National Cyber Director is soliciting public feedback on open-source software security and public policy. Germany’s Sovereign Tech Fund has begun funding initiatives to improve its security.

Open-source software, which allows anyone to inspect, modify, and distribute its source code, has received such high-level attention in part because so much of modern software, including military systems and critical infrastructure, relies on it. Today’s software is mostly open source, written by a third party, not the developer. The exact percentage of open-source code in deployed software varies depending on how the lines of code are measured.

Software developers rely on open-source packages from public repositories for efficient coding. The Python Package Index, analogous to an app store for open-source Python packages, now hosts nearly 500,000 projects. npm, an equivalent Javascript registry, contains millions of packages.

Open-source software is a modern marvel for software developers who need to build applications quickly and easily. However, code from open sources has had and may continue to have significant security issues. There are hundreds or thousands of known malicious compromises of open-source software. The number of unintentional vulnerabilities is also large, though the exact number defies simple measurement. The debate over whether open source or proprietary software is more secure is moot because of the prevalence of open-source inputs. The only pressing question is how to make open-source software more secure than it currently is.

The Open Source Hardening Project

In 2006, the Department of Homeland Security awarded a contract for a little over a million dollars to Coverity for the Open Source Hardening Project, an effort to publish the security-related findings of its tool for hundreds of major open-source software projects. Open-source projects — often under-funded and volunteer-run — used Coverity’s tool for free. Instead, the security findings, a list of potential security bugs, were made available to these open-source software developers. The developers were then free to use this information to fix any security bugs that the information revealed.

By all accounts, the project was a success. During the three-year programme, developers across multiple open-source projects successfully fixed over 11,000 security vulnerabilities. The overall density of security defects in these projects dropped by nearly 20%.

The profit motive

The programme’s success is remarkable because it contradicts current theories about open-source code’s weaknesses. Prominent open-source software advocates often argue that companies and governments must fund open-source software maintainers to ensure security directly. Other advocates, while supportive of direct funding for maintainers, also believe that companies, foundations, and even governments should partner jointly and create large-scale plans to secure open-source software. In this view, a strong coalition of well-funded companies, foundations, and government agencies is necessary to address open-source software security issues.

The Open Source Hardening Program demonstrates that the profit motive can help secure open-source software. Although the Department of Homeland Security provided funding for this effort, it did not go directly to open-source software maintainers and did not require a broad coalition. Instead, Coverity pursued this programme for commercial reasons: the more open-source developers became comfortable with Coverity’s security analysis tool, the more likely they were to be to encourage their companies to purchase the tools. In short, Coverity’s long-term financial prospects were the key to its success.

To be sure, although open-source maintainers benefited from government funds, it was not a direct payment. Instead, the open-source software developers who took part in this programme benefited from better security tools and data which advanced the projects they championed. Simply put, the tools and data helped contributors — often part-time volunteers working nights and weekends — better identify and prioritise fixing unintentional security vulnerabilities.

Smaller, simpler, and cheaper

Of course, mobilising industry and government to secure open-source software has appeal, given the breadth of its security problems. Paying open-source software developers directly dovetails with a widely held belief that a root cause of open-source software insecurity is that many maintainers are volunteers. But the Open Source Hardening Program shows the elegance of another solution: providing additional funds to for-profit companies whose mission is predicated on improving open-source security.

Fortunately, the Department of Homeland Security is taking a page from its own playbook with its recent call for funding nimble outfits interested in building software supply chain security-related tools. The recently introduced Securing Open Source Software Act also aligns with these efforts.

Some organisations, such as Germany’s Sovereign Tech Fund and philanthropic efforts, prefer to fund open-source software foundations and maintainers directly. There is room for that approach, too, but the Open Source Hardening Project suggests that such approaches are not the only path to security. The real trick will be for other parties, those with either ambitious plans or a scheme to fund open-source software developers, to reflect on what this forgotten programme from the past implies for their future.