Open-Source Malware vs. Vulnerable Components: Knowing the Difference Matters

Written by Mitchell Johnson, CPDO of Sonatype

Open source has been a staple to modern software development for years – but, as the saying goes, with great power comes great responsibility. Unsurprisingly, considering up to 90% of software applications are made up of open source today, open source has also become a primary threat vector for cyberattacks.

In the last year alone, 91% of organizations have experienced an attack on their software supply chain. Organizations have combatted this growing threat by investing billions in tools to prevent, detect, and address software supply chain risk.

Yet, despite a growing emphasis and investment in good security practices, 99% of large organizations are still exposed to an easily exploitable security hole – one they can quickly address yet sneaks through most supply chains undetected. This threat is open-source malware. While technically a malicious open-source component, open-source malware is a particularly nefarious group because experts design it to look legitimate.

When we consider open source in the context of software supply chain security, there are three categories of open-source threats:

Related:Linux Malware: What To Know About the Malware Threat

Another thing that makes open-source malware components so insidious is that they are purpose-built to completely evade ALL traditional defenses like code reviews, vulnerability scanners, traditional Software Composition Analysis (SCA), and runtime security tools. Teams commonly don’t have the proper tools to combat this threat because many don’t know the difference between open-source malware components and vulnerable open-source components. 

These terms often get used interchangeably, but their meanings differ in profoundly important ways. The limited understanding of their distinctions has created a false sense of security, establishing an obvious security hole in virtually every organization. Knowing the difference and recognizing that each source of risk has very different mitigation strategies is key to a comprehensive and effective security program.

Vulnerable vs. Malicious Components

“Vulnerability” is the universal bucket developers often use to describe any risk to their software, but it is important to note that vulnerabilities are not intentionally bad. Instead, vulnerabilities are weaknesses in legitimate open-source components that cybercriminals can exploit to gain unauthorized access to a system or network. Open-source malware, on the other hand, is deliberately crafted to execute harmful actions – typically via the introduction of some form of malware – that can severely compromise a system and the organization it serves.

Related:4 Ways to Reduce Reliance on Bad Open Source Packages

If we were to think of software as a house, then vulnerabilities would be equivalent to a burglar sneaking in through an unlocked door. Open-source malware components would equate to someone purposely installing a faulty lock on the door with the intent of coming back and entering undetected.

A good example of open-source malware is the PyPI package (“pytoileur”) uncovered earlier this year. While developers thought they were adding a legitimate PyPI package, it was a counterfeit package hiding code that downloaded and installed trojanized Windows binaries capable of surveillance. Malicious components in an environment like this are evidence of a deliberate and delivered attack.  

Fighting All Open-Source Threats

It may seem like there has been an onslaught of new threat vectors recently. However, as cybercrime has exploded in a nearly $10 trillion industry, the widespread adoption of open source has driven the evolution of new threats like open-source malware components. 

Related:Are We Approaching the End of Open Source?

Combatting the ever-changing threat landscape requires more than traditional security measures. Cybercriminals are putting a new twist on old tactics to trick even the savviest developers. Teams must mitigate all risks and avoid leaving any security holes.

Relying solely on scanners to detect this next generation of threats will never be effective. DevOps teams need solutions designed to monitor, manage, control, and secure the flow of components within a repository environment to prevent known and unknown risks from entering their software supply chains. These tools can enforce control policies to ensure authorized users can access and modify packages within the repository. Additionally, they can validate the integrity and authenticity of the components before using them.

Building open-source software without the right level of protection has potentially devastating consequences. The first step in successfully mitigating threats is to distinguish between open-source malware components vs. vulnerable open-source components. This distinction matters to software development in addition to the reputation, business continuity, and financial stability of organizations that depend on reliable software to thrive.