Source-linked AI summary
What are Weak Links in the npm Supply Chain?
Nusrat Zahan, Thomas Zimmermann, Patrice Godefroid, Brendan Murphy, Chandra Maddila, Laurie Williams
TL;DR
Third-party packages and npm’s centralized ecosystem create a need to identify package-level weak links before attackers exploit them. The paper analyzes npm metadata to propose and evaluate six signals, finding evidence for expired maintainer domains, install scripts, and unmaintained packages as actionable concerns.
Problem
Third-party package use and recurring supply-chain attacks create a need for proactive evidence about npm package vulnerability to high-risk attacks.
Method
The study analyzes metadata from 1.63 million npm packages, proposes six weak-link signals, and surveys 470 npm package developers about them.
Results
2,818 maintainer domains were available for purchase, affecting 8,494 packages; more than 50% of practitioners supported expired domains, install scripts, and unmaintained packages.
Takeaways & Limitations
Practitioners supported three of six signals and wanted notification about weak-link signals before using third-party packages.
Takeaways & Limitations
Three signals involving maintainer and contributor activity were difficult to evaluate because npm lacked sufficient maintainer-activity metadata, and the study covered only npm.
Abstract
from arXiv · showhide
Modern software development frequently uses third-party packages, raising the concern of supply chain security attacks. Many attackers target popular package managers, like npm, and their users with supply chain attacks. In 2021 there was a 650% year-on-year growth in security attacks by exploiting Open Source Software's supply chain. Proactive approaches are needed to predict package vulnerability to high-risk supply chain attacks. The goal of this work is to help software developers and security specialists in measuring npm supply chain weak link signals to prevent future supply chain attacks by empirically studying npm package metadata. In this paper, we analyzed the metadata of 1.63 million JavaScript npm packages. We propose six signals of security weaknesses in a software supply chain, such as the presence of install scripts, maintainer accounts associated with an expired email domain, and inactive packages with inactive maintainers. One of our case studies identified 11 malicious packages from the install scripts signal. We also found 2,818 maintainer email addresses associated with expired domains, allowing an attacker to hijack 8,494 packages by taking over the npm accounts. We obtained feedback on our weak link signals through a survey responded to by 470 npm package developers. The majority of the developers supported three out of our six proposed weak link signals. The developers also indicated that they would want to be notified about weak links signals before using third-party packages. Additionally, we discussed eight new signals suggested by package developers.
1 INTRODUCTION
Third-party package ecosystems create expanding opportunities for supply-chain attacks, motivating proactive identification of npm weak-link signals. This paper empirically studies npm metadata, proposes six signals, and evaluates practitioner agreement with them.
- 96% of applications use third-party packages, with third-party packages comprising 80% of software supply-chain code.
- Attackers can inject malicious updates into benign packages and exploit package metadata to find weak links before rapidly distributing malware.
- 650% year-on-year growth in supply-chain attacks was reported for 2021, after 430% growth in 2020.
- The study analyzes 1.63 million npm packages to quantify and prioritize six weak-link signals for developers and security specialists.
- A survey of 470 npm package maintainers confirmed three proposed signals as strong signals, while participants suggested eight additional signals.
2 BACKGROUND AND RELATED WORK
npm automates package publishing, installation, and dependency management, but its nested dependency structure expands the attack surface. Prior defenses focused on known malicious instances, motivating broader approaches to anticipate unseen weak links and attack vectors.
- A software supply-chain attack targets less-secure components to infect organizations and end users across development, CI/CD, and deployment.
- Nested direct and transitive dependencies mean a single package can dramatically increase a system’s attack surface.
- npm hosts JavaScript packages and uses package.json metadata to manage installation and project dependencies.
- Attack vectors include malicious package releases, social engineering, and maintainer account takeover.
- Prior approaches often target specific observed attacks, whereas recurring out-of-the-box exploit strategies motivate methods that address attacks not yet witnessed.
3 RQ1: WEAK LINK SIGNALS
The paper operationalizes six npm supply-chain weak-link signals from package metadata and quantifies their potential exposure across the registry. Results highlight installation scripts, inactive packages and maintainers, overloaded maintainers, and expired maintainer domains as measurable risk indicators.
- Signal definition: The study defines a weak link as metadata exposing a package to higher supply-chain attack risk that an attacker can exploit.The analysis follows an attacker-oriented path-of-least-resistance approach, while noting that a single signal may not accurately estimate application impact.
- W2: Installation Script: 2.2% (33,249) of packages used install scripts, while 93.9% (3,412) of malicious packages had at least one install script.The study identified package behaviors including third-party data transfer, malicious-tool downloads, reverse shells, and directory removal.
- W3: Unmaintained Package: 58.7% of packages and 44.3% of maintainers were inactive, with 5,532 additional deprecated packages beyond the threshold.Unmaintained or deprecated packages may remain unfixed while vulnerabilities affect applications that depend on them directly or transitively.
- W6: Overloaded Maintainer: Top 1% maintainers owned an average of 180.3 packages with 4,010 average direct dependents, while 70% held inactive packages and 80% of packages had dependencies.The study treats concentrated ownership and downstream dependency responsibility as reasons to place overloaded maintainers on a security radar.
4 CASE STUDY
The case studies quantify weak-link signals among popular npm packages, identify malicious packages through install-script analysis, and illustrate how attackers can combine signals to target packages.
- Case study #1: Popular packages: 14,892 popular packages were analyzed to quantify weak-link signals, using package reach based on dependents and downloads.The sample represented 1% of all packages, with averages of 937.4 dependents and 88.5 million downloads over 12 months.
- Case study #1: Popular packages: 362 popular packages had install scripts, exposing 1,416 packages on average to potential attacks through those scripts.The analysis reported that 97.5% of popular packages avoided install scripts.
- Case study #1: Popular packages: 38% (5,645) of popular packages were inactive, including 560 deprecated packages, while 645 lacked active maintainers.Inactive packages had an average of 422.4 direct dependents, and 619 inactive maintainers still owned 645 popular packages.
- Case study #1: Popular packages: 2,491 overloaded maintainers owned 9,871 popular packages, while 23 packages had an average maintainer-to-contributor ratio of 1:37.The 9,871 packages represented 66.3% of popular packages; the 23 packages averaged 6,458.04 direct dependents and 64.2 million downloads.
- Case study #2: Installation scripts: 11 malicious packages were identified among 74 packages whose installation scripts contained keywords such as curl, wget, /etc/shadow, or /etc/passwd.npm security specialists later identified 10 of the 11 packages as malicious, and the remaining package was reported to npm.
- Case study #3: Data-Driven Attacker: Combining expired-domain and unmaintained-package signals allowed an attacker to identify 15 available domains and potentially reset accounts controlling 899 npm packages.The attack scenario used package metadata to find 5,645 unmaintained packages and 1,108 maintainer email addresses before checking domain availability.
5 RQ2: SURVEY
The survey examined practitioner perceptions of six proposed npm weak-link signals and their desire for notifications. Maintainers supported three signals, rejected three others, and suggested additional signals and repository-related checks.
- Practitioners wanted notifications about weak-link signals, with notification interest exceeding direct agreement for W2 and W3.
- More than 50% of practitioners supported W1 (Expired Maintainer Domain), W2 (Install Scrips) and W3 (Unmaintained Packages) as weak link signals.
- More than 40% disagreed with W4 (Total Number of Maintainers), W5 (Maintainer to contributors ratio) and W6 (Packages per maintainer), while fewer than 20% supported them.
- 41 practitioners mentioned maintainers as a risk, contributing to four proposed maintainer-related signals.
- Practitioners treated maintainer identity, expertise, and two-factor authentication as additional security considerations.
- 52 (24.4%) of responses concerned version control software, package repository, and npm integration.
- Practitioners identified absent or archived source repositories and mismatches between npm packages and repositories as concerns, although repository signals were excluded from this metadata-only study.
6 LIMITATIONS
The study’s limitations concern incomplete maintainer metadata, the absence of repository-related signals, and evaluation restricted to the npm ecosystem.
- W4 (Too many Maintainers), W5 (Too many Contributors), and W6 (Overloaded Maintainer) were difficult to evaluate because maintainer-activity metadata was insufficient.
- The study analyzed only the npm ecosystem and did not evaluate other package-manager ecosystems.
7 DISCUSSION
The discussion frames weak-link signals as inputs to proactive npm supply-chain security practices. It proposes risk scoring, package validation, and security grading while acknowledging implementation difficulty.
- The study aims to increase awareness and visibility of weak-link signals, while not providing a complete mitigation solution.
- Weak-link signals could support estimating security risk because npm lacks an overall package health or security score.
- npm could validate new releases against a risk model before publishing them to users.
- Practitioners suggested security grades and recommendation systems, although grading the ecosystem would be difficult and expensive.
8 SUMMARY
The paper presents a framework for prioritizing and quantifying npm supply-chain weak links and reports additional practitioner-proposed signals. It positions the work as an ongoing investigation rather than a complete solution.
- The framework helps prioritize and quantify weak-link signals in the npm supply chain.
- The authors submitted suspicious packages to the npm security team for actions including taking over packages from inactive maintainers and freezing maintainer accounts.
- The survey produced a list of new weak-link signals proposed by npm practitioners.