DEV Community: Manuel

Supply Chain Attacks on the Web – 10 Ways to Prevent Attacks in the npm Ecosystem

Manuel — Fri, 28 Aug 2026 15:25:09 +0000

Hint: This post is also available in German 🇩🇪.

2026 finds itself even more heavily overshadowed by far-reaching supply chain attacks (SCAs) than the year before. To put it bluntly, not a day goes by without a new report surfacing in software development circles about yet another infected software package capable of compromising one’s own solutions and infrastructure. An SCA, essentially being targeted by malicious actors through third-party dependencies with little to no direct fault of your own, was, just a few years ago, considered a rather theoretical and marginal phenomenon. Today, however, the issue has evolved into an omnipresent and serious threat in the software industry.

This trend is, for example, highlighted in a report published by Sonatype (Figure 1). The graph illustrates the growth of malicious software packages discovered by Sonatype – from the start of record-keeping in 2019 through 2025. 2025 ended with over 1.2 million detected packages – each one representing a separate opportunity to unintentionally infect a victim’s system.

Figure 1: Rise of Malicious Packages (2019 – 2025)
Source: Sonatype (2025)

The nearly exponential increase in such infected packages is particularly concerning. The npm ecosystem accounts for the largest share of this. In 2025 alone, 99% of the packages detected by Sonatype were found on npm. Combined with the large number of such packages installed in an average project in a web or Node.js environment, this raises the question of how to best mitigate the immediate risk of an SCA. While it goes without saying that the risk can never be completely eliminated as long as external dependencies are used, even simple measures and practices can go a long way in reducing the chances of such an incident.

SCAs – A Classification

Essentially, an SCA pursues a single goal: executing malware on one or more target systems to achieve arbitrary objectives, ranging from installing crypto miners to stealing confidential data. What distinguishes SCAs from other types of attacks is the method used to infiltrate the malware. Rather than infiltrating a target system directly, say, through a known vulnerability, SCAs typically take an indirect route by infecting a system's dependencies. This is precisely what makes SCAs so dangerous: dependencies you have trusted for years suddenly turn into vehicles for malicious code, attacking your own system and potentially its users.

There are many ways in which a package can become "Patient Zero" – that is, initially infected and the source of an SCA. Back in 2020, well before the recent surge discussed here, Ohm, Plate, Sykosch, & Meier (2020) published an analysis of open-source SCAs that had already occurred at the time. Figure 2 illustrates the attack paths classified by the authors, ranging from the creation of malicious packages to the compromise of an existing package. Even today, nearly six years after the paper’s publication, the methods depicted remain accurate descriptions of how an SCA can infect target systems.

Figure 2: Potential Attack Vectors for Infecting Packages
Source: Ohm, Plate, Sykosch, & Meier (2020)

For example, back in 2018, the topic of SCAs first gained widespread attention through the "event-stream" attack. In short, the popular npm package event-stream was modified via a malicious pull request ("Pull Request (as contributor)") to add a dependency on another specifically crafted, malicious package named flatmap-stream. The attack specifically targeted the Copay Bitcoin wallet, illustrating early on how quickly malware can be smuggled into a target system via an SCA. Toward the end of 2025, the name "Shai-Hulud" became a collective term and blueprint for SCAs capable of self-propagating after infecting a package, thereby infecting a chain of additional packages. With up to 500 infected packages in just a few days, high-profile victims such as @tanstack/router or Mistral, and recurring waves of attacks in various forms and by different actors, Shai-Hulud is a far more complex and advanced version of an SCA compared to event-stream. In the case of TanStack, however, this wave also began, for example, via an attack path shown in Figure 2 – specifically through the compromise of a build system and subsequently through scripts executed automatically upon the installation of a compromised package.

In general, an analysis of past SCAs shows that understanding how other dependencies and systems have been compromised in the past can help protect oneself from an SCA. The following section presents 10 specific methods that any developer working in web development can use to reduce the risk of an SCA – both for themselves and for their team.

10 Ways to Prevent Attacks in the npm Ecosystem

ℹ️ Note

All of the examples and configurations mentioned here rely on npm as the underlying package manager, given that it is typically the most widely used among the available package management options. That said, alternatives like Yarn or pnpm generally support the same or equivalent features and in some cases even more granular controls.

1 Disable Lifecycle Scripts

Lifecycle scripts, also known as install scripts, are scripts that are automatically executed by npm when interacting with a package at specific times, such as during the package’s installation. Legitimate packages use these for perfectly valid purposes (our own piral-cli, for instance, relies on the postinstall script to automatically generate useful code files). However, these scripts become a major liability when malicious packages enter the picture, as any package can execute any code via lifecycle scripts. This opens up a massive attack vector: every time an infected package is installed, it can execute malicious code directly on the target system.

Even though lifecycle scripts can be useful, the risks they pose usually outweigh the potential benefits. In most cases, it makes sense to disable these scripts altogether, preventing the execution of malicious code at its root. npm enables this through the ignore-scripts configuration setting, which can be configured locally for an individual user/machine or set for the entire development team in the following ways:

Figure 3: Deactivating Lifecycle Scripts via CLI

Figure 4: Deactivating Lifecycle Scripts via .npmrc

ℹ️ Note

It is often a good idea to configure these (and future) settings in both locations, i.e., both for the current machine and via a .npmrc file for the entire project. This protects not only your own development environment but also those of team members or, for example, automated pipelines.

ℹ️ Note

Starting with npm version 12, lifecycle scripts were disabled by default. Manually disabling them may therefore no longer be necessary. However, project-wide configurations via .npmrc may still be useful, at least temporarily, as long as, for example, not all team members or pipelines are using npm version 12.

2 Version Pinning

When referencing specific dependency versions, npm offers several version resolution strategies. For any given dependency, you can:

Request an exact version (e.g., 1.2.3).
Request the latest version within a major version (e.g., the latest version starting with 1).
Request the latest version within a minor version (e.g., the latest version starting with 1.2).
Always request the latest version.

To support this, special syntax is used within a package.json file:

Figure 5: npm Syntax Versioning Syntax

The default setting when installing a new package is Option 2, that is, a versioning strategy in which the specific version of the package to be installed is not necessarily known in advance! This "dynamic" versioning poses a risk in the context of an SCA. If a compromised version of a package is published within a dynamic version range, that package may be installed automatically.

To guard against these scenarios, one can rely on three key practices:

Actively "pinning" installed dependencies.
Using lockfiles (package-lock.json).
Running "clean installs" (npm ci command) to install packages.

Pinning dependencies refers to the above Option 1: specifying an exact package version. This stabilizes a project's list of first-level dependencies until the next manual version update. You can pin dependencies simply by removing the special syntax from a package.json file (see Figure 6).

Figure 6: Pinning Versions

Important: Pinning versions only stabilizes direct dependencies. Transitive dependencies, i.e., packages referenced by other packages, can still be resolved dynamically, and thus also become a potential entry point for an SCA.

To address this issue, one can leverage points (2) and (3). Lockfiles define the exact dependency tree that is initially installed whenever a package version changes. Unlike npm i, the npm ci command installs strictly the exact versions specified in the package-lock.json file. That's why package-lock.json files should always be shared across a project and team – for instance, by committing them to a code repository.

3 min-release-age

Today, many SCAs are swiftly caught by automated, often AI-powered, analysis tools and providers, and immediately removed from npm once detected. As a result, compromised packages are usually only available for installation for a brief window of time.

This is where the min-release-age configuration option comes into play. This option allows you to set a minimum age that a package must have reached to be installed by npm. A timeframe of, say, three to seven days could already help exclude a potential list of compromised packages from installation. Like lifecycle scripts, this option can be set at the user, machine, or project level:

Figure 7: Configuring min-release-age via CLI

Figure 8: Configuring min-release-age via .npmrc

4 Intentional Updates

New dependency versions are published almost daily in the npm ecosystem, and projects often adopt them right away or very quickly. However, for the same reasons as with min-release-age, it may also make sense to perform version updates only deliberately and, if possible, even avoid them or delay them long enough to create a time buffer against SCAs. Not every update brings real value to a project. For example, if an update merely fixes a feature that a project doesn't even use, updating might pose more risks than benefits given the threat of SCAs. Taking a deliberate approach to new npm package versions can go a long way toward preventing an SCA in your own environment. Nonetheless it is important to ensure that updates to new versions aren’t delayed for too long. Important security updates or new major versions should, whenever possible, be integrated promptly to prevent future vulnerabilities and long, painful upgrade cycles down the line. Striking the right balance for a specific package ultimately depends on the situation.

5 Are Dependencies Necesary?

In the npm ecosystem in particular, there are a multitude of (very small) packages that are frequently used by projects. A curious example made headlines a few years ago when the maintainer responsible for the left-pad package removed it from npm. left-pad is an npm package containing a single utility function just a few lines long. The removal caused significant disruptions in many projects, including large and well-known ones. The heated debate at the time about why projects use such packages in the first place and why such small helper functions aren’t developed and managed directly at the project level is also interesting from the perspective of preventing SCAs. It is often possible to simply remove at least a small portion of dependencies – or entirely replace them with self-managed code – thereby mitigating the risk of an SCA. This is particularly true in today’s age of AI, which has drastically reduced the effort required to write and maintain such helper functions. But it’s not just small packages that are worth examining: The JavaScript ecosystem is constantly evolving and, in some cases, even allows for the removal of larger packages. One example of this is the upcoming Temporal API – a native replacement for larger in scope packages such as moment or dayjs. Regularly reviewing and questioning your dependencies is well worth the effort!

6 Using Scopes and Registries

Companies often rely on private, externally inaccessible npm registries and packages. Yet even here, common entry points for SCAs exist. For instance, through a dependency confusion attack, an attacker can still manage to infect systems despite the use of internal registries and packages.

In general, there are two easy-to-implement measures that can help prevent such an attack:

Using Scopes: npm packages can begin with a scope (a prefix in the format @scope/PACKAGE_NAME). Scopes can be linked to a specific npm registry in a .npmrc file (see Figure 9). This configuration can be used to force npm to download packages exclusively from the desired private registry.
Registering Scopes on npmjs.com: Private npm registries often mirror the public npm registry and download packages from there that cannot be found internally. If custom package scopes are used internally and that scope is not registered in the public npm registry, a potential attacker could register that scope, publish a compromised package with a high version number under that scope, and thereby cause the internal registry to mirror this malicious package. To close this gap, scopes used internally should also be registered in the public npm registry whenever possible. Under registered scopes, no other parties outside the owner’s group can publish packages.

Figure 9: Configuring Scopes

7 Auditing

Auditing refers to the automatic scanning of dependencies for vulnerabilities. Automated and regular auditing, for example, as part of a project’s build pipeline, can help react quickly to the use of a compromised package in a project once it becomes known. Auditing generally focuses on mitigating an SCA, that is, detecting malicious packages already in use within a project.

There are many providers and tools for automated scans, both free and commercial. Already integrated into npm is the npm audit command, which finds and lists vulnerable dependencies using the GitHub Advisory database. When run as part of a CI/CD system, npm audit can stop pipelines and builds immediately if critical dependencies are detected. As a minimum, the end-to-end integration of npm audit into all build pipelines – where supported – makes sense in the vast majority of cases.

8 Sandboxing und Isolation

Sandboxing and isolation also fall under the umbrella of mitigation. As a developer, you often work on multiple projects – or at least have files from different projects stored on the same system. This often means that alongside the current project, secrets and credentials belonging to other projects are also accessible on the machine. Without proper isolation between projects, a compromise of a single project via an SCA can lead to the theft of sensitive data from other projects as well – not to mention any general secrets found on the system.

To counteract this, it can make sense to develop projects in isolation from one another. In an isolated environment, an SCA can only access the data specifically made available to that particular project, giving you a much more manageable baseline when responding to such an attack. There are many ways to achieve isolation, such as developing within project-specific VMs, using Dev Containers, or leveraging platforms like GitHub Codespaces.

9 AI Agents

AI agents have now established themselves as a standard tool among developers. Yet, or perhaps precisely for that reason, they present an attack vector in the context of SCAs. Sonatype reports, for example, that AI agents can demonstrably be tricked into installing a compromised dependency. Furthermore, reports highlight how attackers are increasingly tailoring their attack paths toward AI agents, using methods such as typosquatting in package names.

As a developer, you should at least ask yourself to what extent you want to trust an installed AI agent with managing dependencies. From completely revoking dependency management tasks to granting full permission, for instance in combination with strong project isolation, both options can be valid depending on the situation. At the very least you should be aware that AI agents, and by extension the user behind them, can fall victim to an SCA.

10 Maintainer – 2FA & Trusted/Staged Publishing

This section is intended for maintainers of npm packages. npm itself has responded to the rapidly increasing number of infected packages and has increased the number of available options that can potentially prevent a compromised package from being published under one’s own name:

Two-factor Authentication (2FA): 2FA is practically mandatory for package publishing – setting up a second factor protects against account takeover, safeguarding the ability to upload new package versions.
Trusted Publishing: npm supports the Trusted Publishing standard. This allows you to publish a package directly from a build pipeline without any manual management of long-lived authentication tokens—instead, short-lived tokens are issued automatically. In addition to automatic usability improvements (tokens can no longer accidentally expire and cause pipelines to fail), the tokens used by Trusted Publishing are harder to leak and, due to their short lifespan, much harder for malicious actors to exploit overall.
Staged Publishing: A relatively new option is the ability to stage packages on npm prior to final publication. Unlike direct publishing, a package staged by a build pipeline, for instance, must be explicitly approved and verified via 2FA by a maintainer before it appears as a new version and can be installed.

Combined, these three options offer a strong shield for both preventing and mitigating potential SCAs. On their own, these measures can be circumvented. For instance, Trusted Publishing alone did not prevent the SCA on TanStack. In hindsight, a combination of Trusted and Staged Publishing might have led to a different outcome here.

Conclusion

Is it possible to completely prevent a potential SCA in one’s own environment using the methods described here? This question must be answered with a resounding "no". While the methods outlined can, at best, block an SCA or at least mitigate its impact, even they do not offer 100% protection. The complex attack on TanStack highlights how threat actors are already developing and deploying sophisticated techniques to hide malware deep within the forest of software dependencies. As paranoid as it might sound: in modern software development, you should no longer ask if you will be hit by an SCA, but when – and ideally prepare appropriate prevention and response measures accordingly.

Most of the methods mentioned above focus on prevention, and although they are tailored to the npm ecosystem in this article, they may also be applicatable to other languages and environments like Python/Pip or C#/NuGet. In addition to prevention, however, it also makes sense to plan ahead for the worst-case scenario and, ideally, establish an incident response process that can be executed if an SCA does succeed. Ultimately, vigilance and actively monitoring your own dependencies are the best protection. Taking SCAs seriously as a threat and acting on that reality will leave you far better protected in the long run.

References

Ohm, M., Plate, H., Sykosch, A., & Meier, M. (2020). Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks. International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (S. 23-43). Springer, Cham.
Sonatype. (2025). Open Source Malware at the Gate - The Evolving Software Supply Chain Attack Surface.

Supply Chain Attacks im Web – 10 Methoden, Angriffe im npm-Ökosystem zu vermeiden

Manuel — Fri, 28 Aug 2026 15:25:00 +0000

Hinweis: Dieser Post ist auch auf auf Englisch 🇬🇧 verfügbar.

Das Jahr 2026 steht noch deutlicher als das Vorjahr im Schatten weitreichender und tiefgreifender Supply Chain Attacks (SCAs). Überspitzt formuliert vergeht kein Tag, an dem in Softwareentwicklerkreisen nicht eine neue Meldung über ein weiteres infiziertes Softwarepaket aufkommt, welches das Potential hat, eigene Lösungen und Infrastrukturen anzugreifen. Eine SCA, also grundlegend der Prozess, ohne eigenes Zutun via externe Abhängigkeiten als Einfallstor von bösartigen Akteuren angegriffen zu werden, war noch vor einigen Jahren eine eher theoretisch betrachtete Randerscheinung. Heutzutage hat sich das Thema allerdings zu einer omnipräsenten und ernstzunehmenden Gefahr in der Softwarebranche entwickelt.

Konkret veranschaulicht wird diese Entwicklung beispielsweise in einem Bericht des Unternehmens Sonatype (Abbildung 1). Aufgezeigt wird die Entwicklung der von Sonatype entdeckten bösartigen Softwarepakete – vom Beginn der Aufzeichnungen im Jahr 2019 bis einschließlich 2025. Das Jahr 2025 endete mit über 1,2 Millionen entdeckten Paketen – und jedes davon eine individuelle Möglichkeit, unbeabsichtigt ein eigenes System zu infizieren.

Abbildung 1: Entwicklung bösartiger Softwarepakete (2019 – 2025)
Quelle: (Sonatype, 2025)

Besonders besorgniserregend ist der beinahe exponentielle Anstieg solcher infizierten Pakete. Der größte Anteil ist hier dem npm-Ökosystem zuzuschreiben. Allein im Jahr 2025 waren 99% der von Sonatype entdeckten Pakete auf npm zu finden. Kombiniert mit der Vielzahl von solchen Paketen, die in einem durchschnittlichen Projekt im Web- oder Node.js-Umfeld installiert werden, stellt sich hier die Frage, wie sich die unmittelbare Gefahr einer SCA bestmöglich reduzieren lässt. Wenngleich sich bereits vorab sagen lässt, dass die Gefahr niemals vollständig unterbunden werden kann, solange externe Abhängigkeiten verwendet werden, so können doch selbst einfache Maßnahmen und Praktiken bereits helfen, die Chance eines solchen Vorfalls drastisch zu reduzieren.

SCA – Eine Einordnung

Grundsätzlich folgt eine SCA einem einzigen Ziel: Dem Ausführen von Schadsoftware auf einem oder mehreren Zielsystem(en), um arbiträre Ziele wie beispielsweise das Installieren von Crypto Minern bis hin zum Stehlen von geheimen Daten zu erreichen. Was SCAs von anderen Angriffsarten unterscheidet, ist die Art der Einschleusung der Schadsoftware. Anstatt ein Zielsystem direkt, beispielsweise über eine bekannte Schwachstelle, zu infiltrieren, nutzen SCAs typischerweise einen Umweg, indem sie Abhängigkeiten eines Systems infizieren. Genau diese Eigenschaft macht SCAs derartig perfide – Abhängigkeiten, denen man bereits seit langer Zeit sein Vertrauen schenkt, werden plötzlich zum Vehikel von Schadcode, der das eigene System und potenziell dessen Nutzer angreift.

Die Arten und Weisen, auf die ein Paket zum „Patient Zero“, also eben initial infiziert und zur Quelle einer SCA werden kann, sind vielfältig. Bereits 2020, also sogar vor dem aktuellen thematisierten Anstieg, publizierten Ohm, Plate, Sykosch, & Meier (2020) eine wissenschaftliche Analyse von bereits damals aufgetretenen SCAs im Open-Source Umfeld. Abbildung 2 zeigt die von den Autoren klassifizierten Angriffspfade auf – von der Neuerstellung bösartiger Pakete bis zur Kompromittierung eines bestehenden Pakets. Die dargestellten Methoden sind bis heute, knapp sechs Jahre nach Veröffentlichung des Papers, noch akkurate Beschreibungen, wie eine SCA Zielsysteme infizieren kann.

Abbildung 2: Mögliche Angriffspfade zum Infizieren von Paketen
Quelle: Ohm, Plate, Sykosch, & Meier (2020)

So erlangte beispielsweise im Jahr 2018 das Thema SCA durch den „event-stream“ Angriff erstmals größeres Aufsehen. Zusammengefasst wurde damals das populäre npm-Paket event-stream durch einen bösartigen Pull Request („Pull Request (as contributor)“) dahingehend erweitert, dass das Paket selbst von einem weiteren, speziell präparierten und bösartigen Paket namens flatmap-stream abhängig gemacht wurde. Die Auswirkungen betrafen gezielt die Bitcoin Wallet Copay und verdeutlichten bereits damals, wie schnell sich Schadsoftware gezielt per SCA in ein Zielsystem einschleusen lässt. Gegen Ende des Jahres 2025 wurde der Name „Shai-Hulud“ ein Sammelbegriff und Ablaufplan für SCAs mit der Fähigkeit sich nach Infektion eines Pakets selbstständig weiterzuverbreiten und somit eine Kette weitere Pakete zu infizieren. Mit bis zu 500 infizierten Paketen in wenigen Tagen, prominenten Opfern, wie @tanstack/router oder Mistral und wiederkehrenden Angriffswellen in verschiedenen Formen und durch verschiedene Akteure ist Shai-Hulud eine im Vergleich zu event-stream weitaus komplexere und weiterentwickelte Version einer SCA. Im Falle von TanStack begann allerdings auch diese Welle beispielsweise durch einen in Abbildung 2 gezeigten Angriffspfad – konkret durch die Kompromittierung eines Build-Systems und im Folgenden durch automatisch bei der Installation eines kompromittierten Pakets ausgeführter Skripte.

Grundsätzlich zeigt eine Analyse von bereits geschehenen SCAs auf, dass ein Verständnis für die Art und Weise, wie andere Abhängigkeiten und Systeme in der Vergangenheit kompromittiert werden konnten, dabei helfen kann, sich selbst vor einer SCA zu schützen. Im Folgenden werden hier 10 konkrete Methoden vorgestellt, die jeder Entwickler im Web Development Umfeld nutzen kann, um persönlich und auch für ein etwaiges Team die Chance einer SCA zu reduzieren.

10 Methoden zur Vermeidung von SCAs im npm Ökosystem

ℹ️ Anmerkung

Sämtliche der hier genannten Beispiele und Konfigurationen nutzen npm als zugrundeliegenden Paketmanager, da npm typischerweise der am häufigsten verwendete unter den zur Verfügung stehenden Tools ist. Andere Optionen wie Yarn oder pnpm unterstützen in den meisten Fällen allerdings auch dieselben oder zumindest äquivalente Optionen – in manchen Fällen sogar granularer oder ausgeprägter.

1 Lifecycle Scripts deaktivieren

Lifecycle Scripts, auch Install Scripts genannt, sind Skripte, die von einem npm-Paket zu bestimmten Zeitpunkten, beispielsweise bei der Installation des Pakets, automatisch ausgeführt werden. Diese Skripte werden von wohlwollenden Paketen für durchaus sinnvolle Zwecke verwendet (unsere eigene piral-cli nutzt beispielsweise das postinstall Skript zur automatischen Generierung von nützlichen Codedateien). Problematisch werden diese Skripte allerdings bei bösartigen Paketen, denn grundsätzlich kann jedes Paket über Lifecycle Skripte jeden beliebigen Code ausführen. Diese Möglichkeit öffnet ein riesiges Einfallstor für etwaige bösartige Pakete – beispielsweise kann bei jeder Installation eines Malwarepakets dieses auf dem Zielsystem beliebigen Schadcode ausführen.

Auch wenn Lifecycle Scripts nützlich sein können – das von ihnen ausgehende Risiko überwiegt meist den möglichen Nutzen. In den meisten Fällen macht es Sinn, das Ausführen solcher Skripte und damit das potenzielle Ausführen von Schadcode im Kern zu unterbinden. Möglich gemacht wird dies in npm über die ignore-scripts Konfiguration. Diese kann lokal für den aktuellen User/den aktuellen PC, oder auch global für das gesamte Entwicklerteam über folgende Wege deaktiviert werden:

Abbildung 3: Deaktivieren von Lifecycle Scripts per CLI

Abbildung 4: Deaktivieren von Lifecycle Scripts für ein npm-basiertes Projekt

ℹ️ Anmerkung

Oft lohnt es sich, diese (und auch kommende) Einstellungen doppelt vorzunehmen, also sowohl für die aktuelle Maschine als auch via .npmrc für ein gesamtes Projekt. Auf diese Weise wird sowohl die eigene Entwicklungsumgebung als auch diejenigen von Teammitgliedern oder beispielsweise automatisierten Pipelines geschützt.

ℹ️ Anmerkung

Mit npm Version 12 wurden Lifecycle Scripts standardmäßig deaktiviert. Ein manuelles Deaktivieren könnte somit nicht mehr notwendig sein. Projektweite Konfigurationen via .npmrc können allerdings zumindest übergangsweise sinnvoll bleiben, solange nicht beispielsweise alle Teammitglieder oder Pipelines npm in Version 12 verwenden.

2 Versionen festlegen (pinnen)

npm bietet beim Referenzieren bestimmter Abhängigkeitsversionen verschiedene Versionsauflösungsstrategien an. Für eine Abhängigkeit kann man:

Eine exakte Version anfragen (z.B. 1.2.3).
Die neuste Version innerhalb einer „Major-Version“ anfragen (z.B. die neuste Version, die mit 1 startet).
Die neuste Version innerhalb einer „Minor-Version“ anfragen (z.B. die neuste Version, die mit 1.2 startet).
Immer die neueste Version anfragen.

Hierfür wird innerhalb einer package.json Datei spezielle Syntax unterstützt:

Abbildung 5: npm Syntax für Versionierung

Der Standard bei der Neuinstallation eines Pakets ist Option 2, also eine Versionierungsstrategie, bei der die zu installierende Version eines Pakets nicht zwangsläufig final bekannt ist! Diese „dynamische“ Versionierung stellt im Kontext einer SCA eine Gefahr dar. Falls eine kompromittierte Version eines Pakets innerhalb eines dynamischen Versionsbereichs veröffentlicht wird, kann dieses Paket automatisch installiert werden.

Gegen solche Fälle kann man sich mittels folgender drei Punkte schützen:

Aktives „pinnen“ von installierten Abhängigkeiten.
Verwenden von Lockdateien (package-lock.json).
Verwenden von „clean installs“ (npm ci Befehl) zum Installieren von Paketen.

Pinnen von Abhängigkeiten bezeichnet Option 1, also das Spezifizieren einer exakten Paketversion. Dadurch wird die Liste von first-level Abhängigkeiten innerhalb eines Projekts bis zur nächsten, manuell durchgeführten, Versionsänderung stabilisiert. Durchführen kann man ein „Pinning“ durch das Entfernen der speziellen Syntax innerhalb einer package.json Datei (siehe Abbildung 6).

Abbildung 6: Pinning von Versionen

Wichtig: Pinnen von Versionen stabilisiert nur direkt installierte Abhängigkeiten. Transitive Abhängigkeiten, also Pakete, die wiederum von anderen Paketen referenziert werden, können dennoch dynamisch aufgelöst werden und somit auch zum Einfallstor einer SCA werden.

Um dieses Problem zu umgehen, kann man Punkt (2) und (3) anwenden. Lockdateien definieren den exakten Abhängigkeitsbaum, der bei einer Versionsänderung eines Pakets initial installiert wird. Der npm ci Befehl installiert, im Vergleich zu npm i, auch nur exakt die Versionen, die in der package-lock.json Datei genannt sind. package-lock.json Dateien sollten deswegen immer innerhalb eines Projekts und Teams geteilt werden, also beispielsweise als Teil eines Coderepositories eingecheckt werden.

3 min-release-age

Viele SCAs werden heutzutage sehr schnell von automatisierten, häufig KI-gestützten Analysen und Anbietern in kurzer Zeit gefunden und dann, nach Entdeckung, schnell von npm entfernt. Oft sind kompromittierte Pakete somit nur für einen kurzen Zeitraum zur Installation verfügbar.

An diesem Punkt setzt die Konfigurationsoption min-release-age an. Mithilfe dieser Option lässt sich ein Mindestalter einstellen, welches ein Paket zwingend erreicht haben muss, um von npm installiert werden zu können. Ein Zeitraum von beispielsweise drei bis sieben Tagen könnte bereits helfen, eine potenzielle Liste von kompromittierten Paketen von der Installation auszuschließen. Diese Option kann, analog zu Lifecycle Scripts, User-, Maschinen- oder auch Projektweit gesetzt werden:

Abbildung 7: Konfigurieren von min-release-age per CLI

Abbildung 8: Konfigurieren von min-release-age für ein npm-basiertes Projekt

4 Bewusste Aktualisierungen

Neue Versionen von Abhängigkeiten werden im npm-Ökosystem fast täglich veröffentlicht. Oft werden Abhängigkeiten in Projekten direkt, bzw. sehr schnell aktualisiert. Aus denselben Gründen wie bei min-release-age kann es aber auch Sinn machen, Versionsupdates ausschließlich bewusst durchzuführen und, falls möglich, sogar zu vermeiden oder so lange zu verzögern, dass ein zeitlicher Schutzeffekt gegen SCAs entsteht. Nicht jedes Versionsupdate bringt Vorteile für ein Projekt. Werden in einer Abhängigkeit beispielsweise Probleme eines Features behoben, das von einem Projekt nicht verwendet wird, kann ein Update durch die SCA-Thematik sogar mehr Risiken als Vorteile bergen. Ein bewusster Umgang mit neuen Versionen von npm-Paketen und deren Updates kann eine SCA im eigenen Umfeld verhindern.
Natürlich muss sichergestellt werden, dass Updates auf neue Versionen auch nicht zu lange hinausgezögert werden. Wichtige Sicherheitsupdates oder auch neue Major-Versionen sollten, sofern möglich, zeitnah integriert werden, um etwaige spätere Sicherheitslücken und lang andauernde Updateprozesse zu verhindern. Der richtige Prozess für ein konkretes Paket ist eine situationsabhängige Balance.

5 Sind Abhängigkeiten notwendig?

Insbesondere im npm-Ökosystem gibt es eine Vielzahl von (Kleinst-)paketen, die häufig von Projekten als Unterstützung verwendet werden. Ein kurioses Beispiel machte vor einigen Jahren Schlagzeilen, als der für das Paket left-pad zuständige Maintainer das Paket von npm löschte. left-pad ist ein npm-Paket mit einer einzigen, wenigen Zeilen langen Hilfsfunktion. Das Löschen führte zu heftigen Disruptionen in vielen, auch großen und bekannten, Projekten. Die damals laut hörbare Debatte, wieso solche Pakete überhaupt erst von Projekten verwenden werden und solche kleinen Hilfsfunktionen nicht direkt auf Projektebene selbst entwickelt und verwaltet werden, ist auch aus der Blickrichtung der Prävention von SCAs interessant. Häufig ist es möglich, zumindest einen kleinen Teil von Abhängigkeiten schlichtweg zu entfernen, beziehungsweise durch selbstverwalteten Code zu ersetzen, und somit das Risiko einer SCA zu mildern. Dies gilt insbesondere im heutigen Zeitalter der KI, dank deren Hilfe der Aufwand für das Schreiben und die Pflege solcher Hilfsfunktionen drastisch gesunken ist. Aber nicht nur der Blick auf Kleinstpakete lohnt sich: Das JavaScript Ökosystem entwickelt sich konstant weiter und erlaubt teilweise auch das Entfernen von größeren Paketen. Ein Beispiel hierfür ist die kommende Temporal API – ein nativer Ersatz für vom Umfang größere Pakete wie beispielsweise moment oder dayjs. Der regelmäßige Blick auf und das Hinterfragen der Verwendung von Abhängigkeiten kann sich lohnen!

6 Umgang mit Registries

Oft werden innerhalb eines Unternehmens private, also von außen nicht zugängliche, npm-Registries und Pakete verwendet. Auch in diesem Bereich gibt es gängige Einfallstore für eine SCA. Einem Angreifer kann es, beispielsweise über einen Dependency Confusion Angriff, möglich werden, Systeme trotz internen Registries und Paketen zu infizieren.

Allgemein gibt es zwei leicht umzusetzende Punkte, die einen solchen Angriff verhindern können:

Verwenden von Scopes: npm-Pakete können mit einem Scope (einem Präfix im Format @scope/PAKET_NAME) beginnen. Scopes können in einer .npmrc Datei mit einer bestimmten npm-Registry verknüpft werden (siehe Abbildung 9). Über eine solche Konfiguration kann forciert werden, dass npm die Pakete ausschließlich aus der gewollten, privaten Registry herunterlädt.
Registrieren von Scopes auf npmjs.com: Private npm-Registries spiegeln oft die öffentliche npm-Registry und laden von dort Pakete herunter, die intern nicht gefunden werden können. Wenn intern eigene Paket Scopes verwendet werden und dieser Scope nicht in der öffentlich npm Registry registriert ist, könnte ein möglicher Angreifer diesen Scope registrieren, unter diesem Scope ein kompromittiertes Paket mit einer hohen Version veröffentlichen und somit die interne Registry dazu bewegen, dieses bösartige Paket zu spiegeln. Um dieses Einfallstor zu schließen, sollten intern verwendete Scopes nach Möglichkeit auch in der öffentlichen npm-Registry registriert werden. Unter registrierten Scopes können, außerhalb des Eigentümerkreises, keine weiteren Akteure Pakete veröffentlichen.

Abbildung 9: Konfiguration von Scopes

7 Auditing

Auditing bezeichnet das automatische Scannen von verwendeten Abhängigkeiten auf Schwachstellen. Ein automatisiertes und regelmäßiges Auditing, beispielsweise als fester Bestandteil der Buildpipeline eines Projekts, kann nach Bekanntwerden eines kompromittieren Pakets dabei helfen, schnell auf die Verwendung im eigenen Projekt zu reagieren. Auditing zielt generell eher auf die Mitigation einer SCA ab, also auf die Entdeckung bereits verwendeter, schädlicher Pakete im eigenen Projekt.

Anbieter und Tools für automatisierte Scans, sowohl kostenlos als auch kommerziell, gibt es viele. Bereits fest in npm integriert ist der npm audit Befehl der vulnerable Abhängigkeiten mithilfe der GitHub Advisory Datenbank findet und auflistet. Als Teil eines CI/CD Systems ausgeführt kann npm audit Pipelines und Builds direkt stoppen, wenn kritische Abhängigkeiten entdeckt wurden. Die durchgängige Integration von npm audit als Minimum in sämtliche Build Pipelines macht, sofern unterstützt, in den allermeisten Fällen Sinn.

8 Sandboxing und Isolation

Ebenfalls im Bereich der Mitigation angesiedelt ist das Thema Sandboxing und Isolation. Als Entwickler arbeitet man häufig an mehreren Projekten, beziehungsweise hat zumindest häufig die Dateien verschiedener Projekte auf einem System installiert. Oft bedeutet das, dass zusätzlich zu einem Projekt auch Geheimnisse (Secrets) und/oder Anmeldedaten (Credentials) anderer Projekte auf der Maschine verfügbar sind. Dies kann, ohne Isolation der verschiedenen Projekte, dazu führen, dass im Falle der Kompromittierung eines Projekts durch eine SCA auch geheime Daten eines anderen Projekts gestohlen werden – von allgemein auf dem System gefundenen Secrets einmal komplett abgesehen.

Um dem entgegenzuwirken kann es sinnvoll sein, Projekte isoliert/abgeschirmt von anderen zu entwickeln. Bei einem isolierten Projekt kann ein SCA immerhin nur die dem Projekt zur Verfügung gestellten Daten finden – idealerweise ein wesentlich kontrollierbarer Ausgangspunkt für Reaktionen auf einen solchen Angriff. Möglichkeiten der Isolation gibt es viele, beispielsweise das Entwickeln innerhalb einer projektspezifischen VM, in Dev Containern oder auch das Verwenden von Produkten wie GitHub Codespaces.

9 KI-Agenten

KI-Agenten haben sich in Entwicklerkreisen mittlerweile als Standardwerkzeug etabliert. Dennoch, oder gerade deswegen, bieten diese eine Angriffsfläche im Rahmen von SCAs. Sonatype berichtet beispielsweise, dass KI-Agenten nachweislich dazu bewegt werden können, eine kompromittierte Abhängigkeit zu installieren. Außerdem wird berichtet, wie Angreifer ihre Angriffspfade mittlerweile verstärkt auch auf KI-Agenten ausrichten, beispielsweise durch Methoden wie Typosquatting bei Paketnamen.

Als Entwickler sollte man sich zumindest die Frage stellen, inwiefern man einem installierten KI-Agenten beim Verwalten von Abhängigkeiten vertrauen und überlassen möchte. Von komplettem Entzug der Abhängigkeitsverwaltungsaufgaben bis hin zur vollständigen Erlaubnis derselben, beispielsweise in Kombination mit starker Projektisolation – beide Optionen können situationsabhängig valide sein. Bewusst sein sollte man sich aber zumindest darüber, dass auch KI-Agenten, und somit unmittelbar der eigentlich dahinterstehende Nutzer, Opfer einer SCA werden können.

10 Maintainer – 2FA & Trusted/Staged Publishing

Dieser Punkt ist zugeschnitten auf Maintainer von npm-Paketen. npm reagierte selbst auf die rasant steigende Zahl infizierter Pakete und hat in der vergangenen Zeit einige Optionen entwickelt, mit denen sich potenziell verhindern lassen kann, dass ein kompromittiertes Paket im eigenen Namen veröffentlicht wird:

Zwei-Faktor-Authentifizierung (2FA): 2FA ist für das Veröffentlichen von Paketen beinahe schon Pflicht – das Einrichten eines zweiten Faktors schützt vor der Übernahme des eigenen Accounts, und damit der Fähigkeit, neue Versionen eines Pakets hochzuladen.
Trusted Publishing: npm unterstützt den Trusted Publishing Standard. Dieser erlaubt es, ein Paket direkt aus einer Build Pipeline und komplett ohne manueller Verwaltung von langlebigen Authentifizierungstokens zu veröffentlichen – stattdessen werden automatisiert kurzlebige Token ausgestellt. Neben automatischen Verbesserungen bei der Benutzerfreundlichkeit (Token können nicht mehr versehentlich ablaufen und Pipelines fehlschlagen lassen) können die von Trusted Publishing verwendeten Token schwieriger abfließen, beziehungsweise, aufgrund ihrer Kurzlebigkeit, insgesamt schwerer von böswilligen Akteuren verwendet werden.
Staged Publishing: Relativ neu ist die Möglichkeit, Pakete auf npm vor der finalen Veröffentlichung zu „stagen“. Im Vergleich zu einer direkten Veröffentlichung muss ein Paket hier, beispielsweise nach dem Staging durch eine Buildpipeline, explizit und durch 2FA verifiziert von einem Maintainer freigegeben werden, bevor es als neue Version erscheint und installiert werden kann.

Kombiniert bieten diese drei Optionen einen starken Schild sowohl zur Prävention als auch zur Mitigation einer möglichen SCA. Einzeln betrachtet sind die Maßnahmen aushebelbar – so unterband Trusted Publishing allein beispielsweise nicht die SCA auf TanStack. Eine Kombination aus Trusted und Staged Publishing hätte hier rückblickend vielleicht einen anderen Verlauf erwirkt.

Ausblick

Kann man mit Hilfe der hier genannten Methoden eine etwaigen SCA im eigenen Umfeld komplett verhindern? Diese Frage muss mit einem klaren „Nein“ beantwortet werden. Die aufgezeigten Methoden können eine SCA zwar im Besten Fall unterbinden, oder zumindest deren Auswirkungen mildern, aber einen 100%igen Schutz stellen auch sie nicht dar. Der komplexe Angriff auf TanStack verdeutlicht, wie feindliche Akteure bereits heute komplizierte Methoden entwickeln und anwenden, um Schadsoftware tief im Wald der Softwareabhängigkeiten zu verstecken. So paranoid es klingen mag: bei der heutigen Entwicklung sollte man sich nicht mehr fragen, ob man von einer SCA getroffen wird, sondern wann – und entsprechende Präventions- und Reaktionsmaßnahmen vorbereiten. Die meisten der oben genannten Methoden zielen auf Prävention und sind, auch wenn sie in diesem Artikel auf das npm-Ökosystem zugeschnitten sind, auch in anderen Sprachen und Umfeldern wie Python/Pip oder C#/NuGet anwendbar. Zusätzlich zur Prävention ist es allerdings auch sinnvoll, bereits für den Worst-Case vorzuplanen und, idealerweise, einen Incident-Response-Prozess vorzubereiten, der im Falle einer erfolgreich durchgeführten SCA durchlaufen werden kann. Am Ende gilt: Wachsamkeit und ein aktiver Blick auf die eigenen Abhängigkeiten sind der beste Schutz. Wer SCAs als ernstzunehmende Gefahr begreift und danach handelt, ist vor diesen nachhaltig besser geschützt.

Quellen

Ohm, M., Plate, H., Sykosch, A., & Meier, M. (2020). Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks. International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (S. 23-43). Springer, Cham.
Sonatype. (2025). Open Source Malware at the Gate - The Evolving Software Supply Chain Attack Surface.