Pinning Is Futile: You Need More Than Local Dependency Versioning to Defend against Supply Chain Attacks

TL;DR

The paper quantitatively analyzes the security and maintenance effects of dependency versioning in the npm ecosystem, focusing on pinning versus floating. Using counterfactual time-travel dependency resolution and ecosystem-wide simulations, it finds that pinning direct dependencies can increase the attack surface and maintenance burden for large graphs, challenging the assumption that pinning improves security. It further demonstrates that coordinated, ecosystem-level pinning—especially transitive pinning of upstream packages—can substantially reduce the risk of malicious package updates, suggesting concrete npm tooling changes and governance approaches. The work provides practitioners and researchers with evidence-based guidance for more secure software supply chains and opens avenues for cross-ecosystem validation and policy development.

Abstract

Recent high-profile incidents in open-source software have greatly raised practitioner attention on software supply chain attacks. To guard against potential malicious package updates, security practitioners advocate pinning dependency to specific versions rather than floating in version ranges. However, it remains controversial whether pinning carries a meaningful security benefit that outweighs the cost of maintaining outdated and possibly vulnerable dependencies. In this paper, we quantify, through counterfactual analysis and simulations, the security and maintenance impact of version constraints in the npm ecosystem. By simulating dependency resolutions over historical time points, we find that pinning direct dependencies not only (as expected) increases the cost of maintaining vulnerable and outdated dependencies, but also (surprisingly) even increases the risk of exposure to malicious package updates in larger dependency graphs due to the specifics of npm's dependency resolution mechanism. Finally, we explore collective pinning strategies to secure the ecosystem against supply chain attacks, suggesting specific changes to npm to enable such interventions. Our study provides guidance for practitioners and tool designers to manage their supply chains more securely.

Figures (7)

• Figure 1: The distribution of version constraint types and project-level versioning strategies in each year in the dataset we use for answering RQ1 (see Section \ref{['sec:data-collection']} for details) - we observe that after years of increasing floating adoption, since about 2020 the trend reverses with a shift toward pinning. In Figure \ref{['fig:versioning']}, we ignore non-floating/pinning version constraints as they only occupy 0.83% of version constraints in our dataset.
• Figure 2: An example package.jsonfile. We modified version constraints in the original file to illustrate different types of version constraints defined in Section \ref{['sec:method-rq1']}. Other details irrelevant to this paper are omitted.
• Figure 3: An illustration of the trade-off between cost and risk after pinning.
• Figure 4: The effect of pinning direct dependencies on malicious package update attack surface (as measured by the number of floating dependencies in the entire dependency graph). Our model shows that pinning reduces attack surface for small dependency graphs, but the positive effect decreases as the dependency graphs grow larger and even flips to negative for dependency graphs with more than 498 dependencies.
• Figure 5: Examples to illustrate attack impact computation and how local/transitive pinning works.