Die Security-Checkliste, die jeder Entwickler vor dem npm-Publish durchgehen sollte

Wer Open-Source-Pakete baut oder Code über npm verteilt, bewegt sich in einem Umfeld, in dem sich Angreifer in den letzten Monaten besonders kreativ gezeigt haben. „Es läuft bei mir“ reicht heute nicht mehr aus. Ein Paket kann schnell in tausende Projekte gelangen – und damit auch in sensible Build-Pipelines.

Wer verantwortungsvoll publizieren will, braucht daher eine klare Vorab-Prüfung.

Warum Pakete vor der Veröffentlichung auf Security geprüft werden sollten

npm ist gleichzeitig einer der größten Vorteile und eine der größten Schwachstellen des JavaScript-Ökosystems. Ein einziges Paket kann in unzählige Anwendungen und CI/CD-Prozesse fließen. Genau das macht es für Angreifer interessant. Sie nutzen Pakete nicht nur, um Zugangsdaten zu stehlen, sondern auch, um in Build-Umgebungen dauerhaft Fuß zu fassen.

Die gute Nachricht: Die meisten Angriffe lassen sich vermeiden – mit Disziplin und den richtigen Werkzeugen.

Die 12 wichtigsten Angriffsvektoren bei npm-Paketen

1. Account-Übernahme und gezielte Schadcode-Veröffentlichung

Wird ein npm-Account geknackt, riskiert der Entwickler, dass ein Angreifer eine manipulierte Version seines Pakets veröffentlicht. Die Nutzer installieren sie automatisch – und der Schadcode läuft in Produktionsumgebungen.

So schützt du dich:

• 2FA auf dem npm-Account aktivieren (Pflicht)
• Feingranulare Access-Tokens statt des Hauptpassworts verwenden
• Veröffentlichungs-Freigaben für kritische Pakete einrichten
• Veröffentlichungsprotokolle regelmäßig kontrollieren

2. Lifecycle Hooks – wenn die Installation zum Code-Aufruf wird

npm erlaubt preinstall- und postinstall-Hooks. Ein Angreifer, der ein Paket kontrolliert, kann dadurch schon beim Installationsvorgang beliebigen Code laufen lassen.

Mitigationsmaßnahmen:

• Jede Lifecycle-Hook in der package.json prüfen
• Überlegen, ob man Hooks wirklich braucht
• Hooks möglichst einfach und transparent gestalten
• Besser auf Build-Zeit statt Installationszeit ausweichen

3. Selbstreplizierende npm-Würmer

Manche Angriffe modifieren andere Pakete im node_modules-Ordner und verbreiten sich so über den Dependency-Baum. Diese Art Viren ist besonders heimtückisch.

So verteidigst du dich:

• Keine Änderungen am Dateisystem zur Installationszeit
• Andere Pakete nicht anfassen
• Dependencies sauber isolieren
• npm audit und Dependency-Scanner regelmäßig nutzen

4. Angriffe auf die CI/CD-Identitäts-Schicht

In CI/CD-Pipelines stecken oft sensible Credentials. Ein Paket, das in den Build-Prozess gelangt, kann Zugriff auf diese Tokens nehmen.

Schutz durch Defense-in-Depth:

• Nur minimal benötigte, eingeschränkte Credentials pro Schritt verwenden
• Tokens regelmäßig austauschen
• Keine Credentials in package.json-Skripten fest verdrahten
• OpenID Connect für die Paket-Authentifizierung in Betracht ziehen
• Wer Zugriff auf Publish-Secrets hat, sollte regelmäßig überprüft werden

5. Git-basierte Dependency-Schmuggel

Wird eine Dependency direkt aus einem Git-Repo gezogen, umgeht der Entwickler die Kontrollen des npm-Registers. Attacker können so einen bösen Fork aus tricken.

Gegenmaßnahmen:

• Dependencies lieber auf npm-Registry-Versionen festlegen als auf Git-Repos
• Bei Git-Dependencies unbedingt den Commit-Hash festlegen
• „latest“ und Zweig-Referenzierungen von ungesicherten Repos nicht verwenden
• Begründen, warum man eine Git-Dependency wirklich braucht

6. Dynamisch geladene Dependencies

Manche Pakete laden zur Laufzeit weiteren Code nach. 这 schafft eine unsichtbare Attack-Surface, whereby die Pakete nur noch als Loader dienen.

Best Practices:

• Alle Dependencies statisch in die package.json eintragen
• Code nicht dynamisch nachladen und ausführen
• Static Analysis Tools verwenden, um dynamische Requires zu erkennen
• Bei Bedarf nach Flexibilität ohne Code-Au<|eos|>