The Devils in the Dependency Data Driven Software Composition Analysis

## Overview

Chris Eng (Chief Research Officer, Veracode) and Ben (Senior Data Scientist, Scientia) presented quantitative findings on open-source library usage and inherited vulnerability risk from the Veracode State of Software Security report. The report analyzes 12 months of anonymized customer data covering 85,000 unique applications and 351,000 unique libraries—described as "the largest known quantitative study of application security findings"—to expose patterns that challenge conventional appsec wisdom. Core thesis: open-source libraries are "free as in puppy" (developers inherit both functionality and vulnerabilities); however, raw library counts don't directly predict vulnerability burden. The presentation reveals counterintuitive findings: tiny libraries (162 lines of code) can introduce critical flaws; most libraries are indirect transitive dependencies developers never deliberately included; vulnerability severity alone is poor fix prioritization; and 81% of patchable vulnerabilities require only minor version updates.

## Library Usage Patterns: Direct vs. Transitive Dependencies and Language Ecosystems

**Library Distribution by Language**: JavaScript ecosystem stands as outlier with median applications including hundreds of libraries and 90th percentile reaching thousands. Python, Java, and C# typically include dozens of libraries. This reflects ecosystem culture: JavaScript/Ruby emphasize small single-purpose packages (one function per library), while Python/Java/C# favor larger monolithic libraries bundling related functionality. Both approaches carry distinct risk profiles.

**Transitive Dependency Chains**: Most included libraries are NOT directly imported by developers; instead, A depends on B which depends on C. Developers often remain unaware of deep transitive dependency trees, creating invisible attack surface. This layered inclusion means a 162-line utility library can propagate into thousands of applications indirectly, and vulnerabilities in deep dependencies bypass developer awareness.

**Popularity Concentration**: Some JavaScript libraries achieve >90% inclusion rate across all scanned applications (essentially ubiquitous). Vulnerability discovery in high-popularity libraries simultaneously impacts massive portion of ecosystem. Conversely, many libraries serve only 1-10% of applications, concentrating exploit risk to smaller populations. Popularity distribution is heavily right-skewed with few libraries reaching widespread adoption.

**Library Flaw Correlation**: Veracode's data scoring marks libraries on a gradient (dark blue = no known flaws, gray-blue = some flaws reported, light blue = proof-of-concept exploits exist, yellow = wild exploitation observed). Higher popularity does NOT correlate with fewer flaws; some ubiquitous libraries carry known vulnerabilities; some niche libraries remain unvetted. Popularity is independent of security maturity.

## Vulnerability Prioritization and Update Chain Analysis

**Severity Insufficient for Prioritization**: Raw CVE severity scores (CVSS) fail to predict actual risk to specific applications. A critical-severity vulnerability in an unused library poses zero risk; a low-severity flaw in a core library threatens entire applications. Patch prioritization must weigh: (1) vulnerability exploitability in context (does attacker reach this code path?), (2) library criticality to application (is it loaded in attack surface?), (3) blast radius (does patching break dependent code?).

**Update Chain Dependencies**: Patching one library frequently introduces new vulnerabilities in the updated version, creating patch chains. Example: Library A v1.0 has CVE-X; updating to v1.1 patches CVE-X but introduces CVE-Y; then v1.2 required to patch CVE-Y. Analysis shows 81% of patchable vulnerabilities can be resolved with minor version updates (semantic versioning patch/minor bumps), but these updates occasionally carry new CVE introductions, requiring planning cycles. Most updates remain small despite new vulnerabilities appearing, enabling rapid re-patching rather than blocking major-version overhauls.

**Data-Driven Prioritization Beyond Severity**: Veracode recommends multi-dimensional prioritization considering library popularity (more users = higher priority), update availability and scope (minor vs. major versions), downstream dependent count (how many libraries depend on this one), and attacker incentive (is library attack-worthy). These factors reveal that applications with hundreds/thousands of libraries can prioritize fixes without patching everything, focusing on heavily-depended-upon libraries first.