Abstract
AbstractSecurity vulnerability in third-party dependencies is 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 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 (package-side fixing release). Through a preliminary study of 231 package-side fixing release of npm projects on GitHub, we observe that a fixing release is rarely released on its own, with up to 85.72% of the bundled commits being unrelated to a fix. We then compare the package-side fixing release with changes on a client-side (client-side fixing release). Through an empirical study of the adoption and propagation tendencies of 1,290 package-side fixing releases that impact throughout a network of 1,553,325 releases of npm packages, we find that stale clients require additional migration effort, even if the package-side fixing release was quick (i.e., package-side fixing releasetypeSpatch). Furthermore, we show the influence of factors such as the branch that the package-side fixing release lands on and the severity of vulnerability on its propagation. In addition to these lags we identify and characterize, this paper lays the groundwork for future research on how to mitigate propagation lags in an ecosystem.
Publisher
Springer Science and Business Media LLC
Reference57 articles.
1. Abdalkareem R, Nourry O, Wehaibi S, Mujahid S, Shihab E (2017) Why Do Developers Use Trivial Packages? An Empirical Case Study on npm. In: Proceedings of the 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE), pp 385–395
2. Alhazmi O H, Malaiya Y K, Ray I (2007) Measuring, analyzing and predicting security vulnerabilities in software systems. Comput Secur 26(3):219–228
3. Bavota G, Canfora G, Di Penta M, Oliveto R, Panichella S (October 2015) How the Apache Community Upgrades Dependencies: An Evolutionary Study. Empir Softw Eng (EMSE) 20(5):1275–1317
4. Bennett J T (2014) Shellshock in the Wild - Shellshock in the Wild. https://www.fireeye.com/blog/threat-research/2014/09/shellshock-in-the-wild.htmlhttps://www.fireeye.com/blog/threat-research/2014/09/shellshock-in-the-wild.html. (Accessed on 02/08/2021)
5. Bogart C, Kästner C, Herbsleb J, Thung F (2016) How to Break an API: Cost Negotiation and Community Values in Three Software Ecosystems. In: Proceedings of the 24th International Symposium on the Foundations of Software Engineering (FSE), pp 109–120
Cited by
36 articles.
订阅此论文施引文献
订阅此论文施引文献,注册后可以免费订阅5篇论文的施引文献,订阅后可以查看论文全部施引文献
1. Silent Taint-Style Vulnerability Fixes Identification;Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis;2024-09-11
2. See to Believe: Using Visualization to Motivate Updating Third-Party Dependencies;2024 21st International Joint Conference on Computer Science and Software Engineering (JCSSE);2024-06-19
3. Keep Me Updated: An Empirical Study on Embedded Javascript Engines in Android Apps;Proceedings of the 21st International Conference on Mining Software Repositories;2024-04-15
4. Empirical Analysis of Vulnerabilities Life Cycle in Golang Ecosystem;Proceedings of the IEEE/ACM 46th International Conference on Software Engineering;2024-04-12
5. BUMP: A Benchmark of Reproducible Breaking Dependency Updates;2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER);2024-03-12