Was ist eine Dependency Firewall?

Blog

Leitfäden & Best Practices

Verfasst von

Nicholas Thomson

Veröffentlicht am:

13. Juli 2026

Zuletzt aktualisiert am:

14. Juli 2026

Eine Dependency Firewall ist ein Kontrollpunkt, der bösartige Pakete blockiert, bevor sie installiert werden, unabhängig davon, ob eine Entwickelnde, eine CI/CD-Pipeline oder ein AI-Coding-Agent sie angefordert hat. Sie funktioniert ähnlich wie eine Netzwerk-Firewall, nur dass der Traffic hier Open-Source-Pakete anstelle von Netzwerkpaketen ist und der Einstiegspunkt der Installationsbefehl ist.

Dependency Firewalls existieren, weil das Volumen von Lieferkettenangriffen sie notwendig macht. Aikido Intel analysiert nun täglich bis zu 100.000 bösartige Pakete über Open-Source-Registries hinweg, gegenüber etwa 20.000 vor einem Jahr. Allein im zweiten Quartal 2026 wurden rund 7,5 Millionen Paketversionen analysiert und 19.500 als bösartig bestätigt.

Warum sind Dependency Firewalls notwendig?

Sobald Ihr Paketmanager eine Installation ausführt, ist Ihre Maschine exponiert. Erschwerend kommt hinzu, dass Angreifer schneller geworden sind und KI ihnen neue Wege eröffnet hat.

Installationsskripte sind der Payload-Delivery-Mechanismus

Wenn Sie ausführen npm install, Pakete können Code als Teil der Installation selbst ausführen. Der Postinstall-Hook ist der Ort, an dem viele moderne Lieferkettenangriffe stattfinden, da er mit den Berechtigungen der Entwickelnden ausgeführt wird, bevor jemand die Möglichkeit hat, den Code zu überprüfen.

Im März 2026, kaperten Angreifer das npm-Konto des axios-Maintainers und veröffentlichten zwei bösartige Versionen der Bibliothek (die wöchentlich etwa 100 Millionen Mal heruntergeladen wird). Der Payload gelangte über eine neu hinzugefügte transitive Dependency herein, plain-crypto-js, deren Postinstall-Hook einen plattformübergreifenden RAT auf jede Maschine installierte, die die Installation ausführte.

Coding Agents und MCP-Server sind neue Installationsflächen

Die Paketinstallation wird nicht mehr immer von einem Menschen initiiert. Coding Agents und MCP-Server ziehen von npm auf Entwickelnden-Maschinen mit Zugriff auf sensiblen Code und Anmeldeinformationen. Im September 2025 veröffentlichte ein Angreifer, der sich als Postmark ausgab, einen bösartigen MCP-Server auf npm, der jede ausgehende E-Mail heimlich an eine vom Angreifer kontrollierte Adresse als BCC sendete. Es war der erste bestätigte bösartige MCP-Server auf npm, und es ist ein Zeichen für das, was noch kommen wird.

Agents halluzinieren auch, und Angreifer haben begonnen, Paketnamen zu registrieren, um dies auszunutzen. Agents, die falsch raten, riskieren nun die Installation eines Pakets, das der Angreifer im Voraus vorbereitet hat. Dieser Angriff, manchmal als Slopsquatting bezeichnet, existierte vor zwei Jahren noch nicht als Kategorie.

Angriffsfenster werden kürzer

Der bösartige plain-crypto-js Paket, das den axios-Angriff speiste, existierte weniger als 24 Stunden, bevor es eingebunden wurde. Das debug- und chalk-Kompromittierung betraf 18 Pakete mit mehr als 2 Milliarden kombinierten wöchentlichen Downloads in einer einzigen Welle. Jede Abwehrmaßnahme, die nach einer Installation ausgeführt wird, sei es ein nächtlicher Scan oder eine öffentliche Warnung, kommt zu spät.

Ein Paket, dem Sie vertrauen, kann sich gegen Sie wenden

Die folgenreichsten Lieferkettenangriffe des letzten Jahres betrafen Bibliotheken mit Millionen von wöchentlichen Downloads. Angreifer kompromittierten Maintainer-Konten für axios, chalk und debug, stahlen Publish-Tokens und veröffentlichten bösartige Versionen derselben Pakete, die Benutzer bereits in ihren Lockfiles hatten. Reputation und Download-Zahlen schützen nicht vor einer bösartigen neuen Version. Die Überprüfung muss bei jeder Installation erfolgen.

Was eine Dependency-Firewall prüft

Die spezifischen Prüfungen variieren zwischen den Tools, aber eine nützliche Dependency-Firewall deckt die meisten der folgenden Punkte ab. Und jede Prüfung muss auch für transitive Abhängigkeiten gelten, da die meisten modernen Angriffe mehrere Ebenen tief im Abhängigkeitsbaum angesiedelt sind. Das bösartige plain-crypto-js Paket, das den axios-Angriff speiste, war eine transitive Abhängigkeit, die fast niemand explizit installiert hatte.

Bekannte Malware

Die Basisprüfung. Die Firewall gleicht jedes Paket mit einem aktuellen Threat Feed ab und blockiert alles, was bereits markiert wurde. Dies umfasst Backdoors, Credential Stealer, Krypto-Miner und andere als feindlich bekannte Pakete. Entscheidend ist hier, dass der Intelligence Feed schneller ist als der Angreifer. Ein bösartiges Paket, das drei Tage nach der Veröffentlichung markiert wird, ist wahrscheinlich bereits auf dem Rechner einer Person ausgeführt worden.

Mindestalter von Paketen

Die meisten bösartigen Releases werden innerhalb von ein oder zwei Tagen nach der Veröffentlichung entdeckt und entfernt. Eine Firewall, die Pakete blockiert oder verzögert, die in den letzten 24 bis 48 Stunden veröffentlicht wurden, eliminiert das gesamte Früherkennungsfenster. Der Rest des Ökosystems kommt zu derselben Schlussfolgerung. Jeder große Paketmanager im npm-Ökosystem unterstützt jetzt eine Einstellung für das Mindestalter von Releases, die die Installation jeder Paketversion verweigert, die neuer als ein konfigurierbarer Schwellenwert ist. pnpm, Yarn, Bun und npm selbst liefern dies alle mit.

Dependency Confusion, Typosquats und nicht beanspruchte Namen

Dies sind drei eng verwandte Muster. Typosquats imitieren beliebte Paketnamen (z. B. lodahs statt lodash) und setzen darauf, dass ein falsch eingegebener Befehl unbemerkt bleibt. Dependency Confusion zielt auf interne Paketnamen ab, die ein Unternehmen nicht im öffentlichen Register reserviert hat. Der Angreifer veröffentlicht eine öffentliche Version mit einer höheren Versionsnummer, und der Resolver wählt die bösartige aus, in der Annahme, es handele sich um ein sicheres Update. Und es gibt eine neuere Angriffsfläche, die Aikido verfolgt hat, wo Paketnamen in Dokumentationen und README-Dateien referenziert, aber nie tatsächlich veröffentlicht werden. Bleiben sie unbeansprucht, können sie von jedem registriert werden, auch von Angreifern. Coding Agents, die dieselben Dokumente scrapen, installieren dann, was auch immer dort vorhanden ist. Alle drei sind Fälle, die eine Firewall abfängt, bevor der Download erfolgt.

Verhalten von Installationsskripten

Statische Regeln und, in leistungsfähigeren Firewalls, die Ausführung in einer Sandbox prüfen, was die Installationsskripte eines Pakets tatsächlich tun, wohin sie sich verbinden, was sie lesen, was sie starten. Hier verstecken sich ausgeklügelte Angriffe, und hier richten einfache Angriffe ihren Schaden an. Der axios postinstall Hook, der plain-crypto-js nachgezogen hat, ist genau das Muster, das diese Prüfung erkennen soll.

Signale für Maintainer- und Account-Übernahmen

Wenn das Konto hinter einer legitimen, weit verbreiteten Bibliothek kompromittiert wird, wird die bösartige Version unter einem Namen, dem jeder bereits vertraut, an Millionen von Lockfiles ausgeliefert. Gute Firewalls erkennen die Signale einer Account-Übernahme, wie eine unerwartete Änderung des Maintainers, eine Versionserhöhung ohne passenden Source-Commit oder ein legitimes Paket, das plötzlich eine neue Abhängigkeit hinzufügt, die es zuvor nie benötigt hat.

Verschleierungstechniken

Angreifer sind kreativ geworden, was sie wie verstecken. Jüngste Beispiele sind Malware, die in unsichtbaren Unicode-Zeichen geschrieben ist, die in einem Code-Editor nicht gerendert werden (os-info-checker-es6), Payloads, die in aus dem Bildschirm gescrolltem Leerraum versteckt sind (react-html2pdf.js), und Code, der in Bilddateien eingeschleust wird. Eine Firewall, die nur das liest, was ein menschlicher Editor anzeigen würde, übersieht all dies. Die Prüfung muss die Rohbytes betrachten.

Aikidos Dependency-Firewall

Für Teams, die eine Developer-Firewall-Abdeckung für alles benötigen, was Entwickelnde auf ihren Maschinen installieren (z. B. IDE-Erweiterungen, Browser-Erweiterungen, MCP-Server, AI-Coding-Tools), ist Aikido Device Protection die Antwort. Es wird über Ihr bestehendes MDM bereitgestellt, läuft auf derselben zugrunde liegenden Intel-Architektur und bietet Sicherheitsteams eine zentralisierte Transparenz über jede Workstation hinweg.

Für einzelne Entwickelnde oder Teams, die die Installationszeitprüfung ausprobieren möchten, ohne etwas zentral bereitzustellen, ist Safe Chain eine kostenlose, quelloffene Dependency-Firewall für npm, yarn, pnpm, pip, uv, poetry und andere Paketmanager. Installieren Sie es einmal, starten Sie Ihre Shell neu, und jede Installation läuft durch die Firewall.

Die Intelligenz hinter beiden ist Aikido Intel, das neue Paketversionen in über 20 Ökosystemen analysiert, sobald sie veröffentlicht werden, wobei die meisten in durchschnittlich sechs Minuten und viele innerhalb von ein oder zwei Minuten markiert werden. Es läuft in vier Schichten (statische Regeln, Ausführung in einer Sandbox, KI-Reasoning über Dateien hinweg, menschliche Überprüfung für die schwierigsten Fälle), und der Feed selbst ist öffentlich und kostenlos unter AGPL verfügbar.

Zusammen decken Safe Chain, Intel und Device Protection den gesamten Installationspfad der Lieferkette ab, von der npm-Installation eines Entwickelnden bis hin zu einem KI-Agenten, der einen MCP-Server auf einer unbeaufsichtigten Workstation einbindet.

Wie verhindere ich die Installation bösartiger npm-Pakete?

Installieren Sie eine Dependency-Firewall, die beim Installationsbefehl ausgeführt wird. Safe Chain ist kostenlos und quelloffen, umschließt npm, yarn, pnpm, pip und andere Paketmanager und prüft jede Installation gegen Aikido Intel, bevor der Download abgeschlossen ist. Wird das Paket markiert, schlägt die Installation fehl und nichts gelangt auf Ihren Rechner. Die Einrichtung erfolgt mit einem Befehl und einem Shell-Neustart.

Wie schütze ich mich vor Typosquatting und Dependency Confusion?

For dependency confusion specifically, use scoped package names for anything internal (e.g., @yourcompany/<package>) so there's no ambiguous name for an attacker to hijack. For typosquats, use an install-time dependency firewall that checks each package against a real-time threat feed. Safe Chain blocks both across every package manager it wraps.

Wie verhindere ich, dass KI-Coding-Agents bösartige Pakete installieren?

Wenn ein Agent versucht, einen halluzinierten Paketnamen per npm zu installieren, den ein Angreifer vorregistriert hat (ein Angriff namens Slop Squatting), wird eine Dependency-Firewall den Download zum Installationszeitpunkt verhindern. Agenten installieren aber auch über IDE-Erweiterungen, Browser-Erweiterungen und MCP-Server, die das Terminal vollständig umgehen. Dafür deckt Aikido Device Protection alles ab, was eine Entwickelnden-Maschine installieren kann, einschließlich Erweiterungen und MCP-Server.

Was kostet Safe Chain?

Nichts. Safe Chain ist kostenlos und Open Source unter einer MIT-Lizenz und erfordert kein Aikido-Konto zur Nutzung. Der Bedrohungs-Feed, den es prüft, Aikido Intel, ist ebenfalls kostenlos und öffentlich.

Wie implementiere ich eine Dependency Firewall im gesamten Team?

Aikido Device Protection bietet eine Dependency Firewall auf Organisationsebene, die über jedes bereits genutzte MDM (Jamf, Kandji, Fleet, andere) bereitgestellt wird, sodass jeder Arbeitsplatz vom ersten Tag an geschützt ist. Es basiert auf derselben Bedrohungsaufklärung wie Safe Chain und bietet Sicherheitsteams eine zentralisierte Übersicht über jede Maschine.

Textlink

Nachrichten abonnieren

4.7/5

Falschpositive Ergebnisse leid? 
Probieren Sie Aikido, wie 100.000 andere.

Jetzt starten

Erhalten Sie eine personalisierte Führung

Von über 100.000 Teams vertraut

Jetzt buchen

Scannen Sie Ihre App nach IDORs und realen Angriffspfaden

Von über 100.000 Teams vertraut

Scan starten

Erfahren Sie, wie KI-Penetrationstests Ihre App testen

Von über 100.000 Teams vertraut

Testen starten

Testen Sie Safe Chain, kostenlos

Install-time Dependency Firewall

Safe Chain erhalten

Sicherheit von Docker-Images

Die meisten Schwachstellen eines „ container “ stammen aus dem Basis-Image. Wie man Docker-Images absichert, warum die Absicherung ein fortlaufender Prozess ist und wie man das bereits verwendete Basis-Image patcht.

Gehärtete Images

21. Juli 2026

„•“

Leitfäden & Best Practices

Der CISO von Tyro: Der „Einstein der Cybersicherheit“ zu sein, reicht nicht aus, wenn Entwickelnde Ihnen nicht vertrauen

Arun Singh, CISO von Tyro, über das Vertrauen der Entwickelnden als endliche Ressource und was passiert, wenn Lieferkettenangriffe Teams dazu zwingen, es aufzubrauchen

Tools

Sicherheit der Software-Lieferkette

20. Juli 2026

„•“

Leitfäden & Best Practices

Was Entwickelnde über DSPM und Datenexposition im Code wissen müssen

Traditionelles DSPM findet, wo sensible Daten liegen. Code-basiertes DSPM findet, wie sie offengelegt werden, und zeigt auf die Lösung in Ihrem Code.

Tools

AppSec

Datensicherheit

Sicherheit jetzt implementieren

Sichern Sie Ihren Code, Ihre Cloud und Ihre Laufzeit in einem zentralen System.
Finden und beheben Sie Schwachstellen schnell und automatisch.

Jetzt scannen

Demo buchen

Keine Kreditkarte erforderlich | Scan-Ergebnisse in 32 Sek.