npm-Stage-only-Token: Nachweise bei der Trennung von Veröffentlichungsautomatisierung und finaler Freigabe
Wird die Berechtigung eines CI-Systems zum Erstellen eines Pakets von der Berechtigung getrennt, dieses für Benutzer zu veröffentlichen, wird die finale Verantwortung für ein Release klarer abgegrenzt. Ein zusätzlicher Genehmigungs-Button allein beseitigt jedoch keine Risiken in der Lieferkette. Zunächst muss festgelegt werden, was die prüfende Person überhaupt kontrollieren soll.
GitHub gab am 18. September bekannt, dass für granulare npm-Zugriffstoken nun die Schreibberechtigung „stage-only“ ausgewählt werden kann. Der Ablauf sieht vor, dass die Automatisierung eine Version zur Überprüfung einreicht und Maintainer die Veröffentlichung per 2FA freigeben. Nachfolgend werden die offiziellen Änderungen von den Empfehlungen der Redaktion für den praktischen Betrieb abgegrenzt.
Das Blockieren direkter Veröffentlichungen ist nicht gleichbedeutend mit dem Entzug aller Schreibrechte
Laut offizieller Ankündigung kann mit diesem Token npm stage publish ausgeführt werden, eine direkte Veröffentlichung über npm publish wird jedoch verweigert. Diese Einschränkung gilt auch dann, wenn eine 2FA-Bypass-Konfiguration für Automatisierungen vorliegt. Es handelt sich nicht um eine automatische Verhaltensänderung bestehender Token, sondern um ein optionales Feature.
Zu beachten ist, dass andere Schreibberechtigungen für Pakete – wie das Verschieben von dist-tags oder das Deprecaten von Versionen – erhalten bleiben. Die Bezeichnung „stage-only“ darf keinesfalls als reines Lese- oder harmloses Token interpretiert werden. Der zulässige Paketbereich, der Speicherort des Secrets, die verwendenden Akteure und Deaktivierungsprozesse müssen weiterhin verwaltet werden.
Definieren Sie das Release-Paket, das die Freigabestelle prüft
Die folgenden Hinweise sind keine Pflichtvorgaben von npm, sondern operative Vorschläge für kleine Teams. Hinterlegen Sie bei jeder Freigabeanfrage den Quellcode-Commit, das Zielpaket samt Version, Testergebnisse, die Liste der im Paket enthaltenen Dateien sowie eine Zusammenfassung der Änderungen. Wenn die freigebende Person sich Nachweise aus verstreuten CI-Logs zusammensuchen muss, verkommt die Überprüfung schnell zu einem rein formalen Klick.
Insbesondere die Überprüfung des Quellcodes und die des Distributions-Artefakts sind zweierlei Dinge. Während des Build-Prozesses können Dateien hinzugefügt werden, die im Repository nicht vorhanden waren, oder erforderliche Dateien können fehlen. Teams können das Prinzip etablieren, Prüfunterlagen auf Basis des tatsächlich eingereichten Artefakts zu erstellen und jedes nach einer Prüfung geänderte Artefakt als völlig neues Prüfobjekt zu behandeln.
Auch nach grünem CI gibt es einen Wartezustand
Meldete die bisherige Automatisierung einen Befehlserfolg direkt als abgeschlossenes Release, sollte zunächst die Statusdarstellung angepasst werden. Zweckmäßig ist eine Unterteilung in „Eingereicht“, „Wartet auf Freigabe“ und „Veröffentlicht“, jeweils mit nachvollziehbaren Prüfnachweisen. In Benachrichtigungen ist die Angabe der aktuellen Phase und der zuständigen Person für den Betrieb weitaus hilfreicher als ein einfaches „Erfolg“.
Ein hypothetisches Beispiel: Reicht ein nächtlicher CI-Lauf eine neue Version ein, die erst am nächsten Morgen überprüft wird, darf zum Zeitpunkt des Einreichens keine Release-Ankündigung an Benutzer versendet werden. Verknüpfen Sie Dokumentationen oder Mitteilungen erst mit der im Team definierten Veröffentlichungsbestätigung. Es sollte zudem vorab vereinbart werden, wer bei einem Rückstau prüft und wann ältere Einreichungen bereinigt werden.
Migration anhand eines einzelnen Pakets testen
Die aktuellen offiziellen Voraussetzungen umfassen ein bestehendes npm-Paket, Berechtigungen zur Veröffentlichung, aktivierte 2FA auf dem Konto, npm CLI 11.15.0 oder höher sowie Node.js 22.14.0 oder neuer. Vor einer tatsächlichen Migration sollten die neuesten Dokumentationen geprüft und die Versionen der eingesetzten Runner kontrolliert werden.
Es empfiehlt sich, zunächst bei einem Paket mit geringer Auswirkung die Token-Berechtigungen einzuschränken und den Ablauf von Staging-Übermittlung, Maintainer-Prüfung bis hin zur finalen Veröffentlichungsbestätigung durchzuspielen. Richtet man bei Fehlern sofort einen Fallback auf das alte Token mit weitreichenden Rechten ein, verliert die gezogene Grenze ihren Zweck. Auch Freigabeverzögerungen müssen als regulärer Betriebszustand behandelt werden können.
Fragen im Vergleich zu Trusted Publishing
npm bietet mit Trusted Publishing auch eine OIDC-basierte Alternative. Zunächst sollte geprüft werden, ob dies zur unterstützten CI-Umgebung und den Freigabeprozessen des Teams passt; es gibt keinen Grund, stage-only-Token pauschal als Universallösung für jedes Team zu betrachten. Für Automatisierungen, die weiterhin auf Token angewiesen sind, eröffnet sich damit jedoch eine Option für eine schrittweise Umstellung.
Die offizielle Ankündigung nennt den Januar 2027 als Zieldatum für die Einstellung direkter Veröffentlichungen über Bypass-2FA-Token. Statt über noch unbestimmte Implementierungsdetails zu spekulieren, ist es ratsam, bereits jetzt eine Liste betroffener Workflows und die Zuständigkeiten für die Migration festzulegen. Etwaige Zeitplananpassungen sollten anhand künftiger offizieller Mitteilungen verfolgt werden.
Entscheidungsgrundlagen für die Einführung
Dieser Beitrag beansprucht weder einen breiten Community-Konsens noch konkrete Reduktionsraten bei Sicherheitsvorfällen. Er schlägt auf Basis des offiziellen Verhaltens der neuen Funktion überprüfbare Betriebsabläufe vor. Der Ausgangspunkt für eine Einführung ist die klare Unterscheidbarkeit dessen, was die Automatisierung übernimmt und was der Mensch verifizieren muss.
Was heute bereits getan werden kann: Lokalisieren, wo derzeit Release-Token verwendet werden, die Kriterien für eine abgeschlossene Veröffentlichung definieren und festlegen, welche Belege für eine Freigabe erforderlich sind. Erst wenn Rechtebeschränkung und Prüfqualität Hand in Hand gehen, bringt die Staging-Phase einen echten Mehrwert.