Table of Contents
Fetching ...

Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?

Imranur Rahman, Jill Marley, William Enck, Laurie Williams

TL;DR

This paper addresses how dependency version constraints—specifically pinning versus floating—influence the likelihood of dependencies becoming outdated or vulnerable in npm, PyPI, and Cargo. It adopts an empirical, large-scale approach, collecting package metadata and security advisories from deps.dev and OSV, respectively, and uses time-varying Cox proportional hazards models to estimate hazard ratios across constraint types. The study reveals that floating-minor is most common in several ecosystems and that pinning tends to produce more outdated dependencies, while floating-minor generally lowers vulnerability risk; however, vulnerability fixes are not always propagated across major versions, complicating assumptions about floating strategies. The findings support recommending automated updates and lockfiles, with nuanced guidance on when to apply floating Major/Minor/Patch constraints, and offer practical, cross-ecosystem insights for developers and tool builders to manage dependencies more securely and efficiently.

Abstract

Developers consistently use version constraints to specify acceptable versions of the dependencies for their project. \emph{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, \emph{floating} can be used to automatically get bug fixes and security fixes, but comes with the risk of breaking changes. Security practitioners advocate \emph{pinning} dependencies to prevent against software supply chain attacks, e.g., malicious package updates. However, since \emph{pinning} is the tightest version constraint, \emph{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 \emph{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 \emph{floating-minor}, with \emph{pinning} being the next most common. We also find that \emph{floating-major} is the least likely to result in outdated and \emph{floating-minor} is the least likely to result in vulnerable dependencies.

Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?

TL;DR

This paper addresses how dependency version constraints—specifically pinning versus floating—influence the likelihood of dependencies becoming outdated or vulnerable in npm, PyPI, and Cargo. It adopts an empirical, large-scale approach, collecting package metadata and security advisories from deps.dev and OSV, respectively, and uses time-varying Cox proportional hazards models to estimate hazard ratios across constraint types. The study reveals that floating-minor is most common in several ecosystems and that pinning tends to produce more outdated dependencies, while floating-minor generally lowers vulnerability risk; however, vulnerability fixes are not always propagated across major versions, complicating assumptions about floating strategies. The findings support recommending automated updates and lockfiles, with nuanced guidance on when to apply floating Major/Minor/Patch constraints, and offer practical, cross-ecosystem insights for developers and tool builders to manage dependencies more securely and efficiently.

Abstract

Developers consistently use version constraints to specify acceptable versions of the dependencies for their project. \emph{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, \emph{floating} can be used to automatically get bug fixes and security fixes, but comes with the risk of breaking changes. Security practitioners advocate \emph{pinning} dependencies to prevent against software supply chain attacks, e.g., malicious package updates. However, since \emph{pinning} is the tightest version constraint, \emph{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 \emph{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 \emph{floating-minor}, with \emph{pinning} being the next most common. We also find that \emph{floating-major} is the least likely to result in outdated and \emph{floating-minor} is the least likely to result in vulnerable dependencies.

Paper Structure

This paper contains 27 sections, 3 figures, 6 tables.

Figures (3)

  • Figure 1: Taxonomy of version constraint types with examples.
  • Figure 2: Spectrum of version constraint types.
  • Figure 3: Illustration of dependency state transition using hexo's dependency relationship with moment. Green time quantum indicates 'yes', and red time quantum indicates 'no' in both 'updated?' and 'remediated?' axis.