Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?
Not on the map. Why?
Abstract (arXiv)
Developers consistently use version constraints to specify acceptable versions of the dependencies for their project. Pinning dependencies can reduce the likelihood of breaking changes, but comes with a cost of manually managing the replacement of outdated and vulnerable dependencies. On the other hand, floating can be used to automatically get bug fixes and security fixes, but comes with the risk of breaking changes. Security practitioners advocate pinning dependencies to prevent against software supply chain attacks, e.g., malicious package updates. However, since pinning is the tightest version constraint, pinning is the most likely to result in outdated dependencies. Nevertheless, how the likelihood of becoming outdated or vulnerable dependencies changes across version constraint types is unknown. The goal of this study is to aid developers in making an informed dependency version constraint choice by empirically evaluating the likelihood of dependencies becoming outdated or vulnerable across version constraint types at scale. In this study, we first identify the trends in dependency version constraint usage and the patterns of version constraint type changes made by developers in the npm, PyPI, and Cargo ecosystems. We then modeled the dependency state transitions using survival analysis and estimated how the likelihood of becoming outdated or vulnerable changes when using pinning as opposed to the rest of the version constraint types. We observe that among outdated and vulnerable dependencies, the most commonly used version constraint type is floating-minor, with pinning being the next most common. We also find that floating-major is the least likely to result in outdated and floating-minor is the least likely to result in vulnerable dependencies.
Key facts. No citing papers in the map yet (data through 7 Oct 2026). Builds on 16 of its 55 references that are in the map. First posted on arXiv 7 Oct 2025.
Builds on
16 of 55 references.
References · 16
- 2022Taxonomy of Attacks on Open-Source Software Supply Chainscited by 57
- 2017Do Developers Update Their Library Dependencies? An Empirical Study on the Impact of Security Advisories on Library Migrationcited by 23
- 2020An Empirical Study of Usages, Updates and Risks of Third-Party Libraries in Java Projectscited by 11
- 2017Why Modern Open Source Projects Failcited by 8
- 2018Vulnerable Open Source Dependencies: Counting Those That Mattercited by 7
- 2022OpenSSF Scorecard: On the Path Toward Ecosystem-wide Automated Security Metricscited by 5
- 2023A Closer Look at the Security Risks in the Rust Ecosystemcited by 5
- 2023Empirical Analysis of Vulnerabilities Life Cycle in Golang Ecosystemcited by 5
- 2020Dependency Smells in JavaScript Projectscited by 4
- 2023On the Effect of Transitivity and Granularity on Vulnerability Propagation in the Maven Ecosystemcited by 4
- 2025Pinning Is Futile: You Need More Than Local Dependency Versioning to Defend against Supply Chain Attackscited by 4
- 2024DepsRAG: Towards Agentic Reasoning and Planning for Software Dependency Managementcited by 3
4 more
- 2023Using the Uniqueness of Global Identifiers to Determine the Provenance of Python Software Source Codecited by 2
- 2023A Large Scale Analysis of Semantic Versioning in NPMcited by 1
- 2023A Large-Scale Empirical Study on Semantic Versioning in Golang Ecosystemcited by 1
- 2024Detecting and removing bloated dependencies in CommonJS packagescited by 1
Built on by
Not cited yet.