Demystifying the Vulnerability Propagation and Its Evolution via Dependency Trees in the NPM Ecosystem

1 INTRODUCTION

• Earlier work either analyzes direct dependencies or uses reachability reasoning that can resolve inaccurate transitive dependencies, limiting precise large-scale analysis and remediation.NPM’s dependency relationships and vulnerabilities change over time, complicating large-scale analysis of propagation evolution.Source: §1 · pp. 1–2
• The study identifies four challenges: ecosystem completeness, accurate NPM-specific resolution, analysis efficiency, and dependency changes over time.Real package installation can take minutes per run, while NPM releases can change installed dependency trees.Source: §1 · p. 2
• DTResolver combines DVGraph-based reasoning with official NPM dependency-resolution rules to simulate installations at any installation time, with over 90% of resolved dependency trees exactly matching real installations.Source: §1 · p. 2
• 93% of vulnerabilities enter dependency trees before discovery, 87% of fixing versions precede publication, 90% of vulnerable dependencies can be removed over about a year, and 40% remain unexcluded.The study also reports that vulnerabilities are widespread in dependency versions and that some projects retain unavoidable vulnerabilities even after all dependency trees are considered.Source: §1 · p. 2
• DTReme excludes more vulnerabilities than npm audit fix, and the paper offers stakeholder-specific solutions based on its ecosystem-wide findings.The contributions also include a complete DVGraph and publicly available analytic data.Source: §1 · p. 2

2.1 Motivating Example

• When resolving C@1.0.0, reachability selects D@1.2.0 and E@1.0.0, while NPM reuses the already installed D@1.1.0 that satisfies the constraint.The example illustrates how omitting NPM’s installation-context rules can yield inaccurate transitive dependencies.Source: §2.1 · p. 3

2.2 Background

• NPM package metadata records libraries, released versions, and version-specific dependencies; dependency constraints specify allowed version ranges for selecting dependency versions.NPM constraints can use version ranges, tags, Git or remote URLs, and local paths.Source: §2.2 · p. 3
• Semantic versioning separates Major, Minor, and Patch updates, while CVE reports describe vulnerabilities and affected versions in free text that must be mapped to libraries and versions.Source: §2.2 · p. 3

3 DVGRAPH CONSTRUCTION

• The graph links libraries, versions, and vulnerabilities through within-library, cross-library, and vulnerability-related relations.Relations include version ordering, dependency links, default satisfying versions, and vulnerability-to-version or vulnerability-to-library links.Source: §3 · pp. 3–4
• A robust parser handles diverse dependency constraints, while a semi-automated CVE triage process checks affected libraries and version ranges before graph updates.The update framework processes package metadata and CVE feeds; implementation and daily mapping validation involved three months of work and four security analysts.Source: §3 · p. 4
• The snapshot contains 1,147,558 libraries, 10,939,334 versions, and 62,232,906 direct dependencies; it covers 100% of registry libraries and 99.96% of versions.Only 0.36% of direct dependencies were not captured because their libraries were missing from the registry; 0.47% could not resolve to a satisfying version.Source: §3 · p. 4, Table 1 · p. 4
• CVE mappings were manually checked against existing CVEs after snapshotting, using the earliest publication times across sources.Source: §3 · p. 4

4 DEPENDENCY TREE RESOLUTION AND VULNERABLE PATH IDENTIFICATION

• The proposed static method uses DVGraph to resolve dependency trees precisely and efficiently without real installation, supporting vulnerability identification and path analysis.The section also notes that the approach can support other static software-composition-analysis tasks, including license and untrustworthy-dependency detection.Source: §4 · p. 4, paths (each node represents a package… · p. 5

4.1 Dependency Tree Definition

• A dependency tree for a root package comprises the library versions resolved during installation and the dependency relations among them; direct dependencies are distinguished from transitive ones.The section motivates static resolution because prior reachability-based methods omit NPM-specific rules, while real-installation approaches are less efficient for large-scale analysis.Source: §4.1 · p. 5, §4.2 · p. 5

4.2 Dependency Tree Resolution

• DTResolver simulates NPM’s folder allocation, reuses a satisfying version higher in the physical tree when present, and otherwise selects the latest satisfied version.It also maintains dependency relations to recover the logical tree and applies version-selection rules such as priorities for deprecated versions and latest tags; release-time filters support resolving trees at earlier times.Source: §4.2 · p. 5

4.3 Vulnerable Path Identification

• Dependency paths are ordered sequences of versions connected by dependency relations; vulnerable paths identify routes from affected versions that can propagate to the root package.The extractor uses reverse depth-first search from vulnerable points to the root and defines K-step paths by their number of dependency relations.Source: §4.3 · pp. 5–6

4.4 Validation of Dependency Tree Resolution

• Validation compared Graph Trees and npm-remote-ls Remote Trees with real installation trees; 82,415 of 103,609 sampled versions installed successfully.The sample was selected using popularity and centrality criteria.Source: §4.4 · p. 6
• 90.58% of Graph Trees exactly matched Install Trees, versus 53.33% for npm-remote-ls, after excluding incalculable cases.The authors attribute npm-remote-ls mismatches to missed NPM resolution rules, including priority selection on non-deprecated versions.Source: §4.4 · p. 6
• 98.1% vs 97.7% vulnerable-component coverage contrasted with 92.60% vs 78.31% vulnerable-path coverage for DTResolver and npm-remote-ls, respectively.The authors say dependency reach identifies most vulnerable packages but neglects NPM-specific rules that affect path accuracy.Source: §4.4 · p. 7

5 LARGE-SCALE EMPIRICAL STUDY

• Reachability analysis neglects inner dependency relations, limiting fine-grained study of vulnerability changes that the authors describe as important for precise remediation.The stated motivation is to investigate vulnerability propagation and evolution in dependency trees.Source: §5 · p. 7
• The section asks how vulnerabilities affect the NPM ecosystem and propagate through dependency trees to root packages.This is the first research question.Source: §5 · p. 7
• It also asks how vulnerability propagation evolves in dependency trees and how changes in those trees influence that evolution.This is the second research question.Source: §5 · p. 7

5.1.1 How many packages are affected by existing known vulnerabilities in the NPM ecosystem?

• 24.78% of NPM versions (2,711,222), across 19.96% of libraries (229,037/1,147,558), are transitively affected by 416 CVEs from 294 vulnerable libraries.The study captured 815 known vulnerabilities in 14,651 versions from 624 libraries.Source: §5.1.1 · p. 7
• 16.17% of libraries’ latest versions (185,598) remain transitively affected; 35.03% of vulnerable libraries with dependents have vulnerable latest versions.NPM usually resolves dependency constraints to the highest satisfying versions, increasing the chance that vulnerable latest versions are depended upon.Source: §5.1.1 · p. 7

5.1.2 How do vulnerabilities propagate to affect root packages via dependency tree?

• 25 CVEs each affect over 10,000 libraries or 100,000 versions, showing that some vulnerabilities have especially broad reach through dependency trees.The paper presents the ten CVEs affecting the most versions in Table 2.Source: §5.1.2 · p. 7, Table 2 · p. 7
• 88,192,572 vulnerable paths were identified; nearly 90% exceed three steps, and each vulnerable version has 3.97 vulnerable points on average generating 32.53 paths.Versions with over 1,000 vulnerable paths, representing 0.5%, were excluded from exhaustive path computation.Source: §5.1.2 · pp. 7–8
• 33.33% of vulnerable versions (903,569) have one-step vulnerable paths, and 12.04% (326,404) have only such paths.One-step paths also occur in 33.42% (62,022/185,598) of vulnerable latest versions.Source: §5.1.2 · p. 8
• 49.57% of vulnerable versions’ paths pass through one direct dependency, while 78.94% pass through no more than three direct dependencies.The study concludes that precise control of direct dependencies may cut off most vulnerable paths.Source: §5.1.2 · p. 8

5.2 RQ2: Vulnerability Propagation Evolution in Dependency Trees

• Default dependency trees can change when libraries release new versions, introducing or removing vulnerable points; the analysis follows these trees rather than outdated runtime dependencies.The study selected 53,541 versions and calculated 10,906,781 dependency trees from release to the latest snapshot.Source: §5.2 · p. 8, §5.2.1 · p. 8

5.2.1 How does known vulnerability propagation evolve over time?

• Known vulnerabilities affected 19.27% of selected versions (10,320) at release and 33.86% (18,127) at the latest snapshot; 69.76% of ever-affected versions had more CVEs over time.Only 7.4% had fewer CVEs; the study concludes that impact grew in both breadth and depth.Source: §5.2.1 · pp. 8–9

5.2.2 How long do vulnerabilities live in dependency trees?

• 60.05% of 243,448 CVE introductions were later removed, with an average living time of 371 days; 39.95% remained in the latest dependency trees.87.69% of eliminations occurred before CVE publication, while 7.4% of introductions occurred after publication.Source: §5.2.2 · p. 9

5.2.3 Why are there still a considerable portion of CVEs not removed?

• Compared with removed paths, not-removed paths more often involve fixed-version constraints (53.10% vs. 25.67%) and vulnerable latest versions (61.54% vs. 16.12%).The authors identify outdated maintenance by providers and unsuitable dependency constraints by consumers as likely reasons automated CVE removal is hindered.Source: §5.2.3 · p. 9

5.2.4 Example of remediation by avoiding vulnerability introduction (DTReme).

• DTReme combines forward vulnerability checking with backward installed-package tracking to find clean trees and generate a package-lock.json for remediation.The approach accounts for interacting dependency paths, since fixing one vulnerable path alone may not remove a vulnerability thoroughly.Source: §5.2.4 · pp. 9–10
• DTReme outperforms npm audit fix among 262 projects with vulnerable dependencies: it performs better in 77 projects, versus 30 where npm audit fix performs better.The 30 cases arise when npm audit fix violates direct dependency constraints; among 155 ties, DTReme reduces more vulnerable paths in 16 projects.Source: §5.2.4 · p. 10, Table 3 · p. 10

6.1 Lessons Learned by Our Study

• Providers should release fixes promptly, maintain clean versions compatible with common constraints, and check their own dependencies; consumers should periodically update locked trees within compatibility limits.The authors characterize this consumer strategy as trading off known-CVE risk against compatibility issues.Source: §6.1 · p. 10
• Auditors can use lighter static tools more frequently and pursue path-level remediation; call-graph reachability can help filter package-level warnings when vulnerable code is not called.The paper notes that package-level detection can produce false positives.Source: §6.1 · p. 10

6.2 Limitations and Threats to Validity

• Dependency-tree exposure may not affect a root package if vulnerable functions are never reached; the authors leave dependency-tree and call-graph analysis of vulnerable function paths for future work.This bounds the study’s package-level vulnerability impact analysis.Source: §6.2 · p. 10
• The analysis excludes versions with over 1,000 vulnerable paths because of computation costs; these versions account for 2.01% and may cause limited bias.Manual CVE-to-version labeling may also introduce mislabeling, which the co-authors cross-validated against existing CVEs.Source: §6.2 · p. 11

Vulnerability Analysis via Dependency

• Prior vulnerability-impact work often analyzes direct dependencies or reachability-derived transitive dependencies, whereas this study uses dependency trees to analyze transitive impact at scale.The related-work discussion notes that reachability reasoning can differ from accurate dependency resolution.Source: §7 · p. 11
• Unlike approaches focused on vulnerabilities in already installed dependencies, this work identifies vulnerabilities and vulnerable paths before installation and offers DTReme remediation recommendations.Source: §7 · p. 11

Ecosystem Analysis

• Compared with ecosystem studies limited to subsets or general ecosystem statistics, this study analyzes the full NPM package set at ecosystem and package-version levels using accurate dependency trees.Source: §7 · p. 11

• The authors conduct a large-scale empirical study of vulnerability propagation and its evolution in the NPM ecosystem.Source: §8 · p. 11
• DVGraph and DVResolver are used to statically and precisely resolve accurate dependency trees for each package at any time.Source: §8 · p. 11
• The authors propose DVReme as an example remediation method and highlight actionable solutions for stakeholders to mitigate NPM security risks.Source: §8 · p. 11