Malware in Open Source Ecosystems
Download the report
.png)
Executive Summary
For most of the history of open source software (OSS), organizations centered their threat models on vulnerabilities: known weaknesses in legitimate code that needed to be patched. That model is no longer complete.
Malware is present in many different types of open source components. This report is narrowly focused on a large category: software dependencies used in application code.
Malicious open source packages — code that was never trustworthy to begin with, or packages that were taken over by bad actors — have emerged as a distinct and fast-moving category of risk. This type of risk hit mainstream awareness with the 2024 XZ Utils compromise and escalated in 2025 with the high-profile Shai-Hulud campaign.
13.6x
51%
81%
48%
Why This Matters
It is estimated that 70% to 90% of a modern application’s codebase is composed of OSS, rather than code written by an organization’s software developers. The average enterprise application pulls in hundreds of direct dependencies, each of which may call dozens of transitive ones — a chain that grows fast and changes constantly. For most of open source security’s history, that chain’s primary risk was vulnerabilities: known weaknesses in legitimate code that attackers could exploit if left unpatched.
That’s still true. But it’s no longer the whole picture.
Malware in open source packages operates differently. While vulnerabilities are code bugs that could hypothetically be exploited, malware is code designed to cause harm. And with the former, generally danger is only present if the vulnerability makes it into production. But with open-source malware, the attack can start the second the package is imported. The detection surface is different. The response playbook is different.
Recommended Actions
Create an open-source malware taskforce that includes the following stakeholders:
- Engineering owns safe dependency consumption. Lockfiles, minimizing dependency sprawl, avoiding blind auto- upgrades, MFA on npm accounts. These aren’t exotic controls. They’re the baseline, and the survey shows they’re inconsistently applied.
- Application Security owns pipeline hardening and guardrail enforcement. Integrity checks, pinned versions in CI, install script controls, cooldown policies, malware detection integrated from AI IDE through production. AppSec sets the rules; the program makes sure they’re actually followed.
- Cloud Security owns blast containment and infrastructure resilience. Network segmentation, least-privilege access, runtime protection, key management. When a malicious package does get through, cloud security determines how far it can travel. And given that many malware campaigns seek to exfiltrate secrets, cloud security must be prepared for stolen cloud credentials.
Security Operations and Incident Response owns early detection and rapid counter-response. Threat intelligence feeds, IR playbooks specifically built for supply chain attacks, threat hunting for indicators of compromise. These are the people who get called when something lands — and the survey shows they often don’t know where the controls live.
About Endor Labs Research
Endor Labs’ Security Research team investigates how modern software is built—and how it breaks. Led by Henrik Plate, our team of six PhDs and security researchers is on a mission to help the industry understand and reduce risk across the entire software supply chain. From open-source dependency analysis to the rise of AI-generated code, Endor Labs research combines large-scale empirical data with hands-on experimentation to reveal how real development practices impact security outcomes. Each study aims to translate complex findings into practical guidance for engineering and AppSec teams, empowering organizations to build software that is both faster and safer by design.
Download Report