NPM stärkt die Sicherheit mit Ephemeral-Token und OIDC, aber die Lieferkette ist immer noch gefährdet

Im Dezember 2025 hat npm eine tiefgreifende Änderung seines Authentifizierungssystems angewendet, um das Risiko von Supply Chain-Angriffen zu reduzieren: es hat die sogenannten "klassischen Token" aufgehoben und Sitzungstoken und OIDC-basierte Ströme gefördert. Es ist eine signifikante Verbesserung der Standardverteidigungen, aber es nicht vollständig die Möglichkeit eines böswilligen Schauspieler veröffentlichen schädlichen Code.

Seit Jahren war die Basis des Problems einfach: die alten Anmeldeinformationen waren lang gültig, mit einem breiten Spektrum, und wenn sie in die falschen Hände fielen, durften sie neue Versionen von Paketen veröffentlichen, ohne die Quelle des Codes beweisen zu müssen. Dieses Modell machte npm ein attraktives Ziel für diejenigen, die versuchen, Malware direkt in hochverwendete Bibliotheken einfügen. Gut dokumentierte Vorfälle im Ökosystem haben gezeigt, wie engagierte Anmeldeinformationen ausreichen, um große und schnelle Schäden zu verursachen.

Die npm-Reaktion konzentrierte sich auf drei Ideen: kurzes Ablauf von interaktiven Anmeldeinformationen, besseres Tokenmanagement und die Förderung der Verwendung von Identitäten, die mit CI-Ausführungen über OIDC verbunden sind. Sie können die offizielle Erklärung dieser Änderungen in der npm-Team-Anzeige lesen Hier.. In der Praxis bedeutet dies, dass für den normalen Betrieb interaktive Token schnell ablaufen und Publikationen eine Multifaktor-Authentifizierung erfordern können.

Die reale Sicherheit hängt jedoch von technischen Verbesserungen ab und wie Menschen und Geräte sie nutzen. Zwei Schlüsselpunkte öffnen noch die Tür zu Angriffen. Erstens bleiben Phishing-Angriffe, die auf Multifaktor-Authentifizierung abzielen, wirksam: Wenn ein Betreuer falsch geführt wird und sein Passwort und einen zweiten Faktorcode liefert, kann ein Angreifer einen gültigen Session-Token erhalten und eine bösartige Version innerhalb von Minuten veröffentlichen.

Zweitens erlaubt die Plattform weiterhin den Gedankenfluss für die Automatisierung, die, wenn sie mit MFA-Bypass oder Langzeit-Token (z.B. 90-Tage-Tokens) konfiguriert ist, das bisherige Problem im Wesentlichen wiedererlangen. Das heißt, die Existenz von permanenten Token oder mit weggelassenem MFA behält einen wichtigen Risikovektor bei, wenn diese Geheimnisse in CI / CD-Systemen gespeichert oder freigelegt werden.

Dies führt zu einem praktischen Schluss: npm Verbesserungen reduzieren das Belichtungsfenster und erhöhen die Schwierigkeit für den Angreifer, aber nicht beseitigen. Solange es Wege gibt, persistente Anmeldeinformationen zu generieren oder einen Menschen zu täuschen, um Anmeldeinformationen einer einzigen Verwendung zu liefern, wird es immer ein unbefugtes Veröffentlichungsrisiko geben.

Im Hinblick auf die Minderung sollten drei komplementäre Arbeitslinien gefördert werden. Die erste ist die breite Annahme von ODO in den CI-Integrationen; Verwendung von Token, die mit einer bestimmten und sehr kurzlebigen Ausführung verbunden sind, reduziert drastisch das Nutzen jedes gestohlenen Geheimnisses. GitHub bietet Dokumentation darüber, wie OIDC für Implementierungen konfiguriert werden kann, die als praktische Referenz dienen können: OIDC in GitHub Aktionen setzen.

Die zweite Zeile besteht darin, die MFA-Richtlinien zu verschärfen und Ausnahmen zu minimieren: Es ist nicht möglich, Token zuzulassen, um den zusätzlichen Faktor für die Veröffentlichung von Operationen zu vermeiden und MFA auf der Konsole zu zwingen, die Möglichkeit zu verringern, dass ein Phishing ausreicht, um Code zu veröffentlichen. Die von Agenturen wie CISA veröffentlichten Leitlinien zur Phishing-Prävention und zur guten Authentifizierung helfen zu verstehen, warum auch Nutzer mit MFA Opfer werden können, wenn keine zusätzlichen Kontrollen kombiniert werden: Empfehlungen zum Phishing (CISA).

Die dritte Linie geht über die Authentisierung hinaus: reexaminieren Sie, wie die Artefakte unsere Umgebung erreichen. Wenn wir anstelle des Herunterladens von vorkompilierten Paketen aus der Registry jede Einheit aus Ihrem verifizierbaren Quellcode rekonstruieren, ist das Risiko, dass eine freigegebene Version mit Malware unsere Lieferketten erreichen wird viel reduziert. Eine praktische Untersuchung von Chainguard behauptet, dass in seiner öffentlichen Datenbank der engagierten Pakete die meisten der untersuchten Fälle gezeigt Malware nur im veröffentlichten Paket, nicht im vorgelagerten Quellcode. Sie können diese Analyse auf der Chainguard Website überprüfen: Chainguard: Malware in npm mildern.

Dieses "Rekonstruieren von der Quelle"-Ansatz ist nicht trivial: es beinhaltet Investitionen in Reproduzierbarkeit, Unterschrift von Artefakten und Ketten von Vertrauen, aber hat einen spürbaren Effekt auf die Verringerung der Angriffsfläche. Werkzeuge und Dienstleistungen, die überprüfbare Bibliotheken zur Verfügung stellen, können in ein vertieftes Verteidigungsmodell passen, das strenge Zugangsrichtlinien, Audit und Überprüfung in der Zeit der Umsetzung kombiniert.

Am Ende wird darauf hingewiesen, dass es keine einzige wundersame Lösung gibt. Effektive Sicherheit ist eine Summe von Schichten: gute Praxis bei der Verwaltung von Anmeldeinformationen, weit verbreitete Verwendung von OIDC für die Automatisierung, obligatorische MFA in sensiblen Aktionen und, soweit möglich, überprüfte Rekonstruktion von Geräten aus der Quelle. Jede Maßnahme reduziert das verbleibende Risiko der anderen.

Für Projekte und Organisationen bedeutet dies konkrete Entscheidungen: Token zu überprüfen und zu drehen, MFA zu aktivieren und um Bypass Ausnahmen zu entfernen, Pipelines nach OIDC zu migrieren, wenn möglich, und die Annahme von Repositorien oder Dienstleistungen, die sicherstellen, dass das installierte kommt aus dem geprüften Quellcode. Praktische Empfehlungen und öffentliche Anleitungen - wie GitHubs für OIDC oder Vorfallanalyse von Sicherheitsanbietern - sind nützliche Ressourcen für die Planung dieses Übergangs.

npm hat sich in die richtige Richtung bewegt, indem die Standardrichtlinien geändert und entsprechende Anmeldeinformationen eliminiert werden. Trotzdem. solange menschliche Vektoren (Phishing) existieren und die Möglichkeit, langfristige Token zu erzeugen, bleibt die Bedrohung über die Lieferkette. Am sinnvollsten für die Gemeinschaft ist es, Verbesserungen in der Plattform mit Veränderungen der Prozesse und bei der Annahme von Technologien zu kombinieren, die die Barriere für einen Angreifer erhöhen, bis die Nutzung des Systems nicht mehr rentabel ist.

Wenn Sie den Hintergrund und konkrete Fälle vertiefen möchten, wie die in der Vergangenheit begangenen Anmeldeinformationen verwendet wurden, bietet Snyk eine informative Analyse des Zwischenfalls "event-stream", eines der am meisten zitierten Beispiele des JavaScript-Lieferkettenangriffs: Analyse des Ereignisstroms (Snyk). Und wenn Sie an der Erkundung von technischen Alternativen interessiert sind, die sich auf den Aufbau von Artefakten aus der Quelle konzentrieren, erklärt Chainguards Dokumentation zu seinen JavaScript-Bibliotheken diesen Ansatz mit Beispielen und Daten.

Abschließend sei daran erinnert, dass dieser Artikel auf der Arbeit und Analyse der technischen Gemeinschaft basiert. Die Empfehlungen beabsichtigen nicht, zu beunruhigen, sondern in Aussicht zu stellen, dass die npm-Verbesserungen das Risiko reduzieren, aber nicht verschwinden, und dass die effektivste Antwort darauf ist, technische Kontrollen mit Betriebshygiene und Quellenkontrolle zu kombinieren.