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
View on arXiv