Provenance ist kein Sicherheitsbeweis: Was npm Trusted Publishing wirklich schützt

Ein Paket trägt einen Provenance-Haken. Der Build kommt aus GitHub Actions. Der Publish-Schritt verwendet OIDC statt eines langlebigen npm-Tokens. Klingt nach: sicher.

Das wäre zu viel versprochen.

2026 hat npm Trusted Publishing weiter ausgebaut. Pakete können aus unterstützten CI/CD-Systemen per OpenID Connect veröffentlicht werden, ohne dass ein langlebiges Schreib-Token im Workflow liegen muss. Für öffentliche Pakete aus öffentlichen GitHub- oder GitLab-Repositories kann dabei automatisch Provenance erzeugt werden. Das ist ein echter Fortschritt für die Supply Chain.

Aber Provenance beantwortet vor allem eine Herkunftsfrage: Welcher Workflow, welches Repository und welcher Commit haben dieses Artefakt erzeugt? Sie beantwortet nicht automatisch: War der Quellcode gutartig, waren alle Abhängigkeiten vertrauenswürdig und war der Workflow selbst sicher?

Genau diese Unterscheidung gehört in jeden ernsthaften Dependency- und CI-Audit.

Was Trusted Publishing verbessert

Klassische npm-Automation arbeitet häufig mit einem Secret wie NPM_TOKEN. Dieses Token liegt als CI-Secret vor und bleibt gültig, bis es abläuft oder widerrufen wird. Wird es versehentlich in Logs ausgegeben, aus einem kompromittierten Workflow gelesen oder nie rotiert, bleibt ein dauerhaft nutzbarer Veröffentlichungsweg offen.

Trusted Publishing ändert das Modell. npm baut eine Vertrauensbeziehung zu einem konkreten CI/CD-Workflow auf. Der Workflow erhält über OIDC kurzlebige, signierte Identitätsinformationen und kann damit einen Publish durchführen. Es gibt kein langlebiges Publish-Secret, das jemand kopieren und später wiederverwenden kann.

Das entfernt eine ganze Klasse dauerhaft verwertbarer Zugangsdaten aus dem Release-Pfad.

Provenance ist eine Quittung, kein Gütesiegel

npm-Provenance kann sichtbar machen, aus welchem Repository ein Paket stammt, welcher Commit gebaut wurde, welcher Workflow den Build erzeugt hat und welche Build-Umgebung beteiligt war. GitHub Artifact Attestations verknüpfen Artefakte ähnlich mit Repository, Workflow, Commit, Trigger und Build-Umgebung.

Das ist wertvoll, weil Herkunft und Integrität überprüfbarer werden. Aber die Attestierung sagt nicht, dass der Commit keinen Schadcode enthält, dass der Workflow keine gefährliche Drittanbieter-Action verwendet, dass ein Maintainer-Account nicht übernommen wurde oder dass Tests sinnvoll sind.

GitHub weist ausdrücklich darauf hin, dass Attestierungen keine Garantie dafür sind, dass ein Artefakt sicher ist. Sie liefern Informationen, die anschließend gegen eine eigene Sicherheitsrichtlinie bewertet werden müssen.

Provenance macht Vertrauen überprüfbarer. Sie ersetzt nicht die Entscheidung, wem und was Sie vertrauen.

Beispiel: perfekt attestierter Schadcode

Stellen wir uns ein npm-Paket vor. Ein Maintainer fügt absichtlich Code hinzu, der beim Start Umgebungsvariablen an einen externen Server sendet. Der Commit wird normal gemerged. GitHub Actions baut exakt diesen Commit. Trusted Publishing authentifiziert exakt diesen Workflow. npm erzeugt eine korrekte Provenance-Attestierung.

Die Lieferkette kann kryptografisch korrekt sein – und das Paket trotzdem bösartig.

Die Attestierung beweist, dass Sie das Artefakt bekommen haben, das dieser Workflow aus diesem Commit erzeugt hat. Sie beweist nicht, dass dieser Commit hätte veröffentlicht werden sollen.

Fünf Red Flags im Release-Pfad

1. Alte Publish-Tokens existieren weiter

Trusted Publishing wurde eingerichtet, aber das alte Automation-Token bleibt als Repository-Secret bestehen. Dann gibt es weiterhin zwei Veröffentlichungswege. npm empfiehlt nach erfolgreicher Migration, nicht mehr benötigte Automation-Tokens zu widerrufen und traditionellen Token-Zugriff zu beschränken.

Prüfen Sie deshalb, welche npm-Tokens noch existieren, welche Schreibrechte besitzen und ob alte CI-Systeme oder lokale Publish-Skripte weiterhin funktionieren.

2. Der Publisher ist vertrauenswürdig, der Workflow nicht

OIDC bindet die Veröffentlichung an einen Workflow. Damit wird dieser Workflow selbst hochkritisch.

GitHub empfiehlt, Actions für maximale Unveränderlichkeit auf eine vollständige Commit-SHA zu pinnen. Tags und Branches können sich bewegen. Ein Release-Workflow sollte außerdem minimale permissions verwenden, untrusted Pull-Request-Kontexte vom Publish-Pfad fernhalten und Änderungen an Workflow-Dateien besonders schützen.

Trusted Publishing schützt die Authentifizierung bei npm. Es schützt nicht automatisch jede Action und jeden Shell-Schritt davor.

3. Niemand prüft das tatsächliche Publish-Artefakt

Repository und npm-Tarball sind nicht zwingend identisch. Build-Schritte erzeugen Dateien, Bundler ersetzen Werte und Publish-Skripte können zusätzliche Inhalte einpacken. So landen manchmal interne Source Maps, Testdaten, lokale Konfiguration oder sogar Secrets im Paket.

Vor npm publish gehört deshalb ein Blick auf das tatsächliche Artefakt dazu: Was zeigt npm pack --dry-run? Welche Dateien werden veröffentlicht? Stimmen files, .npmignore und Build-Ausgabe? Werden Source Maps bewusst ausgeliefert?

4. Provenance wird angezeigt, aber nie verifiziert

Ein grüner Hinweis in der Registry ist nützlich. Für kritische Abhängigkeiten sollte die Prüfung jedoch nicht nur visuell erfolgen. npm dokumentiert mit npm audit signatures eine Möglichkeit, Registry-Signaturen und vorhandene Provenance-Attestierungen zu prüfen.

Fehlende Provenance macht ein Paket nicht automatisch unsicher. Vorhandene Provenance macht es nicht automatisch sicher. Der Wert liegt in zusätzlicher überprüfbarer Information.

5. Dependabot wird mit Sicherheitsfreigabe verwechselt

Automatisierte Updates reduzieren veraltete Versionen und machen Fixes schneller sichtbar. Ein grüner Bot-PR beantwortet aber nicht, warum die Dependency benötigt wird, ob neue Lifecycle-Skripte oder transitive Abhängigkeiten hinzukommen, ob sich Maintainer oder Repository geändert haben oder ob das Paket nun auf Netzwerk, Dateisystem oder Build-Secrets zugreift.

Automation schlägt eine Änderung vor. Review bewertet das Risiko.

Ein sinnvoller Supply-Chain-Check

Ein belastbarer Audit schaut nicht nur auf package.json, sondern auf den vollständigen Weg bis Produktion:

• Release-Identität: OIDC oder langlebiges Token, Publisher-Bindung, alte Publish-Wege, 2FA und Maintainer.
• Workflow-Integrität: gepinnte Actions, minimale Rechte, geschützte Tags und Branches, keine untrusted Inputs im Release-Pfad.
• Artefakt-Inhalt: Tarball oder Build-Ausgabe vor Veröffentlichung prüfen, Secrets und interne Dateien ausschließen.
• Provenance: Attestierungen erzeugen und technisch verifizieren; Repository, Commit und Workflow mit der Erwartung abgleichen.
• Dependency-Governance: neue Pakete stärker prüfen als Routineupdates, Dependency Review verwenden, unbenutzte Pakete entfernen und automatische Wege bis Produktion bewusst begrenzen.

Was Website-Pflichtencheck prüfen würde

Bei Websites und SaaS-Produkten endet Supply-Chain-Sicherheit nicht beim Server. Ein technischer Check kann npm-, pnpm- oder yarn-Abhängigkeiten, Lockfile-Konsistenz, CI/CD-Berechtigungen, GitHub-Action-Pinning, Secret- und Token-Nutzung, OIDC/Trusted Publishing, Build-Artefakte, Provenance, Dependency-Review und Schutz kritischer Releases untersuchen.

Das Ziel ist nicht, jede Dependency wie einen Kriminalfall zu behandeln. Das Ziel ist, genau zu wissen, welche Schritte zwischen „jemand hat Code geändert“ und „dieser Code läuft auf der Website“ liegen.

Provenance ist die Quittung dafür, woher Software kommt. Sie ist nicht das Prüfzeichen dafür, dass Sie sie gefahrlos ausführen können.