npm PyPI Security 2026 ist ein wichtiges Thema für Unternehmen, deren Anwendungen von JavaScript- oder Python-Paketen abhängen. Ein kompromittiertes Paket kann sich durch automatisierte Builds in zahlreiche Systeme verbreiten. Besonders riskant sind langlebige Registry-Tokens, unzureichend geprüfte CI/CD-Workflows und unbekannte Abhängigkeiten aus öffentlichen Repositories. Sowohl npm als auch PyPI unterstützen inzwischen Trusted Publishing mit OpenID Connect (OIDC): Statt eines dauerhaft gespeicherten Veröffentlichungstokens erhält ein berechtigter Workflow kurzlebige Zugangsdaten. Ergänzende Provenance- und Attestation-Nachweise helfen, die Herkunft eines Releases besser einzuordnen. Dieser Fachartikel zeigt, was diese Mechanismen leisten, wo ihre Grenzen liegen und wie Unternehmen sichere Paketquellen und Release-Prozesse gestalten.
Autor: Salman Dolatpanah Gortlar · GORTNET · 5. November 2026
Kurzfassung: Kurzlebiges OIDC-Publishing reduziert die Abhängigkeit von statischen API-Tokens; Provenance ergänzt, ersetzt aber nicht den Code-Review.
npm PyPI Security 2026: Warum Paketregistries kritisch sind
Moderne Anwendungen nutzen oft Hunderte direkte und indirekte Abhängigkeiten. CI-Systeme laden diese Pakete automatisiert und führen bestimmte Installations- oder Buildschritte aus. Ein kompromittierter Upstream oder manipuliertes Paket kann dadurch auf Entwicklungssysteme, Pipeline-Umgebungen oder schließlich auf produktive Anwendungen wirken. Sicherheitskontrollen müssen daher mehrere Stufen berücksichtigen: Auswahl, Installation, Build und Veröffentlichung.
Nicht jede neue Paketversion ist automatisch riskant, aber unkontrollierte Aktualisierungen erschweren Nachvollziehbarkeit. Ein Unternehmen sollte wissen, welche Registries genutzt werden, welche Konten Pakete veröffentlichen dürfen und welche Projekte besonders kritische Rechte besitzen. Gerade Build-Runner mit Zugriff auf Cloud-Secrets verdienen zusätzliche Schutzmaßnahmen. Die Paketverwaltung gehört in das Sicherheitsinventar.
Was Trusted Publishing konkret verändert
Bei Trusted Publishing wird eine Vertrauensbeziehung zwischen Registry und einer genehmigten CI/CD-Identität eingerichtet. Der Workflow erhält ein kurzlebiges OIDC-Token, das die Registry nach definierten Claims prüft. Ist der Ablauf berechtigt, kann ein kurzlebiges Veröffentlichungstoken ausgegeben werden. Ein fest im Repository hinterlegter Registry-API-Key ist damit für diesen Publishingpfad nicht mehr nötig.
Das reduziert insbesondere die Gefahr, dass langlebige Write-Tokens in Logs oder Konfigurationsdateien verbleiben. Die Maßnahme verlagert jedoch einen Teil der Verantwortung auf die Integrität der CI/CD-Workflows und ihrer Identitäten. Ein kompromittierter autorisierter Release-Workflow kann weiterhin schädliche Pakete veröffentlichen. Trusted Publishing ersetzt deshalb keine Reviewpflicht und keine sichere Build-Umgebung.
OIDC in npm: Voraussetzungen und technische Grenzen
npm dokumentiert für Trusted Publishing aktuell unter anderem die Nutzung einer ausreichend neuen npm-CLI- und Node-Version. Unterstützte Cloud-CI-Anbieter sind je nach aktuellem Stand GitHub Actions, GitLab CI/CD und CircleCI mit spezifischen Randbedingungen. Self-hosted Runner werden in den npm-Dokumenten nicht allgemein als unterstützter Trusted-Publishing-Weg beschrieben. Die exakten Voraussetzungen sollten vor der Umstellung mit dem eigenen Setup verglichen werden.
Registrieren Sie den genauen Publisher-Kontext und testen Sie den Ablauf mit einem unkritischen Paket. Prüfen Sie nicht nur, dass die Veröffentlichung gelingt, sondern auch, dass ein fremdes Repository, ein nicht freigegebener Workflow oder ein unerwarteter Branch keine Berechtigung erhält. Wenn ein alter Registry-Token nicht mehr gebraucht wird, sollte er nach einem geregelten Verfahren widerrufen werden. Eine parallele alte Authentifizierung kann den Sicherheitsgewinn verkleinern.
PyPI Trusted Publishers und kurzlebige Tokens
PyPI verwendet ebenfalls OIDC, um berechtigten CI-Workflows kurzlebige Veröffentlichungstokens auszustellen. Die Dokumentation beschreibt eine kurze Gültigkeitsdauer und eine Bindung an definierte Publisher-Claims. Ein Release kann dadurch ohne manuell verwaltetes, langlebiges API-Token hochgeladen werden. Zusätzlich unterstützt PyPI digitale Attestations für einzelne Release-Dateien.
Hinterlegen Sie beim Projekt möglichst präzise Angaben zu Repository, Workflow und gegebenenfalls Environment. Prüfen Sie die Identität des Releaseprozesses mit einer kontrollierten Testveröffentlichung. Entscheidend ist, dass nicht jeder beliebige Job der Organisation als Publisher akzeptiert wird. Die Sicherheit der Registry-Berechtigung hängt von den Freigaben und der Integrität der vorgelagerten CI-Konfiguration ab.
Provenance und Attestations verständlich erklären
Eine digitale Attestation bindet bestimmte Aussagen über ein Release an einen kryptografischen Digest und eine prüfbare Identität. Sie kann beispielsweise dokumentieren, welcher Workflow eine Paketdatei veröffentlicht hat. In PyPI werden Mechanismen aus dem in-toto-Ökosystem verwendet; npm bietet unter passenden Bedingungen automatisch Provenance-Nachweise. Das hilft Konsumenten, ein Paket besser auf seine Herkunft zurückzuführen.
Ein Herkunftsnachweis bedeutet allerdings nicht, dass der Code harmlos oder frei von Schwachstellen ist. Ein legitim autorisierter, aber kompromittierter Workflow kann bösartige Inhalte mit formal korrekter Provenance veröffentlichen. Kombinieren Sie daher Attestations mit Abhängigkeitsprüfung, Code-Review, sicheren Branches und reproduzierbaren Buildschritten, wo dies praktikabel ist. Authentizität und inhaltliche Sicherheit sind getrennte Eigenschaften.
Dependency Confusion und Namenskonflikte verhindern
Dependency Confusion entsteht, wenn ein Build eine öffentliche Paketquelle verwendet, obwohl intern ein gleich oder ähnlich benanntes Paket vorgesehen ist. Je nach Registry- und Paketmanager-Konfiguration kann dadurch eine unerwünschte öffentliche Abhängigkeit in einen internen Build gelangen. Der Kernfehler ist die unklare Vertrauensgrenze zwischen privaten und öffentlichen Paketnamen.
Definieren Sie für interne Pakete eindeutige Namespaces und kontrollierte Registry-Konfigurationen. Prüfen Sie, in welcher Reihenfolge Quellen gesucht werden und welche Identität ein Build verwendet. Verlassen Sie sich nicht ausschließlich darauf, dass ein Paketname zufällig noch nicht öffentlich belegt ist. Eine interne Paket-Proxy- oder Spiegelarchitektur kann zusätzliche Freigaben und Prüfungen ermöglichen, muss aber sorgfältig konfiguriert und überwacht werden.
Lockfiles, Hashes und reproduzierbare Installationen
Lockfiles dokumentieren die konkret aufgelösten Abhängigkeiten einer Anwendung. Mit Integritätsprüfungen und kontrollierten Versionen lässt sich das Risiko verringern, dass bei jedem Build unerwartet andere Paketversionen geladen werden. Die Details unterscheiden sich zwischen npm, pip und anderen Werkzeugen. Ein Lockfile beweist nicht, dass ein Paket ungefährlich ist, verbessert aber Reproduzierbarkeit und Nachvollziehbarkeit.
Führen Sie Updates in einem separaten Reviewprozess durch und kontrollieren Sie unerwartete Transitive Dependencies. Für Python können Hash-Pinning und geeignete Locking- oder Requirements-Mechanismen helfen, konkrete Artefakte festzulegen. Kombinieren Sie diese Kontrollen mit Security-Advisories und Tests. Unveränderlichkeit allein darf nicht dazu führen, dass bekannte verwundbare Versionen jahrelang im Betrieb bleiben.
Installationsskripte und Build-Runner absichern
Bei Paketinstallation und Build können je nach Ökosystem Skripte ausgeführt werden. Deshalb kann bereits das Testen eines kompromittierten Pakets gefährlich sein. Verwenden Sie für untrusted Builds frische isolierte Runner mit begrenzten Rechten und ohne langfristige Geheimnisse. Netzwerkausgänge sollten auf den für den Job erforderlichen Umfang reduziert werden.
Trennen Sie Paketprüfung, Releasevorbereitung und tatsächliches Publishing. Besonders privilegierte Jobs dürfen nicht automatisch den Code nicht freigegebener Pull Requests ausführen. Speichern Sie Cloud- und Registry-Credentials nicht in allgemein zugänglichen Arbeitsverzeichnissen. Ein Buildprotokoll ist zudem ein möglicher Ort für Secret-Leaks und sollte entsprechend geschützt werden.
Signale für eine kompromittierte Abhängigkeit
Ungewöhnliche Änderungen am Paketumfang, neue Installationsskripte, unerwartete Netzwerkverbindungen oder neue Maintainer können Hinweise auf erhöhte Risiken sein. Keines dieser Merkmale ist allein ein Beweis für bösartigen Code. Unternehmen benötigen deshalb eine Kombination aus automatisierter Prüfung und menschlicher Bewertung. Für kritische Anwendungen sollte klar sein, welche neuen Pakete ohne vorherige Freigabe eingeführt werden dürfen.
Nutzen Sie Dependency- und Malware-Scanning dort, wo passende Tools verfügbar sind. Kontrollieren Sie außerdem Paketquellen, verifizierbare Attestations und Änderungen an GitHub-Actions- oder GitLab-Workflows. Ein transparenter Releaseprozess ist besonders wichtig, weil ein Fehler in einem Grundpaket viele Anwendungen gleichzeitig beeinträchtigen kann.
Incident Response bei einem bösartigen Paket
Wenn eine kompromittierte Version erkannt wird, sollten betroffene Builds und Deployments zunächst gestoppt werden. Inventarisieren Sie, welche Projekte die Version verwendet haben und welche Secrets oder Netzverbindungen in der Pipeline verfügbar waren. Sichern Sie relevante Logs und Artefakte, bevor Systeme bereinigt werden. Prüfen Sie unabhängig, ob die Gefahr ausschließlich im Build oder auch im produktiven Paket besteht.
Rollen Sie auf eine nachweislich sichere Version oder ein geprüftes Artefakt zurück. Behandeln Sie möglicherweise entwendete Tokens entsprechend dem tatsächlichen Zugriff als gefährdet. Die Wiederherstellung muss auch den Entwicklerarbeitsplatz und die CI-Konfiguration berücksichtigen. Ein einfaches Entfernen des Pakets aus einer Requirements-Datei reicht nicht, wenn es bereits während eines früheren Builds ausgeführt wurde.
30-Tage-Plan für sichere Paketveröffentlichung
Woche eins: Registries, Release-Tokens, Maintainer und CI-Workflows inventarisieren. Woche zwei: Ein Pilotprojekt auf Trusted Publishing umstellen und nicht erlaubte Publikationsversuche kontrolliert testen. Woche drei: Provenance, Lockfiles, Berechtigungen und Dependency-Scanning in kritischen Builds integrieren. Woche vier: Unnötige langlebige Tokens widerrufen und einen Incident-Test durchführen.
Messen Sie den Anteil der Releases ohne dauerhafte Publishing-Secrets, die Zahl ungeprüfter Paketquellen und die Dauer bis zur Identifikation betroffener Anwendungen. Eine belastbare Softwarelieferkette ist kein einzelnes Sicherheitsfeature, sondern das Zusammenspiel von Identität, Buildisolierung, Herkunftsnachweisen und kontrollierten Änderungen.
FAQ zu npm und PyPI Security
Was ist Trusted Publishing?
Ein Veröffentlichungsverfahren mit kurzlebigen, über OIDC verifizierten CI-Identitäten statt dauerhaft gespeicherter Registry-Tokens.
Beweisen Attestations, dass ein Paket sicher ist?
Nein. Sie helfen bei der Prüfung von Herkunft und Integrität, ersetzen aber keine Inhaltsanalyse.
Unterstützen npm und PyPI dasselbe Setup?
Nicht vollständig. Die unterstützten CI-Anbieter, Versionen und Attestation-Regeln unterscheiden sich.
Verhindert ein Lockfile jeden Supply-Chain-Angriff?
Nein. Es verbessert Reproduzierbarkeit, garantiert aber keine vertrauenswürdigen Inhalte.
Fazit: Publishing-Identität, Artefakt und Build gemeinsam schützen
npm PyPI Security 2026 verlangt die Überprüfung aller Schritte von der Paketquelle bis zur Veröffentlichung. Trusted Publishing und überprüfbare Attestations schaffen stärkere Nachvollziehbarkeit, können aber unsichere CI-Jobs und kompromittierte Abhängigkeiten nicht allein neutralisieren.
Weitere GORTNET-Artikel
Für sichere CI/CD-Architekturen und Softwarelieferketten GORTNET kontaktieren.
Offizielle Quellen
Redaktionsstand 5. November 2026. Aktuelle Plattformunterstützung und Versionsvoraussetzungen in der jeweiligen Registry-Dokumentation prüfen.