2024 Dependency Management Report | Endor Labs

What it is

Endor Labs' 2024 dependency management report, built from its customer telemetry plus OSV/NCSU datasets (snapshot June 2024). Beyond the headline stats in the summary, it contains reproducible methodology and concrete gaps in public advisory data that affect how you configure SCA tooling.

How it works

Phantom dependency detection (Python). Instead of pip freeze (which inflates results on shared environments and monorepos, and loses direct/transitive distinction) or manifest-only parsing (which misses installed packages), Endor analyzes first- and third-party code in the library search path and recursively follows import statements. Dynamic installs (e.g. neural-compressor installing sigopt at runtime) are only caught if that code has already executed. Causes cited: runtime installs, manual/scripted installs, bloated container images, monorepos.

Rebundling blind spots. Binaries such as libgcc and liblzma (from XZ Utils) sit in hundreds of Python artifacts with no package metadata. In Java, uber JARs repackage vulnerable classes; one cited study found 254 vulnerable classes from 38 components repackaged into thousands of other components, sometimes with metadata stripped or namespaces changed.

Upgrade-risk method. For the 15 Java components with the most customer vulnerabilities, they took 1,265 vulnerable versions released 2017 or later, and computed the nearest non-vulnerable version (1,250 had one; the 15 without were org.bouncycastle:bcprov-jdk15on). They then diffed for removed functions/types and visibility reductions. Function removal was the dominant breaking change.

Preconditions / Affected

• npm users relying on NVD alone: 18% of npm OSV entries lack CVE aliases (Maven 1%). Overall, 828 of 13,963 OSV entries across six ecosystems have no CVE alias.
• Teams consuming only NVD feeds: for 5,978 vulns with both a GHSA and a CVE, most appear first in NVD, and in 25% of cases the GHSA lags by 10+ days. During that lag only imprecise CPE mapping is available.
• Maven BOM/parent POM advisories (e.g. vaadin-bom, keycloak-parent for CVE-2017-12159) may never map to the artifact that actually carries the code (keycloak-services).
• Tomcat: CVE-2020-13935 is listed by OSV only for org.apache.tomcat:tomcat, but Endor says five artifacts contain the vulnerable classes, including tomcat-embed-core and tomcat-embed-websocket, with PoCs showing exploitability. Spring Boot embedded users could be missed. Older coordinates (tomcat:catalina, org.apache.tomcat:catalina) are also unflagged for CVE-2023-41080.
• Endor vs OSV agree on affected packages in only 72% of cases overall, and 55% for Maven.

What to do

• Confirm your SCA tool ingests OSV/GHSA, not just NVD, especially for npm.
• Check whether it resolves Python deps beyond manifests; if it uses pip freeze on shared environments, expect inflated findings.
• For ML/AI stacks, cross-reference multiple advisory sources. The tensorflow GHSA count was roughly 40 (~10%) below the OSV aggregate, e.g. GHSA-24x6-8c7m-hv3f lists only tensorflow, while the PYSEC aliases also list tensorflow-gpu/-cpu. Endor says GitHub corrected these after being notified.
• Remediation planning: upgrade by bumping the version on the nearest non-vulnerable release. For transitive Java deps, override the property in dependencyManagement if the parent exposes one (Spring Boot does), otherwise declare a direct dependency at the fixed version.
• Budget for major bumps: 84% of post-2016 vulnerable spring-web versions need one (e.g. 4.3.x EOL requires 5.3.x or 6.x), whereas logback-core is mostly patch-level (1.2.9 to 1.2.13).
• Concentrate effort: updating the top 15 components removes about 74% of Python findings (Java 60%, npm 45%). Note the page gives 75%/44% in one TL;DR, so treat these as approximate.

Caveats

• All figures come from Endor's own customer base and tooling; a vendor's enrichment database is the proposed fix. The "98% noise reduction" and "<9.5% reachable" are averages over its customers, not independent benchmarks.
• Function-level reachability was not available for JavaScript at publication, so the ~4% JS prioritization figure excludes it.
• Phantom dependency shares (0-60%) come from a subset of tenants. The page elsewhere says 27% of customers have a significant footprint, with over 56% of their vulnerabilities in phantom dependencies.
• Breaking-change counts measure only removals and visibility reductions, so they flag potential breakage and do not show that a given application breaks. Endor suggests call graph and type hierarchy analysis for that.
• Dynamic installs are only detected if the code ran beforehand.
• The page lists seven languages for reachability but names eight or more.