It is no exaggeration to say that open-source software has transformed the way software is written over the last two decades. Many of the most recognised software we use such as the Linux kernel, the Postgres database, the Firefox browser, and the Kubernetes container orchestration system, to name a few, are open-source projects that have influenced and galvanised developers around the world.
The impact is arguably felt even more in the enterprise, where open-source code is the basis for modern application development. Today, developers tasked to create anything from in-house applications to building the “next big thing” rely heavily on a plethora of open-source projects, languages and frameworks ranging from the well-known such as Python to the esoteric such as MLflow.
With open-source code found in over 90% of applications today, cyber attackers have taken note and are now seeking to twist the inherent trustworthiness of the open-source ecosystem to meet their nefarious ends.
The developers behind the code
As many are doubtlessly aware, the ethos behind open source centers on publishing their source code for anyone to use it in their applications, improve it or review it for security flaws. With a large base of inspectors with full access to quickly find issues within a traditionally trusted community, open-source software is generally regarded as being more secure than proprietary solutions. But what if cyber attackers exploit that community of trust and directly target the developers working on these open-source projects?
For instance, the author of popular JavaScript library “UAParser.js” had his account at npm - a top software registry - compromised in October last year. The attackers modified the software package with extra scripts to download and execute binaries from a remote server, installing tools such as a password stealer and a cryptocurrency miner. Though the malicious update was swiftly rectified thanks to the quick response of author Faisal Salman, there is no avoiding the chilling fact that the library sees millions of weekly downloads and the potential for negative impact is widespread.
And this is hardly an isolated event. Barely two weeks later, another popular npm library named ‘coa’ with nine million weekly downloads was hijacked. A few hours later, another component ‘rc’ with 14 million downloads a week was found to be compromised. And the problem is recurring with alarming regularity. Earlier in August, another attacker took over an open-source package with more than three and a half million downloads weekly.
What is evident is that these are not one-off incidents, but a sustained trend of supply chain attacks targeting weak chinks in the open-source ecosystem. Beyond the incalculable damage from just one successful insertion of malicious code into the hearts of enterprises, these attacks also severely undermine the trust that we automatically give to popular packages.
Down the rabbit hole
Today, the typical developer looking for a suitable open-source package evaluates it based on its suitability, popularity, and whether it looks legitimate. He or she will look at the available scoring mechanism, get feedback from peers, and look out for recent complaints. After all, most developers do not have the interest or resources to scrutinise the dozens of other open-source packages that it might rely on or the hundreds of contributors working on them.
Therein lies the problem: the sheer number of open-source packages out there makes it likely that a compromised package could find its way into production code - npm alone sees half a million new packages released every month. The challenge is further exacerbated by the complex interdependencies in open-source software, which greatly increases the attack surface through no fault of the harried developer.
On the other side of this new battlefront, the attackers have built sophisticated infrastructure and automated tools with the sole aim of poisoning open-source packages at scale. User accounts are created en masse to obfuscate their tracks, while disposable domains are set up as command-and-control nodes to manage the injected malware.
Apart from strategic attacks on developers, we are also seeing a sharp increase in malicious packages that are published. For example, one such threat actor, RED-LILI, has published over 1,500 malicious packages using automatically generated npm accounts. Another threat action, CuteBoi, has published over 2,500 malicious packages to date.
The road forward
What can we do to protect our applications, our stakeholders, customers, and users? To craft effective defences, we must first understand that we are talking about an attacker, not software vulnerabilities here. We absolutely do not want malicious code inside our applications and preventing that calls for a completely different mindset.
To be clear, open-source is an excellent approach to developing innovative applications, and we want developers to have the freedom of using open-source code. However, we must discard our current assumption that a project is safe just because it is popular or has a high average rating.
As an industry, we must work better together to improve our standards and close the gap to tighten our supply chain security. We must improve and put better mechanisms and better protections in place and give developers better tools to examine the code that they are reusing.
Fortunately, the industry is now starting to deal with attackers in software supply chains. For instance, SLSA, or Supply-chain Levels for Software Artifacts, is an industry security framework that outlines a list of standards and controls to prevent tempering, improve software integrity, and secure packages and infrastructure.
Ultimately, we will be far less susceptible to supply chain attacks if we ensure that the open-source code that we take from others is secure. In a nutshell, don't take code from strangers without vetting.
