npm Trusted Publishing kann dist-tags jetzt per OIDC verschieben

GitHub hat am 30. September 2026 angekündigt, dass das Trusted Publishing von npm jetzt dist-tags verwalten kann. Das sind die Labels wie latest, die festlegen, welche Version eines Pakets Nutzer installieren. Release-Pipelines können diese Labels mit einem kurzlebigen Login-Token verschieben statt mit einem gespeicherten npm-Zugriffstoken. Damit entfällt ein häufiger Grund, ein langlebiges npm-Secret in einem CI-System aufzubewahren.

Die Berechtigung ist Opt-in. Sie ist bei jeder Konfiguration, ob alt oder neu, zunächst ausgeschaltet, sodass niemand die Möglichkeit erhält, latest zu verschieben, ohne sie anzufordern.

Was Trusted Publishing und dist-tags sind

Mit Trusted Publishing kann ein CI-Job, etwa ein Workflow in GitHub Actions, ohne gespeichertes Passwort oder Token bei npm veröffentlichen. Der Job weist seine Identität per OIDC nach. OIDC steht für OpenID Connect, ein Standardverfahren zur Ausgabe kurzlebiger Identitätstokens. Die npm-Registry prüft dieses Token anhand einer Konfiguration, die der Paketinhaber eingerichtet hat, und erlaubt dann die Aktion.

Ein dist-tag ist ein benannter Zeiger auf eine bestimmte Version eines Pakets. Dem Tag latest folgen die meisten Installationen. Projekte fügen oft weitere hinzu, etwa next oder beta, für Testversionen. Bisher konnte Trusted Publishing ein Paket zwar veröffentlichen, diese Zeiger aber nicht verschieben. Deshalb behielten Teams für diesen Schritt ein langlebiges Token.

Was die neue Berechtigung erlaubt

Jede Trusted-Publishing-Konfiguration hat jetzt eine Einstellung namens "Allow npm dist-tag", wie aus GitHubs Changelog hervorgeht. Ist sie aktiviert, kann der CI-Job dist-tags hinzufügen, entfernen und hochstufen. Die npm-Dokumentation nennt die passenden Befehle: npm dist-tag ls, npm dist-tag add und npm dist-tag rm.

GitHub betont die Voreinstellung. "Sie ist sowohl für neue als auch für bestehende Konfigurationen standardmäßig ausgeschaltet, sodass keine Konfiguration automatisch neue Fähigkeiten erhält", heißt es im Changelog.

Die Berechtigung ist vom Veröffentlichen getrennt. Laut der Dokumentation kann eine Konfiguration die Erlaubnis erhalten, Pakete zu stagen und dist-tags zu verwalten, ohne npm publish ausführen zu dürfen. Außerdem heißt es dort, dass Konfigurationen, die nach dem 3. September 2026 erstellt wurden, Pakete automatisch stagen können, der Zugriff auf dist-tags aber weiterhin von Hand eingeschaltet werden muss.

Eine Regel ist für die Sicherheit wichtig. Eine Änderung an einem dist-tag ist erlaubt, "wenn das eingehende OIDC-Token mit irgendeiner Konfiguration übereinstimmt, bei der die Berechtigung aktiviert ist", schreibt GitHub. Jede Konfiguration mit gesetztem Häkchen ist daher ein weiterer Weg, latest zu verschieben.

Voraussetzungen und Grenzen

Die Dokumentation von npm legt diese Mindestanforderungen fest:

Voraussetzung	Was die npm-Dokumentation sagt
npm CLI für dist-tags über OIDC	11.21.0 oder neuer
npm CLI für Trusted Publishing allgemein	11.5.1 oder neuer
Node.js	22.14.0 oder neuer
GitHub Actions	Nur von GitHub gehostete Runner
GitLab CI/CD	Nur Shared Runner von GitLab.com
CircleCI	Nur CircleCI Cloud
Selbst gehostete Runner	Noch nicht unterstützt

Laut der Dokumentation sind selbst gehostete Runner "für künftige Versionen geplant". Bei der CI-Unterstützung weichen die Quellen voneinander ab. Ein Beitrag in der DEV Community von einem Entwickler namens Leo nennt auch Buddy und Jenkins, Letzteres über Plugins, doch die eigene Dokumentation von npm führt nur die drei oben genannten Dienste auf.

Warum dist-tags ein Angriffsziel sind

Ein dist-tag zu verschieben ist so mächtig wie das Veröffentlichen. Leos Beitrag nennt die Kontrolle über dist-tags ein ernstes Risiko für die Lieferkette, denn ein Angreifer, der latest umschreiben kann, kann jede neue Installation auf eine schädliche Version lenken. Bösartige Releases sind ein reales Muster: Im August führten manipulierte Versionen des Rust-Crates arrayref während der Builds eine Remote-Payload aus.

Leo warnt auch vor einem menschlichen Fehler. Teams, deren Release blockiert ist, setzen womöglich bei jeder Konfiguration das Häkchen, damit das Problem verschwindet. Der Beitrag empfiehlt stattdessen eine eigene Release-Konfiguration mit strengem Abgleich: eine bestimmte Workflow-Datei, eine geschützte Umgebung und einen manuellen Freigabeschritt.

Was das für Entwickler bedeutet

Aktualisieren Sie zuerst die npm CLI in Ihrem Release-Job. Änderungen an dist-tags über OIDC brauchen npm 11.21.0 oder neuer und Node.js 22.14.0 oder neuer. Eine ältere CLI in einem fixierten CI-Image schlägt fehl, selbst wenn die Einstellung aktiviert ist.

Schalten Sie die Berechtigung nur an einer Stelle ein. Da jede einzelne passende Konfiguration latest verschieben kann, aktivieren Sie sie in Ihrer Release-Konfiguration und lassen Sie sie bei Staging- und Testkonfigurationen aus. Prüfen Sie die Liste nach jeder Änderung.

Binden Sie die Konfiguration eng. Verknüpfen Sie sie mit genau der Workflow-Datei, die Releases erstellt, und verlangen Sie eine geschützte Umgebung mit einem Freigabeschritt. So kann weder ein Pull-Request-Workflow noch ein kompromittierter Nebenjob Ihre Tags verschieben.

Löschen Sie das alte Token, sobald die Umstellung funktioniert. Der Sinn dieser Änderung ist, keine langlebigen npm-Secrets mehr in CI zu speichern. Wenn ein Release über OIDC erfolgreich war, entfernen Sie das übrig gebliebene Token aus Ihren CI-Secrets und widerrufen Sie es bei npm.

Behalten Sie ein Token nur dort, wo es sein muss. Wenn Sie auf selbst gehosteten Runnern bauen, deckt Trusted Publishing Sie noch nicht ab. Beschränken Sie dieses Token auf die Pakete, die es braucht, und rotieren Sie es nach festem Zeitplan, bis npm selbst gehostete Runner unterstützt.

Prüfen Sie Ihre Tags nach jedem Release. Führen Sie npm dist-tag ls für Ihr Paket aus und vergewissern Sie sich, dass latest dorthin zeigt, wo Sie es erwarten. Dieser Check dauert zwei Sekunden und deckt sowohl Fehler als auch Angriffe auf.