Lags in the Release, Adoption, and Propagation of npm Vulnerability Fixes

Security vulnerabilities in third-party dependencies are a growing concern not only for developers of the affected software, but for the risks it poses to an entire software ecosystem e.g., Heartbleed vulnerability. Recent studies show that developers are slow to respond to the threat of a vulnerability, sometimes taking four to eleven months to act. To ensure quick adoption and propagation of a release that contains the fix (fixing release), we conduct an empirical investigation to identify lags that may occur between the vulnerable release and its fixing release (fixing release update}). Through a preliminary study of 131 fixing releases of npm projects on GitHub, we observe that a fixing release is rarely released on their own, with up to 92.86% of the bundled commits being unrelated to a fix. We then compare the fixing release update with changes on the client-side (client-side fixing release update). Through an empirical study of the adoption and propagation tendencies of 188 fixing releases that impact throughout a network of 882,222 npm packages, we find that stale clients require additional migration effort, even if the fixing release was quick (i.e., patch landing). Furthermore, we find that factors such as the branch that the fixing release lands on and the severity of the vulnerability influences its propagation. In addition to these lags that we identify and characterize, this paper lays the groundwork for future research on how to mitigate propagation lags in an ecosystems

[1]  Katsuro Inoue,et al.  A generalized model for visualizing library popularity, adoption, and diffusion within a software ecosystem , 2018, 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER).

[2]  David LeBlanc,et al.  Writing Secure Code , 2001 .

[3]  Rabe Abdalkareem,et al.  Why do developers use trivial packages? an empirical case study on npm , 2017, ESEC/SIGSOFT FSE.

[4]  Arie van Deursen,et al.  Tracking known security vulnerabilities in proprietary software systems , 2015, 2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER).

[5]  Fabio Massacci,et al.  Vulnerable open source dependencies: counting those that matter , 2018, ESEM.

[6]  Gabriele Bavota,et al.  How the Apache community upgrades dependencies: an evolutionary study , 2014, Empirical Software Engineering.

[7]  Eleni Constantinou,et al.  An Empirical Analysis of Technical Lag in npm Package Dependencies , 2018, ICSR.

[8]  Laurie A. Williams,et al.  Engineering Security Vulnerability Prevention, Detection, and Response , 2018, IEEE Software.

[9]  Xavier Blanc,et al.  Mining Library Migration Graphs , 2012, 2012 19th Working Conference on Reverse Engineering.

[10]  Indrajit Ray,et al.  Measuring, analyzing and predicting security vulnerabilities in software systems , 2007, Comput. Secur..

[11]  K. Pearson On the Criterion that a Given System of Deviations from the Probable in the Case of a Correlated System of Variables is Such that it Can be Reasonably Supposed to have Arisen from Random Sampling , 1900 .

[12]  Jacob Cohen Statistical Power Analysis for the Behavioral Sciences , 1969, The SAGE Encyclopedia of Research Design.

[13]  Serena Elisa Ponta,et al.  Beyond Metadata: Code-Centric and Usage-Based Analysis of Known Vulnerabilities in Open-Source Software , 2018, 2018 IEEE International Conference on Software Maintenance and Evolution (ICSME).

[14]  Chris Parnin,et al.  Can automated pull requests encourage software developers to upgrade out-of-date dependencies? , 2017, 2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE).

[15]  Fabio Massacci,et al.  An automatic method for assessing the versions affected by a vulnerability , 2015, Empirical Software Engineering.

[16]  Laurie A. Williams,et al.  An empirical model to predict security vulnerabilities using code complexity metrics , 2008, ESEM '08.

[17]  W. Kruskal,et al.  Use of Ranks in One-Criterion Variance Analysis , 1952 .

[18]  Gabriele Bavota,et al.  An Empirical Study on Android-Related Vulnerabilities , 2017, 2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR).

[19]  Andrew Meneely,et al.  Do bugs foreshadow vulnerabilities? An in-depth study of the chromium project , 2016, Empirical Software Engineering.

[20]  Arie van Deursen,et al.  Measuring software library stability through historical version analysis , 2012, 2012 28th IEEE International Conference on Software Maintenance (ICSM).

[21]  Tobias Lauinger,et al.  Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web , 2018, NDSS.

[22]  James D. Herbsleb,et al.  How to break an API: cost negotiation and community values in three software ecosystems , 2016, SIGSOFT FSE.

[23]  Georgios Gousios,et al.  Structure and Evolution of Package Dependency Networks , 2017, 2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR).

[24]  Eleni Constantinou,et al.  On the Impact of Security Vulnerabilities in the npm Package Dependency Network , 2018, 2018 IEEE/ACM 15th International Conference on Mining Software Repositories (MSR).

[25]  Romain Robbes,et al.  How do developers react to API deprecation?: the case of a smalltalk ecosystem , 2012, SIGSOFT FSE.

[26]  Tom Mens,et al.  An empirical comparison of dependency issues in OSS packaging ecosystems , 2017, 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER).

[27]  Mohammad Zulkernine,et al.  Using complexity, coupling, and cohesion metrics as early indicators of vulnerabilities , 2011, J. Syst. Archit..

[28]  Marko C. J. D. van Eekelen,et al.  Measuring Dependency Freshness in Software Systems , 2015, 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering.

[29]  Hirohiko Suwa,et al.  Understanding When to Adopt a Library: A Case Study on ASF Projects , 2017, OSS.