Source-linked AI summary
Do Developers Update Their Library Dependencies? An Empirical Study on the Impact of Security Advisories on Library Migration
Raula Gaikovina Kula, Daniel M. German, Ali Ouni, Takashi Ishio, Katsuro Inoue
TL;DR
The paper asks whether developers update evolving and vulnerable third-party library dependencies and why security advisories may not prompt migration. It conducts a large empirical study with developer feedback, finding that outdated dependencies are common and advisory responses are limited. The authors conclude that dependency updating is not common for many developers despite widespread third-party reuse.
Problem
The paper investigates whether developers update third-party library dependencies and how aware they are of migration opportunities, which matters because dependencies evolve and vulnerabilities require attention.
Method
The study empirically tracks library migrations across projects and libraries, analyzes awareness mechanisms, and surveys affected developers about vulnerable dependencies.
Results
81.5% of studied systems retain outdated dependencies, while 69% of surveyed affected developers report being unaware of their vulnerable dependency.
Takeaways & Limitations
Dependency updating is not common for many developers, and migration decisions reflect awareness, effort, dependency priority, and assigned responsibilities.
Takeaways & Limitations
The findings may not generalize to Java projects without dependency-management tools or to other library ecosystems such as JavaScript npm and RubyGems.
Abstract
from arXiv · showhide
Third-party library reuse has become common practice in contemporary software development, as it includes several benefits for developers. Library dependencies are constantly evolving, with newly added features and patches that fix bugs in older versions. To take full advantage of third-party reuse, developers should always keep up to date with the latest versions of their library dependencies. In this paper, we investigate the extent of which developers update their library dependencies. Specifically, we conducted an empirical study on library migration that covers over 4,600 GitHub software projects and 2,700 library dependencies. Results show that although many of these systems rely heavily on dependencies, 81.5% of the studied systems still keep their outdated dependencies. In the case of updating a vulnerable dependency, the study reveals that affected developers are not likely to respond to a security advisory. Surveying these developers, we find that 69% of the interviewees claim that they were unaware of their vulnerable dependencies. Furthermore, developers are not likely to prioritize library updates, citing it as extra effort and added responsibility. This study concludes that even though third-party reuse is commonplace, the practice of updating a dependency is not as common for many developers.
1 Introduction
The paper examines how developers migrate third-party library dependencies as libraries evolve and vulnerabilities emerge. Its empirical study finds that dependency updating is uncommon, including after security advisories, and identifies awareness, priority, and responsibility as influencing factors.
- Migration decisions: Developers weigh new features, compatibility, usage, documentation, support, and longevity when deciding whether to migrate.Vulnerable dependencies are described as requiring an immediate response because they expose applications to malicious attacks.
- Study focus: 4,659 projects are analyzed to investigate library migration and developer responsiveness to migration opportunities.The study combines empirical tracking, case studies, and a developer survey.
- Library migration in practice: 81.5% of studied systems keep outdated library dependencies.The paper reports that developers are less likely to migrate their dependencies.
- Security advisories: Developers are nonresponsive to security advisories, and 69% of surveyed affected developers report being unaware of the vulnerability.Those developers subsequently migrated away from the vulnerable dependency.
- Contributions: The paper contributes a system- and library-oriented migration model, Library Migration Plots, and a dataset of 852,322 dependency migrations.Tools and data are publicly available through the replication package.
2 Basic Concepts & Definitions
The paper defines library migration as replacing a dependency with a newer version or another library and describes how release announcements and security advisories create migration awareness. Migration proceeds from awareness and replacement selection through migration effort to adoption.
- Migration process: Developers first become aware of a migration opportunity and identify a suitable replacement, including a patched version for vulnerable dependencies.This is the first generic step in the migration process.
- Migration process: After migration effort is completed, the prior dependency is abandoned and the replacement library is adopted by the system.The supplied process description places adoption after the effort phase.
- Awareness mechanisms: New release announcements use official library announcements, change logs, and semantic versioning to signal available updates and estimate migration effort.Change logs describe API changes, features, and bug fixes; major releases may require more effort than minor releases.
- Awareness mechanisms: A security advisory is an official public announcement of a verified vulnerable dependency circulated through mailing lists and security forums.The vulnerability lifecycle includes threat detection, CVE assessment, public disclosure, and patch release.
- Awareness mechanisms: A replacement dependency can become available before public disclosure, allowing migration before the security advisory appears.The vulnerability lifecycle and migration process are not always synchronized.
3 Research Questions
The study asks how extensively developers update dependencies, how they respond to release announcements and security advisories, and why they may not respond to security advisories. These questions address outdated libraries, awareness mechanisms, and developer decision factors.
- Motivation: The motivation includes widespread outdated and vulnerable libraries, including more than 6% of Maven Central download requests involving known vulnerabilities in 2014.The study also cites high-profile vulnerabilities such as Heartbleed, Poodle, and Shellshock.
- Library Migration in Practice: RQ1 asks: To what extent are developers updating their library dependencies?This question targets library migration in practice.
- Developer Responsiveness to Awareness Mechanisms: RQ2 asks how developers respond to new release announcements and security advisories on library updates.The study focuses on maintainer responsiveness to both awareness mechanisms.
- Developer Responsiveness to Awareness Mechanisms: RQ3 asks why developers are nonresponsive to a security advisory.The question follows prior findings that developer responsiveness to library updates is slow and lagging.
4 Research Methods
The study models library migration by tracking dependency relations and updates across systems and libraries, then analyzes migration with system- and library-level metrics. It also uses Library Migration Plots and documentation to examine responses to releases and security advisories.
- Study design: The study reconstructs historical library migrations by mining real-world projects, analyzing release and vulnerability case studies, and interviewing developers with vulnerable dependencies.RQ1 uses mined migration histories, RQ2 analyzes case studies, and RQ3 interviews affected developers.
- Dependency model: A dependency relation is created when a system version adopts a specific version of a library.The notation distinguishes systems S(sys,w), libraries L(lib,v), and their version-specific dependency relation.
- System metrics: Dependency Update (DU) counts the library migrations occurring during one system-version update.The model illustrates DU=1 when a system update adds a new dependency while retaining another dependency.
- Library metrics: Library Usage (LU) is the number of dependent systems at a given time, supporting analysis of usage trends and migration away from libraries.The library dimension examines whether usage is gaining or declining and how quickly decline occurs after migration begins.
- Library metrics: The library dimension measures peak and current LU, time before and after peak usage, and Library Residue.Library Residue is Current LU / Peak LU; the example reports 40% (2/5) and associates low residue with considering migration to a replacement.
- Case-study analysis: Library Migration Plots show LU against time, while release documentation and advisory information help quantify trends and estimate migration effort.The plot is visually analyzed with LU metrics; documentation, release notes, semantic versioning, and vulnerability life-cycle information inform effort estimates.
5 Library Migration in Practice
The study finds that systems depend heavily on libraries but update them infrequently, leaving most dependencies outdated. Library usage often peaks slowly, and popular libraries retain substantial user residue.
- System Dimension: Systems average 147 dependencies but only 1 dependency update, indicating heavy reliance alongside infrequent maintenance.The reported dependency statistics are x̄=147, μ=267.2, σ=311.56, while dependency updates are x̄=1 and μ=2.4.
- Library Dimension: 75% of popular libraries reach a peak library usage of 12, while 596 libraries show no migration.For those 596 libraries, peak library usage equals current library usage.
- Library Dimension: Most of the 2,736 dependencies exhibit high library residue, averaging 85.7% with a median of 81.5%.The distribution has σ=22.2%; log4j 1.2.15 is cited as an example with 98% residue.
- Library Dimension: Higher-peaking, more popular libraries tend to retain more users, even when newer versions are available.The study links popularity, measured through higher peak usage, with higher library residue.
6 Developer Responsiveness to Awareness Mechanisms
Developer responses to new releases and security advisories vary: some migrations are consistent, while older popular versions may remain preferred. Migration effort, incomplete patches, latent disclosures, and limited awareness help explain non-response.
- A New Release Announcement: Google Guava shows consistent migration across releases despite library residue of 60.4% and 85%.The successive versions have peak library usage values of 48 and 49.
- A New Release Announcement: Developers avoid some newer releases when migration requires substantial platform or architectural changes.Junit 4.10 and 4.11 require Java 5 or higher, while junit 3.8.1 retains peak usage of 342; log4j 1.2.16 also remains more popular than a superseding release.
- Security Advisory Disclosure: A timely patched release can trigger migration after a vulnerability disclosure, as observed for the V1 advisory.The patched L(V1,1.9.1) was released shortly after the advisory, followed by a usage peak and decline.
- Security Advisory Disclosure: For V2, vulnerable versions retained high residue—98% for L(V2,1.2.2) and 86% for L(V2,1.3)—despite advisory-triggered migration.The newer dependency required Java 5 or higher, increasing estimated migration effort.
- Security Advisory Disclosure: Some developers did not respond because a replacement dependency involved major architectural changes or was unavailable.The commons-httpclient successor, Httpcomponents, is described as a major upgrade; many users continued using older versions after release.
- Security Advisory Disclosure: Some affected developers had already migrated before disclosure, producing no visible response to the advisory.This latent-advisory pattern is reported for the vulnerable httpcomponents dependency V4.
- Developer Feedback: Among 16 survey responses, 11 developers, or 69%, were unaware of the vulnerability and immediately updated to safer versions.The responses followed notification by the researchers.
- Developer Feedback: Developers weigh vulnerability impact and dependency function when deciding whether an update is necessary.Projects described as inactive, halted, or using vulnerabilities in low-impact components were less motivated to update.
7 Discussion
The discussion interprets library updating as a cost–benefit decision shaped by dependency complexity, migration effort, awareness, and competing responsibilities. It also identifies validity threats related to measurement, response rates, project selection, and generalization beyond Java dependency-managed projects.
- Implications of Results: Dependency hell increases the migration effort required to update dependencies within projects’ complex inter-dependencies.The study frames updating as a cost–benefit decision involving migration effort and replacement benefits.
- Implications of Results: Developer feedback characterizes library migration as low-priority extra work performed in spare time.The discussion speculates that staff responsibility overload and limited motivation may also influence update decisions.
- Threats to Validity: The study’s awareness analysis focuses on new releases and security advisories, excluding other mechanisms such as social-media alerts and word of mouth.The authors describe these as traditional and recognized announcement forms and suggest investigating other awareness mechanisms.
- Threats to Validity: The dependency extraction assumes Maven configuration declarations, so manually embedded or otherwise undocumented dependencies may be missed.PomWalker specifically detects documented dependency declarations, including implicit version references and managed dependencies.
- Threats to Validity: A 25% response rate from contactable projects may not represent all developers, although the authors regard it as adequate for a targeted interest group.This threat affects the research method and interpretation of developer responses for RQ3.
- Threats to Validity: The findings may not generalize to Java projects without dependency-management tools, all Java projects, or other ecosystems such as npm and RubyGems.The authors restrict their conclusions to the studied Java setting and note that other ecosystems may exhibit different migration patterns.
8 Related Work
Related work studies library migration, ecosystem dynamics, popularity, update patterns, and migration-support tools. This paper examines migration in the Maven Java ecosystem using real-world GitHub clients, with particular attention to vulnerabilities and migration extent.
- API Library Updates: Prior API-level studies examined library popularity, migration patterns, usage trends, and recommendations inferred from migration behavior.The paper distinguishes its motivation by emphasizing how much migration occurs and its relationship to vulnerabilities.
- API Library Updates: Empirical work on Maven repositories connected library popularity and usage with system properties, semantic versioning, breakages, and library updates.The cited studies provide broader evidence on dependency behavior in repository ecosystems.
- Library Usage as Popularity Measures: Library usage metrics and Library Migration Plots represent popularity measures across system and library dimensions.Related work similarly uses visualized library usage to study stability, popularity, and safe adoption.
- Library Migration Support: Migration-support research includes change specification languages, imperfect change rules, automatic tools, code-clone analysis, origin analysis, and reuse tracking.These approaches primarily support code transformation, candidate selection, or recovery of change context.
- Library Migration Support: Earlier migration-support tools often omit broader migration concerns, while related work identifies impact assessment, migration effort, and customer issues in vulnerable-library updates.The paper connects these concerns to maintainers’ reluctance to update libraries exposed to malicious attacks.
- Software Systems as Ecosystems: This study analyzes the Maven Java ecosystem through diverse real-world GitHub projects rather than narrowly defined Apache and Eclipse ecosystems.Its clients are described as “wild” projects distributed across GitHub repositories.
9 Conclusion
The study concludes that third-party reuse is widespread but dependency updating is not regularly practiced, including for vulnerability fixes. It attributes update decisions to migration effort, developer awareness, competing responsibilities, and motivation, and proposes visual aids and further study to improve update perceptions.
- Conclusion: 81.5% of studied systems remain on outdated dependencies despite widespread third-party library use.The conclusion states that dependency updates are especially uncommon when intended to fix vulnerabilities.
- Conclusion: Migration effort, including rework, platform preparation, and API changes, plays an important role in update decisions.The conclusion also cites developer awareness, added responsibility, spare-time effort, staff overload, and motivation as influencing factors.
- Conclusion: The study motivates strategies to improve developers’ perceptions of third-party updates when effort is needed to mitigate severe vulnerability risks.This is presented as a direction for the research community rather than a demonstrated intervention outcome.
- Conclusion: Library Migration Plots may provide visual analysis that supports developer awareness and motivation for faster updating.The paper identifies further exploration of migration effort and update responsibilities as future work.