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

TL;DR

This study analyzes the effectiveness of dependency pinning in open-source software supply chain security, revealing that pinning may not always reduce risk and can increase exposure due to npm's dependency resolution mechanics.

Contribution

It provides a counterfactual analysis of pinning's security impact in npm, highlighting potential drawbacks and proposing strategies for more effective supply chain defense.

Findings

Pinning increases maintenance costs and vulnerability exposure.

Dependency resolution mechanics can cause pinning to increase attack surface.

Collective pinning strategies can enhance supply chain security.

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.