Socket.dev vs. Snyk vs. npm audit: 830 Pakete [2026]

Der Schock kam an einem Montagmorgen. Am 24. November 2025 registrierten Sicherheitsteams bei Zapier, PostHog, Postman, ENS Domains und AsyncAPI, dass ihre eigenen npm-Pakete plötzlich Schadcode enthielten. Der Wurm “Shai-Hulud 2.0” hatte über 500 Pakete infiziert, mehr als 25.000 GitHub-Repositories kompromittiert und rund 132 Millionen monatliche Downloads erreicht, bevor jemand eingriff. Wer zu diesem Zeitpunkt nur auf npm audit vertraute, hat davon nichts mitbekommen, denn der Wurm hatte noch keinen offiziellen CVE-Eintrag. Genau diese Lücke zwischen bekannter Schwachstelle und aktivem Angriff treibt Unternehmen aktuell zu neuen Werkzeugen wie Socket.dev und Snyk.

Dieser Vergleich stellt drei sehr unterschiedliche Ansätze gegenüber: das kostenlose, in npm eingebaute Audit-Kommando, die etablierte Plattform Snyk mit bekannten Schwachstellendatenbanken und den jüngeren Herausforderer Socket.dev, der auf Verhaltensanalyse von Paketen setzt statt auf reine CVE-Abgleiche. Für deutsche und europäische Unternehmen, die npm, PyPI oder andere Paket-Ökosysteme in der Softwarelieferkette einsetzen, ist die Wahl des richtigen Werkzeugs längst keine reine Compliance-Frage mehr, sondern eine Frage der Betriebssicherheit.

Warum Supply-Chain-Schutz für npm-Pakete 2026 kein Nischenthema mehr ist

Die Softwarelieferkette ist für Angreifer inzwischen attraktiver als der direkte Angriff auf ein einzelnes Unternehmen. Ein einziges kompromittiertes npm-Paket kann sich über Tausende Projekte verteilen, bevor jemand etwas merkt. Der Shai-Hulud-Wurm zeigte dieses Muster gleich zweimal: Die erste Welle im September 2025 begann laut FortiGuard Labs mit einem Phishing-Angriff auf den npm-Maintainer “qix” am 8. September 2025, bei dem Zugangsdaten gestohlen wurden. Über den kompromittierten Account wurden manipulierte Versionen der weitverbreiteten Pakete debug, chalk und ansi-styles veröffentlicht. eSentire zählte in einer späteren Analyse 187 betroffene Pakete in dieser ersten Welle, darunter auch Pakete aus dem CrowdStrike-Namespace.

Die zweite Welle traf die npm-Community deutlich härter. Zwischen dem 21. und 24. November 2025 luden die Angreifer laut Wiz und Aikido trojanisierte Paketversionen hoch. Die Zahlen variieren je nach Zeitpunkt der Zählung: Socket meldete am 24. November mehr als 500 betroffene Pakete und über 700 betroffene Versionen, Wiz sprach von rund 700 kompromittierten Paketen, und The Hacker News berichtete später von mehr als 830 Paketen, nachdem sich der Angriff sogar auf das Java-Ökosystem Maven ausgeweitet hatte. Übereinstimmend berichten alle Quellen von mehr als 25.000 betroffenen GitHub-Repositories und rund 350 betroffenen Nutzerkonten.

Technisch war der Angriff besonders unangenehm, weil er sich selbst weiterverbreitete. Die Schadsoftware nutzte laut Aikido und SC World unsichere GitHub-Actions-Konfigurationen mit pull_request_target und workflow_run, installierte heimlich die Bun-Laufzeitumgebung und registrierte infizierte Maschinen als selbstgehostete GitHub-Actions-Runner mit dem Namen “SHA1HULUD”. Anschließend durchsuchte das Schadprogramm mit dem Tool TruffleHog Repositories und Umgebungsvariablen nach npm-Tokens, GitHub-Zugangsdaten sowie AWS-, Google-Cloud- und Azure-Credentials, um sich mit den gestohlenen Zugangsdaten weiter zu vervielfältigen. PostHog bestätigte in einem öffentlichen Post-Mortem, dass die eigenen JavaScript-SDKs posthog-node, posthog-js, posthog-react-native und posthog-docusaurus betroffen waren und bezeichnete den Vorfall als bislang größten Sicherheitsschreck des Unternehmens.

Genau solche Vorfälle sind der Grund, warum reine Versionsabgleiche gegen bekannte CVE-Datenbanken nicht mehr ausreichen. Ein Paket kann technisch sauber laut Datenbank sein, obwohl es bereits aktiv Zugangsdaten stiehlt, weil noch kein Sicherheitsforscher die Schadfunktion dokumentiert und gemeldet hat. Das ist der zentrale Unterschied zwischen den drei hier verglichenen Werkzeugen. Mehr technische Hintergründe zum Angriff liefert die Analyse von Wiz zur zweiten Shai-Hulud-Welle.

Wie npm selbst auf die Angriffswellen reagiert hat

Parallel zu den hier verglichenen Drittanbieter-Tools hat auch der Registry-Betreiber npm, mittlerweile Teil von GitHub, seine eigenen Sicherheitsmechanismen grundlegend überarbeitet. Am 23. September 2025 veröffentlichte GitHub einen mehrstufigen Plan, um die npm-Lieferkette abzusichern, wie im offiziellen GitHub-Blog nachzulesen ist. Der Plan sah unter anderem vor, klassische, lange gültige Tokens schrittweise abzuschaffen, granulare Tokens mit kurzer Laufzeit zur Pflicht zu machen und OIDC-basiertes “Trusted Publishing” als bevorzugten Weg für CI/CD-Pipelines zu etablieren.

Die Umsetzung erfolgte in klar terminierten Schritten. Am 29. September 2025 deaktivierte npm die Neuanlage von TOTP-basierter Zwei-Faktor-Authentifizierung und verwies neue Konten auf WebAuthn beziehungsweise Passkeys, dokumentiert im GitHub-Changelog vom 29. September 2025. Am 5. November 2025 folgte die Abschaltung der Neuerstellung klassischer Tokens, wobei bestehende Tokens noch bis zum 19. November 2025 gültig blieben, danach wurden sie vollständig widerrufen. Gleichzeitig ersetzte npm lange gültige lokale Publish-Zugangsdaten durch Sitzungs-Tokens mit einer Gültigkeit von rund zwei Stunden, wie der Changelog-Eintrag vom 9. Dezember 2025 bestätigt. Seit diesem Datum ist Zwei-Faktor-Authentifizierung zudem für neu veröffentlichte Pakete standardmäßig aktiviert.

Für CI/CD-Pipelines empfiehlt npm inzwischen ausdrücklich, komplett auf gespeicherte Zugangs-Tokens zu verzichten und stattdessen Trusted Publishing zu nutzen, wie in der offiziellen npm-Dokumentation beschrieben. Dabei stellt ein unterstützter CI-Anbieter wie GitHub Actions ein kurzlebiges OpenID-Connect-Identitätstoken aus, das npm gegen eine hinterlegte Konfiguration aus Repository, Workflow-Datei und Aussteller prüft. Erst wenn diese Angaben übereinstimmen, erhält die Pipeline eine temporäre Publish-Berechtigung, ganz ohne ein dauerhaft gespeichertes Geheimnis, das gestohlen werden könnte. Diese Funktion war laut GitHub bereits seit Juli 2025 verfügbar und wurde im April 2026 um Unterstützung für den CI-Anbieter CircleCI erweitert. Diese Maßnahmen ändern nichts an der Funktionsweise von npm audit, Snyk oder Socket, verringern aber die Angriffsfläche, über die ein Wurm wie Shai-Hulud überhaupt erst gestohlene Zugangsdaten missbrauchen kann.

Die drei Ansätze im Überblick: npm audit, Snyk und Socket.dev

npm audit ist seit Jahren fester Bestandteil des npm-Kommandozeilenwerkzeugs und damit für jeden Node.js-Entwickler ohne Zusatzkosten verfügbar. Das Tool gleicht die im Lockfile aufgelösten Abhängigkeiten gegen eine Advisory-Datenbank bekannter Schwachstellen ab und schlägt bei Bedarf automatische Fixes über npm audit fix vor. Die Stärke liegt in der Einfachheit: kein Zusatzaccount, keine Konfiguration, sofort einsatzbereit in jeder CI-Pipeline. Die Schwäche liegt in der Definition selbst. Das Tool prüft gegen bekannte Advisories, nicht gegen verdächtiges Verhalten. Ein frisch gekapertes Paket, für das noch kein Advisory existiert, fällt bei npm audit grün durch, selbst wenn es im Hintergrund bereits Zugangsdaten exfiltriert.

Snyk positioniert sich breiter als reiner Schwachstellenscanner. Die Plattform deckt mit eigenen Produktlinien Open-Source-Abhängigkeiten (Snyk Open Source), statischen Code (Snyk Code), Container (Snyk Container) und Infrastructure-as-Code (Snyk IaC) ab. Für diesen Vergleich zählt vor allem Snyk Open Source, das Abhängigkeiten gegen eine von Snyk kuratierte Vulnerability-Intelligence-Datenbank prüft, die über die reine npm-Advisory-Datenbank hinausgeht und zusätzliche Kontextinformationen zur Ausnutzbarkeit liefert. Snyk ist damit näher an einer klassischen Software-Composition-Analysis-Lösung (SCA) als an einem reinen Malware-Detektor, auch wenn das Unternehmen zunehmend Bedrohungsdaten zu böswilligen Paketen einbindet.

Socket.dev verfolgt einen grundsätzlich anderen Ansatz. Statt primär gegen eine Liste bekannter Schwachstellen zu prüfen, bewertet Socket das Verhalten und die Eigenschaften eines Pakets: Greift es beim Installieren auf das Netzwerk zu? Führt es verdächtige Lifecycle-Skripte wie preinstall oder postinstall aus? Hat sich die Paketgröße oder der Maintainer plötzlich verändert? Nutzt es ungewöhnliche APIs wie Dateisystemzugriff, obwohl das Paket laut Beschreibung nur eine Formatierungsfunktion bereitstellt? Dieser heuristische, verhaltensbasierte Ansatz erlaubt es Socket, verdächtige Pakete zu markieren, bevor überhaupt ein CVE existiert. Genau deshalb gehörte Socket zu den ersten Anbietern, die während der Shai-Hulud-Welle im November 2025 öffentlich über den Angriff berichteten, mit einem Blogbeitrag am selben Tag, an dem die Kompromittierung entdeckt wurde.

Funktionsvergleich: Was jedes Tool tatsächlich leistet

Die folgende Tabelle stellt die wichtigsten technischen Eigenschaften gegenüber. Die Angaben basieren auf den öffentlich dokumentierten Funktionen der jeweiligen Anbieter und Produktseiten, Stand September 2026.

Kriterium	npm audit	Snyk (Open Source)	Socket.dev
Grundprinzip	Abgleich gegen Advisory-Datenbank	Kuratierte Vulnerability-Intelligence-Datenbank	Verhaltens- und Risikoanalyse pro Paket
Erkennt bekannte CVEs	Ja	Ja, mit Kontext zur Ausnutzbarkeit	Ja, als ein Signal von vielen
Erkennt neue Schadpakete ohne CVE	In der Regel nein	Teilweise, abhängig von Threat-Intelligence-Feeds	Zentrale Produktfunktion (Verhaltenssignale)
Prüft Install-Skripte (preinstall/postinstall)	Nein	Eingeschränkt	Ja, mit Risikobewertung
Reachability-Analyse	Nein	Teilweise in höheren Plänen	Ja, ab Team-Plan
SBOM-Export	Nein	Ja	Ja, ab Business-Plan
CI/CD-Integration	Ja (nativ in npm)	Ja (GitHub, GitLab, Jenkins u. a.)	Ja (GitHub App, GitLab, CLI)
IDE-Integration	Nein	Ja	Ja (Browser-Erweiterung für npm-Registry)
Container- und IaC-Scanning	Nein	Ja (separate Produkte)	Eingeschränkt, Fokus auf Paket-Ökosysteme
Unterstützte Ökosysteme	Nur npm	npm, PyPI, Maven, RubyGems, Go, NuGet u. a.	npm, PyPI, Go, Maven, Composer, Cargo
Kosten im Basistarif	Kostenlos	Kostenlos (limitiert)	Kostenlos (limitiert)
Open-Source-Projekte	Kostenlos	Kostenlos mit Einschränkungen	Dauerhaft kostenlos

Der Unterschied zwischen bekannter Schwachstelle und verdächtigem Verhalten ist in der Praxis entscheidend. Ein Paket, das plötzlich eine Netzwerkverbindung zu einer unbekannten Domain aufbaut, obwohl es laut Beschreibung nur String-Funktionen bereitstellt, hat noch keine CVE-Nummer, aber ein klares Risikosignal. Socket ist auf genau solche Signale spezialisiert, während npm audit und in geringerem Maß auch Snyk primär auf dokumentierte Vorfälle reagieren.

Preise im Detail: Was kostet der Schutz wirklich

Für Einzelentwickler und kleine Open-Source-Projekte bleiben alle drei Werkzeuge kostenlos nutzbar. Bei wachsenden Teams und Unternehmenseinsatz unterscheiden sich die Modelle jedoch deutlich, sowohl bei den Limits als auch bei den Zusatzfunktionen, die erst in höheren Plänen freigeschaltet werden.

Tarif	npm audit	Snyk	Socket.dev
Free	0 €, unbegrenzt, in npm integriert	0 $/Monat, 5 Projekte, 100 Snyk-Code-Tests/Monat	0 $/Monat, bis 3 Mitglieder, 1.000 Scans/Monat
Team / mittlerer Tarif	Nicht zutreffend	Ab 25 $ pro Entwickler/Monat, 100 Projekte, 1.000 Tests/Monat	25 $ pro Entwickler/Monat, bis 10 Mitglieder, 5.000 Scans/Monat, Reachability-Analyse
Business / höherer Tarif	Nicht zutreffend	In Enterprise-Tarif integriert	50 $ pro Entwickler/Monat, unbegrenzte Mitglieder und Scans, SBOM-Export
Enterprise	Nicht zutreffend	Individuelles, kreditbasiertes Preismodell	Individuelles Preismodell
Rabatt bei Jahreszahlung	Nicht zutreffend	Abhängig vom Vertrag	Rund 20 % bei Team- und Business-Tarif
Open-Source-Projekte	Immer kostenlos	Kostenlos mit reduzierten Limits	Dauerhaft kostenlos laut Anbieter

Für ein Team mit zehn Entwicklern bedeutet das bei Snyk im Team-Tarif rund 250 US-Dollar monatlich, bei Socket im Team-Tarif ebenfalls rund 250 US-Dollar, allerdings mit doppelt so hohem Scan-Kontingent und der Reachability-Analyse bereits inklusive, die bei Snyk teilweise erst in höheren Tarifstufen verfügbar ist. Wer vor allem SBOM-Exporte für Compliance-Zwecke benötigt, etwa im Rahmen der EU-Richtlinie zur Cyberresilienz, muss bei Socket in den Business-Tarif für 50 US-Dollar pro Entwickler wechseln, während Snyk diese Funktion je nach Vertrag auch im Enterprise-Paket bündelt. npm audit bleibt in jedem Fall kostenlos, liefert aber keine der genannten Zusatzfunktionen.

Für ein größeres Team mit 50 Entwicklern skaliert der Kostenunterschied deutlich stärker. Im Socket-Business-Tarif wären das rund 2.500 US-Dollar monatlich für unbegrenzte Scans, unbegrenzte Mitglieder und vollständigen SBOM-Export. Bei Snyk hängt der Preis für eine vergleichbare Ausstattung stark vom individuell verhandelten Enterprise-Vertrag ab, da das Unternehmen für diese Größenordnung kein öffentliches Preisschema mehr veröffentlicht, sondern auf ein kreditbasiertes Modell umstellt. Für Budgetplanungen bedeutet das in der Praxis: Der Team-Tarif beider Anbieter lässt sich gut vorab kalkulieren, während ab etwa 20 bis 30 Entwicklern ein Gespräch mit dem jeweiligen Vertrieb notwendig wird, um die tatsächlichen Kosten zu ermitteln.

Erkennungsleistung: Was die drei Werkzeuge in der Praxis unterscheidet

Ein sauberer, unabhängiger Benchmark, der Socket, Snyk, npm audit und vergleichbare Scanner wie OSV-Scanner speziell auf die Erkennung neuer Schadpakete testet, existiert nach aktueller Recherche nicht in ausreichend belastbarer Form. Die meisten veröffentlichten Vergleiche messen stattdessen die Abdeckung bekannter CVE-Datenbanken, die Anzahl falsch positiver Treffer oder die Geschwindigkeit der Auflösung von Abhängigkeitsbäumen. Diese Kennzahlen sind nicht gleichzusetzen mit der Fähigkeit, ein frisch kompromittiertes Paket ohne bestehenden CVE-Eintrag zu erkennen.

Belastbarer sind die dokumentierten Reaktionszeiten bei realen Vorfällen. Bei der zweiten Shai-Hulud-Welle veröffentlichte Socket am selben Tag der Entdeckung, dem 24. November 2025, eine detaillierte technische Analyse mit den betroffenen Paketnamen und Versionen unter dem Titel “Shai Hulud Strikes Again (v2)”. Auch Wiz, Aikido und Orca Security veröffentlichten am 24. November 2025 eigene Analysen mit teils abweichenden, aber vergleichbaren Zahlen zur Anzahl betroffener Pakete. Diese Geschwindigkeit ist typisch für Anbieter, deren Geschäftsmodell auf kontinuierlicher Überwachung des Registrierungsverkehrs basiert, im Gegensatz zu klassischen Advisory-Datenbanken, die auf gemeldete und verifizierte Vorfälle warten, bevor ein Eintrag veröffentlicht wird.

Für die Bewertung von npm audit ist wichtig zu verstehen, dass das Tool strukturell nicht für diese Art der Früherkennung gebaut wurde. Es handelt sich um einen Datenbankabgleich, keinen Verhaltensscanner. Ein Sicherheitsteam, das ausschließlich auf npm audit setzt, erfährt von einer Kompromittierung frühestens dann, wenn ein offizielles Advisory veröffentlicht wurde, was bei komplexen, mehrstufigen Angriffen wie Shai-Hulud mehrere Tage dauern kann. In dieser Zeit läuft die Schadsoftware in Produktionsumgebungen weiter, sofern niemand manuell eingreift.

Wie unterschiedlich die Zahlen selbst unter spezialisierten Sicherheitsanbietern ausfielen, zeigt ein Blick auf die am 24. November 2025 veröffentlichten Analysen der zweiten Shai-Hulud-Welle. Die Abweichungen erklären sich vor allem dadurch, dass die Ermittlungen zum jeweiligen Meldezeitpunkt noch liefen und sich die Zahl bestätigter Pakete über mehrere Tage hinweg änderte.

Quelle	Datum der Meldung	Gemeldete Anzahl kompromittierter Pakete
eSentire	24. November 2025	492 Pakete, über 132 Mio. Downloads/Monat
Orca Security	24. November 2025	425 Pakete
Socket	24. November 2025	über 500 Pakete, über 700 Versionen
Wiz	24. November 2025	rund 700 Pakete, über 25.000 Repositories
The Hacker News	26. November 2025	über 830 Pakete, Ausbreitung auf Maven

Diese Schwankungsbreite ist selbst eine wichtige Erkenntnis für die Tool-Auswahl. Wer sich bei einem laufenden Vorfall nur auf eine einzige Quelle oder ein einziges Werkzeug verlässt, riskiert ein unvollständiges Bild der tatsächlichen Reichweite eines Angriffs. Mehrere unabhängige Signale, etwa aus einem Verhaltensscanner und einer klassischen Advisory-Datenbank, ergänzen sich in solchen Situationen besser als ein einzelnes Tool.

GitHub Actions als zweite Angriffsfläche: Warum reine Paket-Scanner nicht reichen

Ein oft übersehener Aspekt der zweiten Shai-Hulud-Welle betrifft nicht die npm-Registry selbst, sondern die CI/CD-Pipelines, über die Pakete gebaut und veröffentlicht werden. Laut der Analyse von Aikido nutzten die Angreifer unsicher konfigurierte GitHub-Actions-Workflows mit den Triggern pull_request_target und workflow_run aus. Beide Trigger führen Workflow-Code mit erweiterten Berechtigungen aus, auch wenn der auslösende Pull Request von einem nicht vertrauenswürdigen externen Beitragenden stammt. Wird ein solcher Workflow unsauber konfiguriert, kann ein Angreifer eigenen Code mit den Rechten des Ziel-Repositorys ausführen lassen, ohne dass ein Maintainer aktiv etwas freigeben muss.

Im konkreten Fall installierte die Schadsoftware zunächst heimlich die Bun-Laufzeitumgebung und registrierte die kompromittierte Maschine anschließend als selbstgehosteten GitHub-Actions-Runner mit dem auffälligen Namen “SHA1HULUD”. Über diesen eigenen Runner konnte der Angreifer weitere Workflow-Läufe im Kontext des betroffenen Repositorys ausführen und mit dem Tool TruffleHog systematisch nach Geheimnissen wie npm-Tokens, GitHub Personal Access Tokens sowie AWS-, Google-Cloud- und Azure-Zugangsdaten suchen. Diese Kombination aus Registry-Angriff und CI/CD-Missbrauch erklärt, warum sich die Kompromittierung so schnell über Tausende Repositories ausbreiten konnte, statt auf die ursprünglich betroffenen Pakete beschränkt zu bleiben.

Für Sicherheitsteams bedeutet das: Ein Paketscanner wie npm audit, Snyk oder Socket deckt ausschließlich die Registry-Seite der Lieferkette ab, nicht die CI/CD-Konfiguration. Wer sich wirksam schützen will, sollte zusätzlich pull_request_target und workflow_run nur mit minimalen Berechtigungen einsetzen, selbstgehostete Runner regelmäßig auf unbekannte Registrierungen prüfen und Workflow-Geheimnisse grundsätzlich zeitlich begrenzt statt dauerhaft gültig ausstellen. Diese Maßnahmen ergänzen die reine Paketprüfung und schließen die Lücke, die keines der drei hier verglichenen Werkzeuge allein abdeckt.

Einordnung in OWASP und regulatorische Rahmenwerke

Kompromittierte Abhängigkeiten fallen fachlich unter die OWASP-Kategorie “Vulnerable and Outdated Components”, die seit Jahren zu den am häufigsten dokumentierten Risikoklassen in Webanwendungen zählt. Anders als bei einer klassischen SQL-Injection oder einem fehlerhaften Zugriffskontrollmechanismus liegt die Schwachstelle hier nicht im eigenen Code, sondern in einer fremden Abhängigkeit, auf deren Sicherheit sich das eigene Team verlassen muss, ohne den Quellcode im Detail zu prüfen. Genau diese Verlagerung des Vertrauens macht die Softwarelieferkette zu einem strukturellen Risiko, das sich nicht allein durch sauberen eigenen Code lösen lässt.

Für deutsche und europäische Unternehmen kommt eine regulatorische Dimension hinzu. Betreiber kritischer Infrastrukturen müssen im Rahmen von NIS-2 und dem nationalen KRITIS-Dachgesetz Nachweise über eingesetzte Softwarekomponenten führen, wofür in der Praxis eine Software Bill of Materials verlangt wird. Ein SBOM allein verhindert keinen Angriff, macht aber im Ernstfall nachvollziehbar, welche Systeme von einem kompromittierten Paket wie im Fall von Shai-Hulud überhaupt betroffen sein könnten. Von den drei hier verglichenen Werkzeugen bietet nur Socket im Business-Tarif und Snyk im Enterprise-Umfeld einen vollständigen SBOM-Export, während npm audit diese Funktion grundsätzlich nicht vorsieht und damit für regulierte Branchen allein nicht ausreicht.

Reale Vorfälle: Fünf Beispiele, an denen sich die Unterschiede zeigen

Die folgenden fünf Beispiele stammen ausschließlich aus dokumentierten, öffentlich nachvollziehbaren Vorfällen und zeigen, wie unterschiedlich sich Angriffe auf die Softwarelieferkette auswirken können.

• CrowdStrike-Namespace, September 2025: Im Rahmen der ersten Shai-Hulud-Welle wurden laut eSentire auch Pakete im CrowdStrike-Namespace kompromittiert, nachdem der npm-Maintainer “qix” am 8. September 2025 Opfer eines Phishing-Angriffs wurde und seine Zugangsdaten verlor.
• debug, chalk und ansi-styles: Diese drei extrem weitverbreiteten npm-Pakete gehörten laut FortiGuard Labs zu den ersten, in denen die Angreifer über den gekaperten Account manipulierte Versionen veröffentlichten. Beide Pakete werden in Millionen von Projekten weltweit als transitive Abhängigkeit genutzt.
• PostHog, November 2025: PostHog bestätigte in einem öffentlichen Post-Mortem, dass die JavaScript-SDKs posthog-node (Versionen 4.18.1, 5.13.3, 5.11.3), posthog-js (1.297.3), posthog-react-native (4.11.1) und posthog-docusaurus (2.0.6) am 24. November 2025 um 4:11 Uhr UTC kompromittiert wurden.
• Zapier und ENS Domains, November 2025: Pakete wie zapier-platform-core und @ensdomains/ens-validation wurden laut Wiz und Orca Security in derselben Angriffswelle infiziert, was zeigt, wie breit gestreut die Kampagne über verschiedene Branchen hinweg war.
• 36 AsyncAPI-Pakete, 24. November 2025: Laut Aikido gehörten 36 Pakete des AsyncAPI-Projekts zur allerersten identifizierten Charge kompromittierter Pakete um 3:16 Uhr UTC, gefolgt von PostHog um 4:11 Uhr und Postman-Paketen um 5:09 Uhr UTC am selben Morgen.

Gemeinsam zeigen diese fünf Fälle, dass Angreifer heute nicht mehr nur unbekannte, selten genutzte Pakete kapern, sondern gezielt Pakete mit hoher Downloadzahl und breiter Verbreitung angreifen, um die Reichweite des Angriffs zu maximieren. Nach Angaben von eSentire erreichten allein die in der zweiten Welle betroffenen Pakete zusammen rund 132 Millionen Downloads pro Monat.

Über npm hinaus: PyPI, Maven und weitere Ökosysteme

Auch wenn dieser Vergleich sich auf npm konzentriert, zeigt gerade der Shai-Hulud-Vorfall, dass sich Lieferketten-Angriffe nicht auf ein einzelnes Ökosystem beschränken. Laut The Hacker News breitete sich die zweite Angriffswelle im November 2025 über kompromittierte npm-Pakete hinaus bis in das Java-Ökosystem Maven aus, weil Projekte häufig beide Paket-Ökosysteme innerhalb derselben Build-Pipeline nutzen und gestohlene Zugangsdaten sich entsprechend breit einsetzen ließen. Für Teams, die neben JavaScript auch Python, Java oder Go einsetzen, ist die Wahl eines Werkzeugs, das mehrere Ökosysteme gleichzeitig abdeckt, deshalb keine Nebensächlichkeit, sondern eine zentrale Anforderung.

Hier zeigt sich der praktische Unterschied zwischen den drei verglichenen Werkzeugen besonders deutlich. npm audit ist von Haus aus strikt auf das npm-Ökosystem beschränkt und lässt sich nicht auf PyPI-, Maven- oder Cargo-Pakete anwenden. Wer in Python arbeitet, müsste stattdessen auf das äquivalente pip-audit zurückgreifen, ein separates Werkzeug mit denselben strukturellen Einschränkungen wie npm audit. Snyk und Socket decken dagegen beide mehrere Ökosysteme über eine einzige Oberfläche ab, was für Unternehmen mit polyglotten Codebasen den Aufwand für Konfiguration, Schulung und Reporting spürbar reduziert, weil nicht für jede Programmiersprache ein eigenes Werkzeug mit eigener Bedienlogik gepflegt werden muss.

Fünf Anwendungsfälle: Welches Tool für welches Team passt

Die richtige Wahl hängt stark davon ab, wie groß das Team ist, wie sensibel die verarbeiteten Daten sind und wie viel Budget für Sicherheitswerkzeuge zur Verfügung steht. Ein Fintech-Startup mit Zugriff auf Zahlungsdaten hat andere Prioritäten als eine Marketing-Agentur, die überwiegend statische Websites ausliefert, auch wenn beide dieselben drei Werkzeuge zur Auswahl haben.

• Solo-Entwickler und kleine Open-Source-Projekte: npm audit reicht für den Einstieg, sollte aber durch die kostenlose Socket-GitHub-App ergänzt werden, da Socket für Open-Source-Projekte dauerhaft kostenlos bleibt und zusätzliche Verhaltenssignale liefert, ohne das Budget zu belasten.
• Startups mit 5 bis 15 Entwicklern: Der Socket-Team-Tarif für 25 US-Dollar pro Entwickler bietet mit Reachability-Analyse und 5.000 Scans pro Monat ein gutes Verhältnis aus Kosten und Abdeckung, besonders wenn das Produkt viele externe Abhängigkeiten nutzt.
• Etablierte Unternehmen mit bestehender SCA-Pflicht: Snyk eignet sich, wenn ohnehin mehrere Produktlinien wie Snyk Code, Container und IaC benötigt werden, da eine einzige Plattform mehrere Compliance-Anforderungen gleichzeitig abdeckt.
• Regulierte Branchen mit SBOM-Pflicht: Unternehmen, die unter das KRITIS-Dachgesetz oder vergleichbare Regularien fallen, sollten den Socket-Business-Tarif oder eine Snyk-Enterprise-Lösung mit vollständigem SBOM-Export in Betracht ziehen, da reines npm audit keine SBOM-Funktionalität bietet.
• Agenturen mit vielen kleinen Kundenprojekten: Eine Kombination aus npm audit als kostenloser Basisebene in jeder CI-Pipeline und Socket als zusätzlicher Pull-Request-Kommentierung für kritische Projekte bietet eine kosteneffiziente Abstufung, ohne für jedes kleine Projekt volle Enterprise-Lizenzen zu benötigen.

Migrationsleitfaden: Von reinem npm audit zu einer mehrschichtigen Absicherung

Teams, die bisher ausschließlich auf npm audit gesetzt haben, sollten die Umstellung schrittweise angehen, statt alle Pipelines an einem Tag umzustellen. Der folgende Ablauf hat sich in der Praxis bewährt.

1. Bestandsaufnahme aller Repositories und package.json-Dateien erstellen, um zu wissen, wie viele Projekte und Abhängigkeiten überhaupt betroffen sind.
2. Kostenlosen Socket-Free-Tarif oder Snyk-Free-Tarif parallel zum bestehenden npm audit aktivieren, ohne bestehende Workflows sofort zu ersetzen.
3. Die GitHub-App des gewählten Tools mit Lesezugriff auf ein Pilot-Repository verbinden und für zwei bis vier Wochen im reinen Beobachtungsmodus laufen lassen.
4. Ergebnisse mit dem Sicherheitsteam sichten und falsch positive Treffer dokumentieren, da Verhaltensanalyse-Tools wie Socket tendenziell mehr Warnungen erzeugen als reine CVE-Abgleiche.
5. Schwellenwerte konfigurieren, ab welchem Risikograd ein Pull Request automatisch blockiert werden soll, statt bei jeder Warnung manuell einzugreifen.
6. Reachability-Analyse aktivieren, damit nur tatsächlich im Code genutzte Funktionen einer verwundbaren Abhängigkeit als kritisch eingestuft werden.
7. CI/CD-Pipeline erweitern, sodass sowohl npm audit als auch das neue Tool bei jedem Build laufen, aber nur das neue Tool über Merge-Blockaden entscheidet.
8. Team-Mitglieder schulen, wie sie Warnungen im Pull-Request-Kommentar lesen und welche Schritte bei einem tatsächlich bösartigen Paket zu unternehmen sind.
9. Rollout auf alle produktiven Repositories ausweiten, priorisiert nach Kritikalität der jeweiligen Anwendung.
10. SBOM-Export einrichten, falls regulatorische Anforderungen wie NIS-2 oder das KRITIS-Dachgesetz dies verlangen.
11. Regelmäßige Reviews der Konfiguration einplanen, da sich sowohl Schwellenwerte als auch die Bedrohungslage laufend verändern.
12. npm audit als kostenlose Zusatzebene beibehalten, da es weiterhin bekannte CVEs schnell und ohne Zusatzkosten aufdeckt, auch wenn es allein nicht mehr ausreicht.

Wichtig ist, dass keines der drei Werkzeuge das andere vollständig ersetzt. Die robusteste Konfiguration kombiniert mindestens zwei Ebenen: eine kostenlose Basisprüfung gegen bekannte Schwachstellen und eine Verhaltensanalyse, die auch unbekannte Risiken markiert.

npm Provenance: Herkunftsnachweis als zusätzliche Schutzebene

Neben den drei zentral verglichenen Werkzeugen lohnt sich ein Blick auf eine Funktion, die npm selbst bereitstellt: Provenance-Attestierungen, die auf dem Open-Source-Projekt Sigstore basieren. Damit kann ein Paket kryptografisch belegen, aus welchem Quellcode-Repository und welchem CI-Workflow es tatsächlich stammt, statt sich allein auf die Angaben in der package.json zu verlassen. Für Teams, die npm audit, Snyk oder Socket einsetzen, ist Provenance keine Konkurrenz, sondern eine sinnvolle Ergänzung: Während die drei verglichenen Werkzeuge den Inhalt eines Pakets auf Schwachstellen oder verdächtiges Verhalten prüfen, bestätigt Provenance die Herkunft des Pakets selbst. Wer beide Ebenen kombiniert, verringert das Risiko, dass ein Angreifer über einen gekaperten Maintainer-Account ein Paket veröffentlicht, dessen Build-Herkunft sich nicht mit dem erwarteten Repository deckt. Ähnliche Signaturmechanismen für Container-Images und andere Artefakte werden auch in separaten Vergleichen von Signierwerkzeugen wie Cosign, Notation und GPG behandelt, die einen verwandten, aber eigenständigen Teil der Software-Lieferkette absichern.

Vor- und Nachteile im direkten Vergleich

npm audit

Vorteile: Kostenlos, ohne Zusatzaccount sofort einsatzbereit, direkt in jede npm-basierte CI-Pipeline integrierbar, keine Datenübertragung an Dritte notwendig.

Nachteile: Erkennt keine Schadpakete ohne veröffentlichtes Advisory, keine Verhaltensanalyse von Install-Skripten, kein SBOM-Export, keine Reachability-Analyse, nur für das npm-Ökosystem nutzbar.

Snyk

Vorteile: Breite Ökosystem-Unterstützung über npm hinaus, zusätzliche Produktlinien für Code, Container und Infrastructure-as-Code, gute IDE-Integration, etablierte Plattform mit langjähriger Marktpräsenz.

Nachteile: Kostenpflichtige Zusatzfunktionen können sich bei mehreren Produktlinien summieren, Fokus liegt stärker auf bekannten Schwachstellen als auf verhaltensbasierter Früherkennung, Enterprise-Preise sind nicht öffentlich einsehbar.

Socket.dev

Vorteile: Verhaltensbasierte Erkennung auch ohne bestehenden CVE-Eintrag, schnelle öffentliche Reaktion bei realen Vorfällen wie Shai-Hulud, dauerhaft kostenlos für Open-Source-Projekte, Reachability-Analyse bereits im Team-Tarif enthalten.

Nachteile: Tendenziell mehr Warnungen, die manuell bewertet werden müssen, SBOM-Export erst im teureren Business-Tarif verfügbar, jüngeres Unternehmen mit kürzerer Erfolgsbilanz als Snyk, Fokus liegt stärker auf Paket-Ökosystemen als auf Container- oder IaC-Sicherheit.

Praxis-Checkliste: Verdächtige Signale bei einem npm-Paket

Unabhängig davon, welches Werkzeug ein Team einsetzt, hilft es, die typischen Warnsignale eines kompromittierten oder böswilligen Pakets selbst zu kennen. Automatisierte Tools decken die meisten dieser Punkte ab, aber ein geschultes Auge erkennt Auffälligkeiten oft schon beim Lesen des package.json oder des Diffs einer neuen Version, bevor überhaupt ein Scan läuft.

• Ein plötzlicher Maintainer-Wechsel bei einem seit Jahren stabilen Paket, ohne nachvollziehbare Ankündigung im zugehörigen Repository.
• Neue oder veränderte preinstall– oder postinstall-Skripte in einer Paketversion, die zuvor keine Installationsskripte enthielt.
• Ein Versionssprung, der weder im Changelog noch in den Git-Tags des zugehörigen Quellcode-Repositorys dokumentiert ist.
• Ungewöhnlich stark obfuskierter oder minifizierter Code in einem Paket, das laut Beschreibung nur eine einfache Hilfsfunktion bereitstellt.
• Netzwerkzugriffe beim Installationsvorgang, obwohl die dokumentierte Funktion des Pakets keinerlei externe Kommunikation erfordert.
• Ein sprunghafter Anstieg der Downloadzahlen in sehr kurzer Zeit, kombiniert mit negativen oder warnenden Kommentaren in verlinkten Issues.
• Fehlende oder gelöschte Zwei-Faktor-Authentifizierung beim Maintainer-Konto, sofern diese Information öffentlich einsehbar ist.

Kein einzelnes dieser Signale beweist für sich genommen einen Angriff. In Kombination, etwa ein neues Installationsskript direkt nach einem Maintainer-Wechsel, sind sie jedoch genau die Muster, auf die verhaltensbasierte Werkzeuge wie Socket automatisiert prüfen, während ein reiner Advisory-Abgleich wie npm audit sie grundsätzlich nicht erfasst.

Grenzen aller drei Ansätze: Was kein Tool allein löst

Kein Werkzeug in diesem Vergleich verhindert, dass ein Entwickler versehentlich ein kompromittiertes Paket manuell installiert, bevor eine Warnung greift. Auch die Reaktionszeit auf neue Kampagnen bleibt begrenzt, selbst bei verhaltensbasierten Ansätzen wie Socket, da Angreifer ihre Techniken kontinuierlich anpassen. Die zweite Shai-Hulud-Welle zeigte zudem, dass sich Angriffe über GitHub-Actions-Workflows ausbreiten können, ein Bereich, den reine Paket-Scanner wie npm audit oder klassische SCA-Tools nur eingeschränkt abdecken. Wer die Softwarelieferkette wirklich absichern will, braucht deshalb zusätzlich sauber konfigurierte CI/CD-Berechtigungen, rotierende Zugangsdaten und ein Monitoring für ungewöhnliche Netzwerkaktivität während des Build-Prozesses, unabhängig davon, welches der drei hier verglichenen Tools zum Einsatz kommt.

Ein weiterer blinder Fleck betrifft die menschliche Ebene. Der erste Shai-Hulud-Angriff begann nicht mit einer technischen Schwachstelle im npm-Registry, sondern mit einem erfolgreichen Phishing-Versuch gegen einen einzelnen Maintainer. Kein Scanner, egal wie ausgefeilt seine Verhaltensanalyse ist, kann verhindern, dass ein legitimer Maintainer seine eigenen Zugangsdaten preisgibt. Genau deshalb betonen sowohl GitHub als auch die hier verglichenen Anbieter unisono, dass technische Tools eine Ergänzung zu organisatorischen Maßnahmen sind, etwa verpflichtender Zwei-Faktor-Authentifizierung für Maintainer-Konten, regelmäßigen Phishing-Schulungen und einer klaren Eskalationsroutine, falls ein Konto kompromittiert wurde. Wer allein auf ein Werkzeug aus diesem Vergleich vertraut und die organisatorische Seite vernachlässigt, schließt nur einen Teil der tatsächlichen Angriffsfläche.

Verdict: Welches Tool sich für welches Budget lohnt

Für die reine Absicherung gegen bekannte, bereits dokumentierte Schwachstellen bleibt npm audit ein solider, kostenloser Startpunkt, der in keiner Pipeline fehlen sollte. Wer jedoch das Risiko von Vorfällen wie Shai-Hulud ernst nimmt, bei denen 500 bis über 800 Pakete kompromittiert wurden, bevor überhaupt ein offizielles Advisory existierte, kommt an einer Verhaltensanalyse nicht vorbei. Hier hat Socket.dev im direkten Vergleich einen klaren Vorteil, weil verdächtiges Paketverhalten unabhängig vom CVE-Status erkannt wird und der Team-Tarif für 25 US-Dollar pro Entwickler bereits die Reachability-Analyse enthält, die bei Snyk teilweise erst in höheren Tarifstufen freigeschaltet wird. Snyk bleibt die richtige Wahl für Unternehmen, die ohnehin eine breite Plattform für Code-, Container- und Infrastructure-Sicherheit unter einem Dach suchen und bereit sind, dafür mehrere Produktlinien zu bezahlen. Die pragmatischste Antwort für die meisten Teams lautet daher: npm audit als kostenlose Grundabsicherung beibehalten und mit Socket oder Snyk als zweite, verhaltens- beziehungsweise kontextbasierte Ebene ergänzen, statt sich auf ein einzelnes Werkzeug zu verlassen.

Kurz zusammengefasst nach Budget: Wer nichts ausgeben kann oder will, fährt mit npm audit plus der kostenlosen Socket-Integration für Open-Source-Projekte am weitesten. Wer bis zu 25 US-Dollar pro Entwickler und Monat investieren kann, bekommt bei Socket im Team-Tarif das derzeit vollständigste Paket aus Verhaltenserkennung und Reachability-Analyse für den Preis. Wer bereits in eine breitere Snyk-Landschaft investiert hat oder mehrere Produktlinien wie Code- und Container-Sicherheit unter einem Vertrag bündeln will, bleibt bei Snyk gut aufgehoben, sollte aber die zusätzlichen Kosten für separate Produktmodule von Anfang an einkalkulieren.

Häufige Fragen zu Socket.dev, Snyk und npm audit

Ist npm audit für den professionellen Einsatz ausreichend?

Für die Erkennung bekannter, bereits gemeldeter Schwachstellen ist npm audit ein brauchbarer und kostenloser Basisschutz. Gegen neue, noch nicht dokumentierte Schadpakete wie in der Shai-Hulud-Kampagne bietet das Tool jedoch keinen zuverlässigen Schutz, weshalb Unternehmen mit sensiblen Produktionsumgebungen zusätzliche Werkzeuge einsetzen sollten.

Was unterscheidet Socket.dev fachlich von Snyk?

Socket konzentriert sich auf Verhaltens- und Risikosignale einzelner Pakete, etwa verdächtige Install-Skripte oder ungewöhnliche Netzwerkzugriffe, während Snyk breiter als Plattform für Software Composition Analysis mit Zusatzprodukten für Code-, Container- und Infrastructure-Sicherheit positioniert ist.

Kann man mehrere dieser Tools gleichzeitig einsetzen?

Ja, viele Sicherheitsteams kombinieren npm audit als kostenlose Basisebene mit einem der beiden kommerziellen Anbieter als zweite, tiefergehende Prüfschicht. Da die Tools unterschiedliche Erkennungsprinzipien nutzen, ergänzen sie sich eher, als dass sie sich überschneiden.

Was war der Shai-Hulud-Wurm genau?

Shai-Hulud war ein selbstverbreitendes npm-Schadprogramm, das in zwei Wellen im September und November 2025 auftrat. Es stahl npm-, GitHub- und Cloud-Zugangsdaten über kompromittierte Paket-Installationsskripte und nutzte diese Zugangsdaten, um sich automatisch auf weitere Pakete und Repositories auszubreiten.

Lohnt sich Socket oder Snyk auch für kleine Teams?

Beide Anbieter bieten kostenlose Tarife mit Limits an, die für kleine Teams oder Open-Source-Projekte ausreichen können. Erst bei wachsender Projektzahl oder dem Bedarf an Funktionen wie Reachability-Analyse oder SBOM-Export wird ein kostenpflichtiger Tarif relevant.

Erkennt npm audit auch Schwachstellen in PyPI- oder Maven-Paketen?

Nein, npm audit ist ausschließlich auf das npm-Ökosystem beschränkt. Wer mehrere Programmiersprachen und Paket-Ökosysteme im selben Unternehmen absichern muss, benötigt ein Werkzeug wie Snyk oder Socket, das mehrere Ökosysteme gleichzeitig abdeckt.

Welche Rolle spielt eine SBOM-Pflicht bei der Tool-Auswahl?

Unternehmen, die regulatorisch zur Erstellung einer Software Bill of Materials verpflichtet sind, etwa im Rahmen von NIS-2 oder dem KRITIS-Dachgesetz, sollten frühzeitig prüfen, ob der gewählte Tarif einen SBOM-Export enthält. Bei Socket ist diese Funktion erst im Business-Tarif verfügbar, bei npm audit gar nicht vorhanden.

Wie schnell reagieren die Anbieter auf neue Angriffswellen?

Bei der zweiten Shai-Hulud-Welle veröffentlichten Socket, Wiz, Aikido und Orca Security ihre technischen Analysen noch am selben Tag der Entdeckung, dem 24. November 2025. Diese Geschwindigkeit ist typisch für Anbieter mit kontinuierlicher Registry-Überwachung, während klassische Advisory-Datenbanken oft mehrere Tage bis zur Veröffentlichung benötigen.