Das NPM_TOKEN-Problem, das Trusted Publishing löst
Ein klassischer npm publish-Schritt in einer Pipeline braucht ein Automation-Token: ein NPM_TOKEN, in den Secrets des Repositorys oder der Organisation hinterlegt, im Workflow als Umgebungsvariable eingelesen. Dieses Token ist langlebig. Es liegt so lange im Secret-Speicher, bis jemand es widerruft oder rotiert, und es funktioniert unabhängig davon, welcher Workflow es gerade verwendet.
npm Trusted Publishing ersetzt genau diesen Schritt. Nach der npm-Dokumentation (gelesen am 28.09.2026) ermöglicht Trusted Publishing das Veröffentlichen von Paketen direkt aus CI/CD-Workflows per „OpenID Connect (OIDC) authentication, eliminating the need for long-lived npm tokens“. Die Registry vertraut dabei nicht mehr einem gespeicherten Geheimnis, sondern einer Identitätsaussage, die dein CI/CD-Anbieter für genau diesen Workflow-Lauf ausstellt. Laut Doku implementiert npm damit den Trusted-Publishing-Standard der Open Source Security Foundation.
Unterstützt sind laut Doku drei Plattformen: GitHub Actions (GitHub-hosted Runner), GitLab CI/CD (GitLab.com Shared Runner) und CircleCI (CircleCI Cloud). Selbst gehostete Runner sind ausdrücklich ausgenommen: „Self-hosted runners are not currently supported but are planned for future releases.“ Dieser Beitrag beschreibt den Weg über GitHub Actions.
Trusted Publisher für ein Paket hinterlegen
Die Vertrauensbeziehung entsteht nicht im Workflow, sondern zuerst auf der Registry-Seite: Du hinterlegst in den npm-Paketeinstellungen, welcher Workflow aus welchem Repository publizieren darf. Laut Doku sind dafür folgende Angaben nötig:
- Organization/User: der GitHub-Benutzername oder die Organisation.
- Repository: der Repository-Name.
- Workflow filename: nur der Dateiname, kein Pfad, zum Beispiel
publish.yml. - Environment name: optional, zusätzliche Einschränkung auf ein GitHub-Environment.
- Allowed actions: optional.
Die Doku warnt ausdrücklich, dass Tippfehler hier nicht sofort aussortiert werden: „Double-check that your repository, workflow filename, and other details are correct, as errors will only appear when you attempt to publish.“ Pro Paket lassen sich laut Doku bis zu 10 Trusted Publisher konfigurieren. Als Absicherung danach empfiehlt die Doku, klassisches Token-Publishing für das Paket einzuschränken: „Select ‚Require two-factor authentication and disallow tokens’“.
Der Workflow ohne NPM_TOKEN
Auf der Workflow-Seite braucht es laut Doku vor allem eine Berechtigung: id-token: write, damit GitHub Actions einen OIDC-Token ausstellen darf. Ein Gerüst dafür:
name: Publish to npmon: release: types: [published]permissions: id-token: write # erforderlich, damit GitHub Actions einen OIDC-Token ausstellt contents: readjobs: publish: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '22' registry-url: 'https://registry.npmjs.org' - run: npm ci - run: npm publish
Kein NPM_TOKEN, kein NODE_AUTH_TOKEN im publish-Schritt. Voraussetzung laut GitHub-Changelog zur allgemeinen Verfügbarkeit vom 31.07.2025 ist npm CLI v11.5.1 oder neuer, mitgeliefert über eine entsprechend aktuelle Node-Version in setup-node. Trusted Publishing funktioniert laut Changelog sowohl für private als auch für öffentliche Pakete.
Eine Einschränkung bleibt: Braucht npm ci Zugriff auf private Abhängigkeiten, empfiehlt die Doku dafür weiterhin einen separaten, nur lesenden Token als Secret, etwa NPM_READ_TOKEN über NODE_AUTH_TOKEN. Trusted Publishing ersetzt hier den Publish-Token, nicht zwangsläufig jeden Token im Workflow.
Was sich an der Angriffsfläche ändert
Der Unterschied zum klassischen Token liegt laut Doku im Token selbst: „each publish uses short-lived, cryptographically-signed tokens that are specific to your workflow and cannot be extracted or reused.“ Die GitHub-Ankündigung zur GA beschreibt dieselbe Eigenschaft: „short-lived, workflow-specific credentials that cannot be exfiltrated or reused.“ Ein Token, das mit dem einzelnen Publish-Vorgang entsteht und danach nicht mehr gültig ist, kann nicht aus einem Secret-Speicher, einem Log oder einer kompromittierten Third-Party-Action abgezogen und später wiederverwendet werden.
Die npm-Doku stellt den Kontrast zum klassischen Token explizit heraus: Ein gestohlenes Automation-Token liefert laut Doku so lange Zugriff, bis es widerrufen wird: „If compromised, they provide persistent access until revoked.“ Damit verschwindet mit dem NPM_TOKEN auch der Rotationsaufwand, der zu einem langlebigen Secret gehört: kein Kalendereintrag für den nächsten Tokenwechsel, kein Secret, das jemand beim Offboarding vergisst zu widerrufen.
Provenance ist ein eigenes Thema, keine Voraussetzung
Trusted Publishing beantwortet, wie sich der Workflow an der Registry anmeldet. Provenance beantwortet eine andere Frage: ob sich nachträglich beweisen lässt, woher ein veröffentlichtes Paket stammt. Seit der GA vom 31.07.2025 hängen beide Funktionen zusammen, sind aber nicht identisch: Laut GitHub-Changelog veröffentlicht die npm CLI bei OIDC-Publishing Provenance-Attestationen standardmäßig, der Flag --provenance ist nicht mehr nötig. Die npm-Doku nennt dafür Bedingungen: Publishing über OIDC, öffentliches Repository, öffentliches Paket. Wer das nicht will, kann es laut Doku über NPM_CONFIG_PROVENANCE=false oder provenance=false in der .npmrc abschalten.
Abgrenzung zu Nachbarthemen auf diesem Blog
Dieser Beitrag behandelt ausschließlich den Registry-seitigen Publish-Schritt eines npm-Pakets. Der Cloud-Deploy-OIDC-Flow, mit dem GitHub Actions ohne gespeicherte Zugangsdaten etwa bei AWS oder Azure deployt, ist Thema des Beitrags „OIDC statt Secrets: Wie GitHub Actions ohne gespeicherte Tokens deployt“ auf diesem Blog. Dort geht es um die Anmeldung an einer Cloud-Plattform, hier um die Anmeldung an der npm-Registry, zwei unterschiedliche Vertrauensbeziehungen mit demselben Grundprinzip. Wie sich Herkunft und Signatur eines bereits gebauten Artefakts nachweisen lassen, behandeln die Beiträge „Provenance und Attestation: woher ein Artefakt wirklich stammt“ und „Merkle-Trees und Transparenz-Logs: Wie Sigstore Vertrauen ohne zentrale Instanz schafft“. Dieser Beitrag hier bleibt beim Publish-Schritt selbst.
Wo Unterstützung ansetzt
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Hinterlasse einen Kommentar