💻 computer science

Original Sin of npm: A Study on Vulnerability Propagation in JavaScript Dependency Networks

This study analyzes a dataset of over 1 million JavaScript packages to reveal that a small number of vulnerabilities propagate widely through the npm dependency network, causing 21.6% of packages to be affected with high severity, while highlighting a significant delay between vulnerability fixes and their public disclosure.

Original authors: Michael Robinson, Sajal Halder, Muhammad Ejaz Ahmed, Muhammad Ikram, Seyit Camtepe, Hyoungshick Kim

Published 2026-04-21

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Michael Robinson, Sajal Halder, Muhammad Ejaz Ahmed, Muhammad Ikram, Seyit Camtepe, Hyoungshick Kim

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Picture: The "Digital Lego" Problem

Imagine you are building a massive castle out of Lego bricks. Instead of making every single brick yourself, you go to a giant public warehouse (called npm) where millions of people have left their own custom-made bricks. You grab a few, snap them together, and suddenly you have a castle in minutes. This is how modern software works, especially for JavaScript (the language that powers most of the internet).

This paper is a study of what happens when one of those borrowed bricks is broken.

The Core Problem: The "Original Sin"

The title refers to the "Original Sin" of this system: Vulnerability Inheritance.

If you borrow a Lego brick that has a hidden crack (a security vulnerability), every castle you build using that brick is now unsafe. But here's the scary part: You might not know the brick is broken. Worse, the brick you borrowed might have been built using another broken brick from a different shelf.

The researchers found that a tiny number of broken bricks are responsible for breaking almost the entire castle.

Key Findings (Translated)

1. The "Bad Apples" Are Everywhere

The researchers looked at over 1 million software packages (the Lego bricks).

The Stat: About 21.6% of all these packages rely on at least one broken brick somewhere in their chain.
The Analogy: Imagine walking into a library where 1 out of every 5 books has a page missing. If you read one of those books, you might miss a crucial plot point. In software, that "missing page" is a hole hackers can use to steal your data.
The Severity: Most of these "missing pages" are High Severity (42%) or Critical (26%). These aren't just typos; they are gaping holes in the wall.

2. The "Super-Spreaders" (The 80/20 Rule on Steroids)

The study found that vulnerabilities don't spread evenly. They spread like a virus through a few specific "Super-Spreaders."

The Stat: Just 7 specific broken bricks account for 25% of all the security problems. If you fix those 7, you fix a quarter of the entire ecosystem's issues.
The Analogy: Imagine a city where 90% of the traffic jams are caused by just 3 specific intersections. If the city fixes those 3 intersections, the whole city moves smoothly. The researchers found that a handful of popular libraries are the "traffic jams" of the internet.

3. The "Slow Fix" vs. The "Fast Fix" Paradox

This is the most confusing and interesting part of the study.

The Problem: It takes a long time to fix a broken brick. On average, it takes 4 years and 11 months from the moment a broken brick is first used until it is finally fixed.
The Twist: However, the researchers found that 83% of the time, the fix was actually ready before anyone knew the brick was broken.
The Analogy: Imagine a mechanic fixes a car's engine on Tuesday. But they don't tell the car owner until next Friday. The car was safe on Tuesday, but the owner kept driving it dangerously because they didn't know the fix existed.
Why? Developers often fix the code quietly and release a new version without announcing, "Hey, we fixed a huge security hole!" They wait for a formal announcement (which takes years), leaving users in the dark.

4. The "Ticking Time Bomb" Timeline

Discovery: It takes about 6 years (median) for a broken brick to be officially labeled as "broken" in the public database.
The Lag: Even after the fix is available, people keep using the old, broken version for years.
The Analogy: It's like a fire alarm that goes off, but the building manager waits 6 years to tell the tenants there is a fire, and even after they tell them, half the tenants keep sleeping in the burning building because they are used to the old routine.

Why Does This Happen?

The paper suggests three main reasons:

Complexity: The web of dependencies is so deep (some packages rely on 800+ other packages) that it's impossible to track who is using what.
Silent Fixes: Developers fix things quietly to avoid panic or because they don't want to break other people's code, but this leaves users unaware.
Outdated Habits: Developers are lazy or busy. They stick with old versions of libraries because updating is hard and risky.

What Should We Do? (The Recommendations)

The authors suggest a few practical steps for developers and companies:

Don't Pin Your Bricks: Don't lock your software to one specific version of a library. Let it update to the latest "safe" version automatically.
Prune the Garden: Get rid of libraries you aren't actually using. If you aren't using a tool, you don't need to worry about its broken bricks.
Trust but Verify: Just because a library is popular doesn't mean it's safe. Check if the maintainers are active and responsive.
Fix Before You Announce: Developers should fix the hole first, then tell the world. Don't wait for a formal report to make the code safe.

The Bottom Line

The "Original Sin" of npm is that we built a massive, interconnected system where one small mistake in a tiny, hidden corner can bring down the whole house.

The study shows that while the number of broken bricks is growing, it's growing in a predictable, linear way. If we focus our energy on fixing the top 20 most common broken bricks, we could secure nearly half of the entire internet's software infrastructure. The technology to fix this exists; we just need to change how we manage our digital Lego sets.

1. Problem Statement

The widespread adoption of open-source software (OSS) and package managers like npm (Node Package Manager) has accelerated development but introduced complex security risks. Specifically, the paper addresses vulnerability inheritance, where a parent package inherits security flaws from its dependencies (both direct and transitive/indirect).

Key challenges identified include:

Complexity of Dependency Networks: Modern JavaScript ecosystems involve deep, multi-layered dependency chains, making it difficult to trace the origin and spread of vulnerabilities.
Lack of Comprehensive Analysis: Prior studies often focused on direct dependencies, small sample sizes, or static snapshots, failing to capture the dynamic, large-scale propagation of vulnerabilities across the entire ecosystem.
Delayed Remediation: There is a critical need to understand the timeline between vulnerability discovery, publication, and the availability of fixes, as well as the rate at which downstream packages adopt these fixes.

2. Methodology

The authors constructed a massive, structured dataset and employed statistical survival analysis to investigate vulnerability propagation.

Data Collection & Construction

Source: Data was sourced from the 'npm-follower' project (weekly snapshots of npm), deps.dev (for dependency graphs), Google Open Source Vulnerability (OSV) API, and the National Vulnerability Database (NVD).
Scale: The study analyzed 1,077,946 unique npm parent packages (a representative subset of ~4 million total packages).
Dependency Mapping: Using the deps.dev API, the authors constructed full dependency graphs for each parent package, distinguishing between direct and indirect (transitive) dependencies.
Vulnerability Linkage: Vulnerabilities were identified by parsing package names and versions against OSV and NVD, linking them to specific CVEs and CVSS scores.
Database: A custom vulnerability database was created containing 1,517 unique vulnerabilities and over 2.1 million vulnerability instances across the dataset.

Analytical Approach

Survival Analysis: The authors utilized Kaplan-Meier estimators to model time-to-event data (e.g., time from first vulnerable release to publication, or time to fix). This method handles "right-censored" data (vulnerabilities not yet fixed or published at the time of study) more accurately than simple arithmetic means.
Regression Analysis: Linear and exponential models were used to assess the growth trends of vulnerabilities and affected packages over time ( $R^2$ values calculated).
Correlation Analysis: Investigated the relationship between dependency depth/quantity and vulnerability prevalence.

3. Key Contributions

Large-Scale Empirical Study: One of the first studies to analyze over 1 million npm packages and their full transitive dependency networks, moving beyond the limited scope of previous works (e.g., Decan et al., which analyzed ~400 vulnerabilities).
Temporal Alignment: The study uniquely aligns timelines to the first affected release (upload date) rather than just the advisory publication date, revealing the true "exposure window" for downstream users.
Propagation Quantification: It quantifies the "vulnerability propagation ratio," demonstrating how a small number of high-frequency CVEs disproportionately impact the ecosystem.
Remediation vs. Adoption Gap: It distinguishes between the time it takes to publish a fix and the time it takes for the ecosystem to adopt it, highlighting that slow adoption is a primary driver of risk.

4. Key Results & Findings

Vulnerability Prevalence & Severity

Dependency Reliance: 61.30% of packages rely on at least one dependency.
Infection Rate: 21.60% (232,836) of all analyzed packages contain at least one known vulnerability in their dependency network.
Severity Distribution: Of the 1,498 unique vulnerabilities (CVSS v3.x), 42% are High severity, 31% Medium, 26% Critical, and only 0.5% Low.
Growth Trend: The number of vulnerabilities and affected packages has increased linearly since 2015 ( $R^2 = 0.97$ and $0.96$ respectively), not exponentially.

Timeline & Remediation (RQ1 & RQ2)

Publication Lag: The median time from the first vulnerable version being uploaded to npm to its public disclosure (OSV/NVD) is ~71 months (5 years and 11 months).
Fix Availability: Surprisingly, 83.1% of vulnerabilities are fixed before they are publicly published. The median time from publication to fix is -19 days (indicating the fix existed ~19 days prior to disclosure).
Total Fix Duration: Despite early fixes, it takes a median of 59 months (4 years and 11 months) from the first vulnerable release for a fix to be available.
Adoption Gap: Even when fixes are available, downstream packages take years to update, with many continuing to use vulnerable versions long after patches exist.

Propagation Patterns (RQ3)

Pareto Principle (80/20 Rule): A tiny fraction of vulnerabilities causes the majority of risk.
- The top 7 CVEs account for 25% of all vulnerability instances.
- The top 23 CVEs account for 50% of all instances.
- The top 1 CVE (CVE-2023-44270) alone affects 24,882 packages (8.34% of total instances).
Dependency Depth: Vulnerabilities are most prevalent in packages with 4–6 levels of dependency depth.
Propagation Ratio: On average, 13.9% of packages affected by the top 20 CVEs account for 50% of the network coverage. This implies a propagation ratio of 3.6, meaning each affected package influences ~3.6 other packages through the dependency chain.

5. Significance & Recommendations

The paper concludes that the npm ecosystem suffers from a "Original Sin" of deep, unmanaged dependencies where a few critical packages act as single points of failure.

Recommendations:

For Developers:
- Adopt permissive version constraints (e.g., ^ or ~) rather than pinning exact versions to allow for automatic patch updates.
- Prune unused dependencies and separate development dependencies from production ones.
- Prioritize updating packages that are part of the "top frequent CVE" list.
For Maintainers:
- Release fixes before public disclosure to minimize the window of exploitation.
- Improve security culture and transparency to build trust.
For Tooling:
- Integrate automated dependency analysis and update suggestions into CI/CD pipelines.
- Improve vulnerability scoring (e.g., moving toward CVSS v4) to better reflect real-world risk and reduce false positives.

Significance:
This study provides a quantitative foundation for shifting the security paradigm in the JavaScript ecosystem from reactive patching to proactive dependency management. It highlights that while the discovery of vulnerabilities is improving, the propagation and remediation lags remain critical systemic failures that require structural changes in how dependencies are managed and updated.