# Vulnerable Open Source Dependencies: Counting Those That Matter

arXiv: https://arxiv.org/abs/1808.09753 · HTML: https://mlsanity.com/paper/1808.09753/

## Key facts

- Cited by 7 papers in the map (data through 14 Oct 2026).
- First posted on arXiv 29 Aug 2018.

## Built on by (most cited first, 7 of 7)

- [An Empirical Study on Using Large Language Models to Analyze Software Supply Chain Security Failures](https://mlsanity.com/paper/2308.04898/) (2023)
- [AI for DevSecOps: A Landscape and Future Opportunities](https://mlsanity.com/paper/2404.04839/) (2024)
- [MELT: Mining Effective Lightweight Transformations from Pull Requests](https://mlsanity.com/paper/2308.14687/) (2023)
- [Code Ownership in Open-Source AI Software Security](https://mlsanity.com/paper/2312.10861/) (2023)
- [Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?](https://mlsanity.com/paper/2510.08609/) (2025)
- [The Invisible Hand of AI Libraries Shaping Open Source Projects and Communities](https://mlsanity.com/paper/2601.01944/) (2026)
- [From Adoption to Deployment: A Qualitative Study on AI Integration in Software Development Practice](https://mlsanity.com/paper/2607.16660/) (2026)

## Abstract (arXiv)

BACKGROUND: Vulnerable dependencies are a known problem in today's open-source software ecosystems because OSS libraries are highly interconnected and developers do not always update their dependencies. AIMS: In this paper we aim to present a precise methodology, that combines the code-based analysis of patches with information on build, test, update dates, and group extracted from the very code repository, and therefore, caters to the needs of industrial practice for correct allocation of development and audit resources. METHOD: To understand the industrial impact of the proposed methodology, we considered the 200 most popular OSS Java libraries used by SAP in its own software. Our analysis included 10905 distinct GAVs (group, artifact, version) when considering all the library versions. RESULTS: We found that about 20% of the dependencies affected by a known vulnerability are not deployed, and therefore, they do not represent a danger to the analyzed library because they cannot be exploited in practice. Developers of the analyzed libraries are able to fix (and actually responsible for) 82% of the deployed vulnerable dependencies. The vast majority (81%) of vulnerable dependencies may be fixed by simply updating to a new version, while 1% of the vulnerable dependencies in our sample are halted, and therefore, potentially require a costly mitigation strategy. CONCLUSIONS: Our case study shows that the correct counting allows software development companies to receive actionable information about their library dependencies, and therefore, correctly allocate costly development and audit resources, which is spent inefficiently in case of distorted measurements.