No Vulnerability Data, No Problem: Towards Predicting Mean Time To Remediate In Open Source Software Dependencies

• DOI: 10.48550/arxiv.2403.17382
• Publication Date: 2024-01-01
• Authors: Rahman, Imranur; Paramitha, Ranindya; Zahan, Nusrat; Magill, Stephen; Enck, William; Williams, Laurie
• Keywords: Software Engineering (cs.SE); FOS: Computer and information sciences; D.2.8; D.2.7; Cryptography and Security (cs.CR)

Timely remediation of vulnerabilities in software dependencies is critical for the security of the software supply chain. As such, researchers have proposed tools and metrics to help practitioners assess the security practices of each of their dependencies. Conceptually, a dependency-focused Mean-Time-To-Remediate (MTTR) metric can provide a historical perspective on how long it takes a given package to update vulnerable versions of its dependencies. However, existing MTTR metrics focus on a package fixing bugs in its own code, not its dependencies. Simultaneously, existing dependency update metrics do not aggregate values for the entire package and are not sensitive to aspects important for vulnerabilities (e.g., floating version constraints). The goal of this study is to aid industry practitioners, including developers, in assessing the risk of dependencies through a novel metric approximating mean-time-to-remediate vulnerabilities in their dependencies that is evaluated by an empirical study. We propose a novel algorithm for computing MTTR called $MTTR_{dep}$ and a companion metric called $Mean-Time-To-Update_{dep}$ ($MTTU_{dep}$), which considers all version updates, including vulnerability fix updates. We conduct a large-scale study using 163, 207 packages in npm, PyPI, and Cargo, of which only 22, 513 packages produce $MTTR_{dep}$ because of the lack of vulnerability data. We further study how package characteristics (e.g., contributors and version counts) influence $MTTU_{dep}$ and $MTTR_{dep}$ and explore how long packages retain outdated vulnerable dependencies in npm, PyPI, and Cargo. Our results indicate that industry practitioners can reliably use $MTTU_{dep}$ as a proxy for $MTTR_{dep}$ when available vulnerability data is insufficient.