npm bietet für granulare Zugriffstokens nun die Berechtigung „Read and write (stage only)“. Automatisierte Workflows dürfen damit eine Paketversion zur Prüfung bereitstellen, aber nicht direkt in der npm Registry veröffentlichen. Die endgültige Freigabe übernimmt ein Maintainer mit Zwei-Faktor-Authentifizierung. Für Unternehmen ist das ein praktikabler Übergang von dauerhaften Publishing-Geheimnissen zu einem Prozess, der Automatisierung und menschliche Freigabe bewusst trennt.
Was Stage-only-Tokens technisch ändern
Nach der offiziellen GitHub-Mitteilung verwendet die Pipeline mit einem Stage-only-Token den Befehl „npm stage publish“. Ein direkter Versuch über „npm publish“ wird mit diesem Token abgewiesen – auch dann, wenn das Token für Automatisierung mit einer 2FA-Ausnahme konfiguriert wurde. Eine berechtigte Person prüft die bereitgestellte Version und genehmigt die Veröffentlichung anschließend mit 2FA. Die Funktion ist optional und verändert bestehende Tokens zunächst nicht.
- Bestätigt: Das Token darf Paketversionen bereitstellen, aber nicht unmittelbar veröffentlichen.
- Bestätigt: Ein Maintainer muss die bereitgestellte Version prüfen und per 2FA freigeben.
- Bestätigt: Stage-only-Tokens behalten weitere Schreibrechte, darunter das Verschieben von Dist-Tags und das Deprecaten von Versionen.
- Bestätigt: Staged Publishing funktioniert für bestehende npm-Pakete.
- Bestätigt: Erforderlich sind Publish-Zugriff, aktivierte 2FA, npm CLI ab 11.15.0 und Node.js ab 22.14.0.
Warum Unternehmen vor Januar 2027 handeln sollten
npm plant laut der Mitteilung, direkte Veröffentlichungen über Tokens mit 2FA-Bypass im Januar 2027 zu beenden. Stage-only-Tokens sind ausdrücklich als Migrationspfad gedacht, wenn Trusted Publishing noch nicht möglich ist. Daraus folgt kein Zwang, jede Organisation sofort auf diesen Token-Typ umzustellen. Es folgt aber ein klarer Planungsbedarf: Teams sollten ermitteln, welche Pipelines noch dauerhaft hinterlegte Publishing-Tokens nutzen und ob sie zu Trusted Publishing oder zunächst zu Staged Publishing wechseln.
Der betriebliche Vorteil liegt in der Gewaltenteilung. Eine kompromittierte CI-Pipeline kann eine vorbereitete Version erzeugen, aber nicht allein den finalen Release abschließen. Das reduziert den direkten Veröffentlichungsweg eines gestohlenen Tokens. Vollständig beseitigt ist das Lieferkettenrisiko nicht: Manipulierter Quellcode, Build-Artefakte, Dist-Tags oder Deprecation-Aktionen bleiben gesondert zu kontrollieren. Aussagen zu konkreten Schadens- oder Kostensenkungen enthält die Quelle nicht.
Migrationsplan in sechs Schritten
- Inventar erstellen: Alle npm-Pakete, Release-Workflows, Token-Eigentümer, Secret Stores und 2FA-Bypass-Konfigurationen erfassen.
- Zielpfad wählen: Pro Pipeline prüfen, ob Trusted Publishing bereits passt oder Stage-only als zeitlich begrenzte Zwischenstufe benötigt wird.
- Voraussetzungen aktualisieren: Test-Runner auf mindestens npm CLI 11.15.0 und Node.js 22.14.0 bringen, ohne ungeprüft die gesamte Produktions-Toolchain anzuheben.
- Token begrenzen: Ein granulares Stage-only-Token nur für die tatsächlich benötigten Pakete erstellen, sicher hinterlegen und das bisherige Token parallel noch nicht löschen.
- Workflow umstellen: „npm publish“ durch „npm stage publish“ ersetzen, Staging-Ergebnis protokollieren und eine benannte Maintainer-Gruppe für die 2FA-Freigabe definieren.
- Pilot und Abschaltung: Testpaket beziehungsweise risikoarmes Paket vollständig durchlaufen lassen, Rückweg prüfen und alte Publishing-Tokens nach erfolgreicher Abnahme widerrufen.
Der Parallelbetrieb sollte kurz und dokumentiert bleiben. Sonst existiert neben dem neuen Freigabeweg weiterhin ein altes Token mit direkter Publishing-Berechtigung und der Sicherheitsgewinn bleibt theoretisch. Für kritische Pakete empfiehlt sich außerdem eine Vertretungsregel: Mindestens zwei geeignete Maintainer sollten freigabefähig sein, ohne dass ein gemeinsam genutztes Konto oder eine gemeinsam genutzte 2FA-Methode entsteht.
Freigabegates für einen belastbaren Releaseprozess
Die menschliche Freigabe sollte keine bloße Klickstation werden. Vor der 2FA-Bestätigung müssen Paketname, Version, Quell-Commit, erzeugtes Artefakt, Abhängigkeiten und Testergebnis zusammenpassen. Bei sensiblen Bibliotheken gehört zusätzlich ein Vergleich zwischen gebautem Inhalt und erwarteter Releasequelle in den Prozess. Diese Kontrollen sind eine betriebliche Ableitung; npm garantiert durch Staged Publishing allein weder reproduzierbare Builds noch fehlerfreie Pakete.
- Staging nur aus geschützten Branches und freigegebenen Workflow-Versionen zulassen.
- Artefakt, Commit und Versionsnummer vor der 2FA-Freigabe eindeutig verknüpfen.
- Dist-Tag-Änderungen und Deprecation-Aktionen separat überwachen.
- Token-Nutzung, fehlgeschlagene Direktveröffentlichungen und Freigabezeiten protokollieren.
- Widerruf, Maintainer-Ausfall und fehlerhaften Staging-Lauf als Notfallszenarien testen.
Für den Pilot sollten Teams nicht nur prüfen, ob ein Release technisch gelingt. Sinnvolle Prozesskennzahlen sind die Zeit zwischen Staging und Freigabe, abgebrochene Freigaben, manuell entdeckte Abweichungen, Notfall-Widerrufe und die Zahl verbliebener Tokens mit direkter Publishing-Berechtigung. Ein festes Enddatum für den Parallelbetrieb verhindert, dass die Übergangslösung dauerhaft zwei Freigabewege unterhält. Die Kennzahlen dienen der internen Steuerung; sie sind keine von npm zugesagten Benchmarks.
Entscheidungsrahmen: Trusted Publishing oder Stage-only
Trusted Publishing bleibt der naheliegende Zielzustand, wenn Plattform, Paket und Workflow unterstützt werden und kurzlebige Identitäten genutzt werden können. Stage-only ist sinnvoll, wenn eine tokenbasierte Pipeline vorerst bestehen muss, das Unternehmen aber die direkte Veröffentlichung aus der Automatisierung entfernen will. Wer bereits eine belastbare Release-Freigabe hat, kann den Wechsel früh pilotieren. Wer viele unbekannte Alt-Pipelines betreibt, beginnt mit Inventar und Risikoklassen statt mit einer pauschalen Token-Rotation.