„Die Dependencies sind doch sicher, oder?“ Ein Satz, den wir nach über 15 Jahren Erfahrung in Softwarequalität, Open Source und Remote Consulting leider viel zu oft hören. Die neue Angriffswelle durch Shai-Hulud 2 zeigt eindrucksvoll: NPM Supply Chain Attacks haben eine neue Dimension erreicht. Über 425 kompromittierte Pakete mit mehr als 100 Millionen Downloads monatlich – darunter prominente Namen wie Zapier, Postman und AsyncAPI. Was ihr jetzt wissen und tun müsst, um eure Projekte zu schützen.
Die Realität: Ein Wurm, der aus seinen Fehlern lernt
Shai-Hulud 2 ist keine gewöhnliche Malware. Die Angreifer haben aus der ersten Welle gelernt und zentrale Schwachstellen beseitigt. Statt auf externe Webhook-Plattformen zu setzen, nutzt der Wurm nun GitHub selbst als Command-and-Control-Server. Die Zugangsdaten werden direkt in GitHub-Repositories hochgeladen – unter dem Titel „Sha1-Hulud: the Second Coming“. Diese Transparenz ist gewollt: Sie macht die Daten für die Angreifer einfach auffindbar, während GitHub gegen Windmühlen kämpft und über 27.800 kompromittierte Repositories entfernen muss.
Warum gerade Low-Code-Plattformen im Visier stehen
Low-Code-Plattformen wie Zapier, n8n oder Postman haben eines gemeinsam: Sie integrieren NPM-Pakete für ihre Workflows und Automation-Features. Diese Pakete laufen oft mit erhöhten Berechtigungen und haben Zugriff auf sensible API-Keys, Cloud-Credentials und Kundendaten. Für Angreifer ist das ein Jackpot.
Die betroffenen Pakete zeigen ein klares Muster: API-Clients (@postman/, @zapier/), Workflow-Tools (@asyncapi/*), und Entwickler-SDKs. Genau die Werkzeuge, die Teams nutzen, um schneller zu entwickeln – ohne dabei die Security-Implikationen zu durchdenken.
Die 10 wichtigsten Fragen zu Shai-Hulud 2 – direkt beantwortet
1. Wie erkenne ich, ob meine Dependencies kompromittiert sind?
Der erste Schritt ist eine Bestandsaufnahme. Nutzt npm ls in eurem Projekt, um alle Dependencies inklusive transitiver Abhängigkeiten zu sehen. Für Production-Dependencies verwendet npm ls --prod --long – das zeigt euch genau, was tatsächlich in Production läuft.
Prüft eure package-lock.json oder yarn.lock gegen die Liste der kompromittierten Pakete. GitHub hat bereits begonnen, Repositories zu entfernen, aber neue Varianten tauchen täglich auf. Tools wie Snyk oder npm audit helfen bei der automatischen Erkennung, aber verlasst euch nicht blind darauf – manuelle Code-Reviews bleiben essentiell.
Praktischer Tipp: Erstellt ein Script, das eure Lock-Files täglich gegen bekannte Malware-Signaturen prüft. In unseren Consulting-Projekten haben wir damit bereits mehrere Zero-Day-Kompromittierungen früh erkannt.
2. Warum sind Post-Install-Scripts das Hauptrisiko?
Post-Install-Scripts sind die Achillesferse von NPM. Sie werden automatisch ausgeführt, sobald ihr npm install lauft – mit denselben Berechtigungen wie euer User. Shai-Hulud 2 nutzt genau diesen Mechanismus, um sich zu verbreiten und Credentials zu stehlen.
Die Lösung: Verwendet npm install --ignore-scripts oder wechselt zu pnpm, das Scripts standardmäßig deaktiviert. Ja, manche Pakete benötigen Post-Install-Scripts legitim – aber die sind seltener als ihr denkt. In über 90% unserer Projekte liefen alle Dependencies einwandfrei ohne Scripts.
Best Practice: Erstellt eine Whitelist für Pakete, die Scripts wirklich brauchen. Alles andere: geblockt.
3. Was mache ich, wenn ich ein kompromittiertes Paket installiert habe?
Sofortmaßnahmen sind kritisch:
- Alle Credentials rotieren: GitHub Personal Access Tokens, npm Tokens, Cloud-Credentials (AWS, GCP, Azure), API-Keys von Drittdiensten
- Caches leeren: Auf Developer-Maschinen, CI/CD-Servern und Artifact-Registries
- Logs prüfen: Sucht nach ungewöhnlichen Netzwerk-Verbindungen, besonders zu GitHub-APIs
- Dependencies zurücksetzen: Installiert nur bekannt sichere Versionen
Unser Incident-Response-Playbook aus über 15 Jahren Consulting: Geht davon aus, dass alles kompromittiert ist. Paranoia schützt besser als Hoffnung.
4. Wie schütze ich meine CI/CD-Pipeline vor NPM-Angriffen?
CI/CD-Pipelines sind Goldgruben für Angreifer – sie haben Zugriff auf Production-Secrets und Deploy-Berechtigungen. Drei essenzielle Schritte:
Lock-Files verbindlich machen: Nutzt npm ci statt npm install in CI. npm ci installiert exakt die Versionen aus der Lock-File und wirft einen Error bei Diskrepanzen.
# GitHub Actions Example
- name: Install dependencies
run: npm ci --ignore-scriptsIntegrity Checks aktivieren: Verifiziert Checksums von Downloads. Moderne Package-Manager unterstützen das, aber es muss aktiviert sein.
Separate Credentials: CI-Pipelines brauchen eigene, limitierte Credentials – niemals die gleichen wie Developer verwenden.
5. Warum trifft es ausgerechnet jetzt Low-Code-Plattformen?
Das Timing ist kein Zufall. Am 9. Dezember 2025 schafft npm Classic Tokens ab – eine lange angekündigte Security-Verbesserung. Die Angreifer wollten offensichtlich noch schnell zuschlagen, bevor diese Lücke geschlossen wird.
Low-Code-Plattformen sind attraktive Ziele, weil sie:
- NPM-Pakete mit erhöhten Rechten ausführen
- Zugriff auf Multi-Tenant-Umgebungen haben
- Oft von Citizen Developers ohne Security-Training genutzt werden
- API-Integrationen zu sensiblen Systemen bieten
Entscheider-Perspektive: Wenn euer Team Low-Code nutzt, braucht ihr dringend Security-Guidelines und Dependency-Scanning. Die Entwicklungsgeschwindigkeit bringt nichts, wenn dabei die Hintertür offen bleibt.
6. Wie unterscheidet sich Shai-Hulud 2 von normaler Malware?
Der entscheidende Unterschied: Selbstreplikation. Normale Malware kompromittiert ein System. Shai-Hulud 2 kompromittiert ein Paket, stiehlt die NPM-Credentials des Maintainers und infiziert automatisch weitere Pakete.
Die Automatisierung ist der Game-Changer. Ein einzelner kompromittierter Maintainer-Account kann hunderte Pakete infizieren, ohne dass der Angreifer manuell eingreifen muss. Das skaliert exponentiell.
GitHub-Workflows sorgen für Backdoors auf infizierten Maschinen, während ein zweiter Workflow Secrets abgreift und als JSON hochlädt. Command-and-Control läuft über GitHub Discussions – selbst-gehostet und schwer zu blockieren.
7. Welche Alternative zu npm install gibt es wirklich?
Die beste sofort umsetzbare Alternative: pnpm. Der Package-Manager arbeitet nach dem „Default-Deny“-Prinzip – Scripts sind standardmäßig deaktiviert und müssen explizit freigeschaltet werden.
# Migration zu pnpm
npm install -g pnpm
pnpm import # importiert package-lock.json
pnpm install # installiert ohne Scriptspnpm zeigt euch klar, welche Scripts es übersprungen hat. Ihr könnt dann gezielt einzelne Scripts aktivieren:
pnpm install --config.scripts-whitelist="package-name"Realität aus der Praxis: In über 90% unserer Projekt-Migrationen zu pnpm funktionierte alles sofort ohne manuelle Script-Freigaben.
8. Wie gehe ich mit alten, ungepflegten Dependencies um?
Ungepflegte Pakete sind Zeitbomben. Die Security-Community empfiehlt: Nutzt nur Pakete, die älter als 60 Tage sind (für neue Pakete) und aktiv gepflegt werden.
Tools wie depcheck finden ungenutzte Dependencies in eurem Projekt:
npx depcheckEntfernt alles, was ihr nicht aktiv nutzt. Weniger Dependencies = kleinere Angriffsfläche. In unseren Security-Audits finden wir regelmäßig 20-30% ungenutzter Dependencies.
Pragmatischer Ansatz: Manchmal ist ein triviales Package kopieren besser als eine neue Dependency. Ja, die NPM-Community hasst diesen Rat – aber Golang-Entwickler finden ihn offensichtlich. Code-Duplikation ist kein Todessünde, wenn sie Security erhöht.
9. Welche Rolle spielen Lockfiles wirklich für Security?
Lockfiles sind euer erster Security-Layer. package-lock.json oder pnpm-lock.yaml fixieren exakte Versionen inklusive aller transitiven Dependencies. Ohne Lockfile zieht npm install bei jeder Ausführung potenziell neue Versionen – unkontrolliert und ungeprüft.
Critical: Committed eure Lockfiles in Git. Verwendet in CI ausschließlich npm ci oder pnpm install --frozen-lockfile. Diese Commands werfen Errors bei Abweichungen statt still neue Versionen zu ziehen.
Floating Ranges (^, ~, latest) in package.json mögen bequem erscheinen, aber sie sind Security-Albträume. Pinnt eure Dependencies auf exakte Versionen.
10. Was bedeutet das konkret für mein Team und unsere Projekte?
Die Auswirkungen hängen von eurem Setup ab:
Für Developer-Teams: Sofort alle npm Tokens rotieren, CI/CD-Secrets prüfen, Dependencies scannen. Plant Zeit für Security-Reviews ein – nicht als Nice-to-have, sondern als Business-Critical.
Für Entscheider: Die Kosten eines Incidents übersteigen die Kosten von Prevention um Größenordnungen. Ein kompromittiertes System kann euren gesamten Cloud-Account übernehmen. Budget für Security-Tools und Training ist keine Option, sondern Notwendigkeit.
Für Low-Code-User: Prüft, welche NPM-Pakete eure Plattform nutzt. Fragt euren Vendor nach Security-Prozessen. Implementiert Monitoring für ungewöhnliche API-Aktivitäten.
Konkrete Schutzmaßnahmen für sofort
Basierend auf unserer Consulting-Erfahrung: Diese Maßnahmen könnt ihr heute umsetzen:
Dependency-Scanning aktivieren: Integriert Snyk, Dependabot oder ähnliche Tools in eure CI/CD. Automatisierte Checks bei jedem Pull Request.
SBOM (Software Bill of Materials) erstellen: Dokumentiert alle Dependencies. Tools wie Syft oder CycloneDX machen das automatisch.
Least Privilege für npm Tokens: Nutzt granulare Tokens statt Classic Tokens. Limitiert Scope und Laufzeit.
Trusted Publishing: GitHub Actions können direkt an npm publizieren ohne Tokens. npm und GitHub haben das Feature speziell als Reaktion auf Shai-Hulud entwickelt.
60-Tage-Rule: Neue Pakete mindestens 60 Tage abwarten bevor ihr sie nutzt. Gibt der Community Zeit, Probleme zu finden.
Code-Reviews für Dependencies: Nicht nur euren Code reviewen – auch Dependencies durchsehen, besonders bei Updates.
Die Business-Perspektive: Warum das Entscheider interessieren muss
Ein kompromittiertes npm Paket kann:
- Kundendaten exfiltrieren
- Cloud-Accounts übernehmen
- Supply-Chain-Angriffe auf eure Kunden durchführen
- Compliance-Verstöße verursachen (GDPR, SOC2, etc.)
- Euren Ruf nachhaltig schädigen
Die Kosten: Im Durchschnitt kostet ein Data Breach 4,35 Millionen Dollar (IBM Security Report). Die Kosten für präventive Maßnahmen: Ein Bruchteil davon.
ROI von Security-Investment: Jeder Euro in Prevention spart durchschnittlich 10 Euro in Incident Response. Unsere Erfahrung aus Dutzenden Projekten bestätigt das.
Was GitHub und npm jetzt tun
GitHub hat reagiert: Über 500 kompromittierte Pakete wurden entfernt, neue Packages mit bekannten IoCs (Indicators of Compromise) werden blockiert. Classic Tokens werden ab 9. Dezember deaktiviert.
Aber: Die Angreifer passen sich an. Neue Varianten tauchen täglich auf. Trusted Publishing ist verfügbar, aber die Adoption verläuft schleppend. npm hatte geplant, die Akzeptanz organisch wachsen zu lassen – Shai-Hulud hat diese Pläne durchkreuzt.
Die Message: Vendor-Security ist wichtig, aber nicht ausreichend. Ihr müsst eure eigenen Defenses aufbauen.
Eure nächsten Schritte
- Heute: Prüft eure Dependencies gegen die kompromittierte Pakete-Liste
- Diese Woche: Rotiert alle Credentials, aktiviert Dependency-Scanning
- Diesen Monat: Migriert zu pnpm oder implementiert
--ignore-scripts - Dieses Quartal: Etabliert Security-Guidelines für Dependencies, schult euer Team
Direkte Unterstützung für eure Projekte
Ihr braucht Hilfe bei der Absicherung eurer NPM-Dependencies? Oder wollt ihr ein Security-Audit für eure Supply Chain? Mit über 15 Jahren Expertise in Softwarequalität, Open Source und Remote Consulting unterstützen wir euch bei:
- Security-Audits eurer Dependencies
- Implementation von Dependency-Scanning in CI/CD
- Migration zu sicheren Package-Manager-Setups
- Incident Response bei Kompromittierungen
- Team-Training zu Supply Chain Security
Kontakt: roland@nevercodealone.de
Gemeinsam schaffen wir sichere Development-Workflows – keine theoretischen Konzepte, sondern bewährte Lösungen aus der Praxis.
Fazit: Security ist keine Einmal-Aktion
Shai-Hulud 2 zeigt brutal klar: NPM Supply Chain Security ist kein Nice-to-have mehr. Die Angreifer werden besser, die Automatisierung nimmt zu, und die Blast-Radius wächst.
Aber: Ihr seid nicht hilflos. Die Werkzeuge existieren, die Best Practices sind bekannt, und die Community arbeitet an Lösungen. Was fehlt, ist konsequente Umsetzung.
Startet heute. Prüft eure Dependencies. Aktiviert Scanning. Rotiert Credentials. Jeder Schritt macht euer Projekt sicherer.
Never Code Alone – Gemeinsam für bessere Software-Qualität!
