It was always a leap to imagine a lone coder depending on their own brilliance and technical know-how to produce the next great piece of software. It is more of a myth today than ever before. Software developers must rely on code written by an unknown number of other programmers due to market factors. As a result, most software is best described as bricolage: a collection of disparate, usually open source components, referred to as dependencies, that are stitched together with bespoke code to form a new programme.
This software engineering model has resulted in enormous economic gains, with programmers reusing open source software components rather than duplicating the efforts of others. According to the most recent research, open-source components now make up 90% of all software products. And the list of economically significant and extensively used open source components — such as Google’s deep learning framework TensorFlow or its Facebook-sponsored competition PyTorch, the commonly used encryption library OpenSSL, or the container management software Kubernetes — is lengthy and increasing. Open source software is also used by the military and intelligence community: tools like Palantir have become critical for counter-terrorism operations, and the F-35 has millions of lines of code.
The issue is that the open-source software supply chain can introduce security flaws that are undisclosed and possibly purposeful. The bulk of malicious assaults targeted open-source software, according to a previous review of all publicly known software supply chain compromises. In other words, high-profile software supply-chain assaults on proprietary software, such as SolarWinds, are the exception rather than the rule. As a result of the vast complexity of the modern software dependency tree: components that depend on other components that depend on other components, and so on, halting attacks has become challenging. Software developers have a full-time and practically difficult task in determining what vulnerabilities exist in their code.
There is, nevertheless, reason for optimism. We propose three initiatives that software developers and government authorities might take to improve the security of open source software. To begin, producers and users should embrace software transparency, resulting in an auditable ecosystem in which software is no longer just mystery blobs exchanged over a network connection. Second, software developers and users should use software integrity and analysis tools to better manage supply chain risk. Third, government measures can assist limit the number of open-source software compromises and their consequences.
The Path to Dependency
Traditionally, the rise of reusable software components has been attributed to the 1960s. Software gurus like Bell Laboratories’ Douglas McIlroy had already mentioned the high cost of developing new software. To make things easier, McIlroy proposed the formation of a “software components” sub-industry dedicated to mass-producing software components that can be used across computers, users, and applications — in other words, exactly what modern open source software does.
When open source first began, it was centred on technical communities that offered governance, administration, and quality assurance. Debian, for example, is supported by a global network of open-source software developers who manage and implement guidelines for which software packages will and will not be included in the Debian distribution. However, this tight control has given place to a more ad hoc, perhaps more innovative system of package registries organised primarily by programming language. Consider these registries to be software developers’ app shops, allowing them to download free open source components from which to build new programs. The Python Package Index, for example, is a registry of Python packages that allows anyone to publish code on it, from an idealistic volunteer to a corporate employee to a criminal coder. The number of these registries is staggering, and they are now practically needed by all programmers.
Because of the efficiency of this software approach, open-source software is used by a large portion of society. Open-source enthusiasts quickly defend the present system by citing Linus’ law: “All defects are shallow if there are enough eyeballs.” That is, because the source code of software is open to inspection, software developers working and sharing code online will uncover flaws before they harm society, and society need not be concerned about its reliance on open-source software because this invisible army will safeguard it. If you look hard enough, that could have been true in 1993. However, much has changed since then. When hundreds of millions of new lines of open-source code are written in 2022, there will be too few eyes and deep bugs. That’s why it took two months to uncover in August 2018 that a cryptocurrency-stealing malware had been inserted into a piece of software that had been downloaded over 7 million times.
Event-Stream
The affair began when developer Dominic Tarr gave another entity known only as “right9ctrl” the publishing rights to an open-source JavaScript library named “event-stream.” The file was transferred using GitHub, a prominent code-hosting platform used by tens of millions of software developers. Right9ctrl, a user, had offered to maintain event-stream, which was being downloaded almost two million times per week at the time. Tarr made a reasonable and routine decision. He had made this open-source software available for free under a permissive licence — the software was offered as-is — but he no longer used it. He had already been maintaining several hundred pieces of open-source software for free. So when right9ctrl, whoever he was, asked for control, Tarr gave it to him.
Transferring control of open source software to a third party occurs frequently and with little impact. But there was a malicious twist this time. Right9ctrl added a new component after Tarr transferred control, which attempted to steal bitcoins from the victim’s computer. Until developer Jayden Seric detected an anomaly in October 2018, millions of PCs have downloaded this malicious software bundle.
The canary in the code mine was Event-stream. Computer security researchers have discovered attackers adopting a variety of novel approaches in recent years. Some are imitating domain-name squatting by tricking software developers into downloading malicious software when they misspell a package name (dajngo vs. django). Other attacks use software tool misconfigurations to fool developers into downloading software packages from the incorrect package registry. Over the last decade, the incidence and intensity of these assaults have increased. These figures don’t even take into account the arguably larger number of unintended security flaws in open source software. A White House summit on open-source software security was held recently in response to an unintended vulnerability in the widely used log4j software program.
The Three-Step Strategy
Fortunately, software manufacturers and customers, including the US government, can adopt a number of steps that will allow society to reap the benefits of open-source software while reducing the hazards. The first stage, which has already been endorsed by the United States, is Making software transparent so that it can be examined and understood is a priority for the Department of Commerce and industry. This began with initiatives to promote the usage of a software bill of materials. This bill is a comprehensive list or inventory of a piece of software’s components. With this list, searching for potentially corrupted components in software becomes much easier.
In the long run, this bill should include information about who authored the software and how it was built, rather than just a list of components. Imagine a food product with clearly described but unknown and unanalyzed constituents, to borrow logic from everyday life. That list is a nice start, but most people will pass without further investigation of these substances. Individual programmers, tech companies, and government agencies should all approach software components in the same way. One way to do so is to adopt Supply-chain Levels for Software Artifacts, a set of recommendations for tamper-proofing software supply chains within enterprises.
The next phase is software security firms and researchers developing tools to sign and validate software, as well as analyse the software supply chain and empower software teams to make informed component choices. One such attempt is the Sigstore project, which is a collaboration between the Linux Foundation, Google, and a number of other organisations aimed at leveraging digital signatures to make the chain of custody for open source software transparent and auditable. These technical solutions are the digital equivalent of a tamper-resistant seal. Sigstore has already been adopted by the Department of Defense’s Platform One software team.
A software supply chain “observatory” that collects, curates, and analyses the world’s software supply chain with the goal of preventing attacks could also be beneficial. An observatory, possibly administered by a university consortium, could help evaluate the number and severity of open source software compromises, give the underlying data that allows detection, and compare the success of various solutions statistically. The Software Heritage Dataset lays the groundwork for such a facility. Governments should assist in the support of this and other security-related activities. Tech businesses can also participate in numerous “nutrition label” projects, which provide a quick snapshot of a software project’s supply chain’s “health.”
