LONDON (IT BOLTWISE) – GitHub verkürzt das Risiko bei npm Trusted Publishing spürbar: Neue Trusted-Publisher-Konfigurationen müssen nach Erstellung innerhalb von 48 Stunden den ersten erfolgreichen Publish abschließen. Danach bindet GitHub die Konfiguration an eine „repository’s immutable identity“ und macht das Setup gegen das Ausnutzen von freigewordenen Slugs unattraktiv. Zusätzlich blockiert GitHub künftige Token-Übertragungen über GitHub-Aktionen-Kontexte und verschärft den Umgang mit GitHub Actions issue_comment sowie pull_request_target. Für Maintainer heißt das: Trusted Bindings regelmäßig gegen den aktuellen Repository-Zustand prüfen und bei Umbenennung oder Transfer neu aufsetzen.
GitHub zieht bei npm Trusted Publishing nach: Das System zum credential-freien Pushen von Paketen aus CI/CD-Umgebungen wird so angepasst, dass neu konfigurierte „Trusted Publisher“ nicht lange als angreifbare Zwischenstufe offen bleiben. Die Kernidee dahinter ist pragmatisch: Wenn eine vertrauenswürdige Zuordnung zwischen npm und einem GitHub-Repository erst einmal „aktiv“ wurde, soll sie nicht mehr über einen frei werdenden, menschengelesenen Namen (den sogenannten slug im Format „owner/repository“) übernommen werden können. Konkret läuft die Validierung für neu erstellte Konfigurationen nun nach 48 Stunden ab, falls in dieser Zeit kein erster erfolgreicher Publish erfolgt. In der Praxis reduziert diese Änderung das Zeitfenster, in dem ein Angreifer versuchen könnte, einen bereits referenzierten slug so zu „beanspruchen“, dass er nachträglich zum Ziel der Vertrauenskette wird.
Technisch betrachtet hängt Trusted Publishing am Zusammenspiel von npm-Registry und GitHub-Authentifizierung über OpenID Connect (OIDC). Wenn Trusted Publishing eingerichtet ist, erzeugt der CI/CD-Provider für einen einzelnen Workflow-Run einen kurzlebigen kryptografischen Token. Die npm-Registry prüft diesen Token gegen eine vorautorisierte Konfiguration. Das Ziel dieser Architektur ist klar: Entwickler müssen keine langfristigen npm-Geheimnisse mehr speichern oder rotieren, und gleichzeitig lassen sich Provanienz-„Attestations“ ableiten, also Informationen darüber, wo ein Paket gebaut und von wem es publiziert wurde. Genau in diesem „verbindlichen“ Mechanismus steckt aber die Schwachstelle, die in der aktuellen Anpassung adressiert wird: Bei der Identitätsprüfung wurde offenbar ein Repo-Bezug verwendet, der sich über Namensänderungen oder Transfers verschieben kann, statt sich konsequent an die dauerhaft gültige, vom Anbieter vergebene Repository-ID zu halten.
Ausgangspunkt der Änderung ist eine Untersuchung, die die Sicherheitslücke in npm Trusted Publishing unter dem Namen SlugFest beschreibt. Laut den Angaben von Golan Myers und dem Sicherheitsunternehmen Bloom Security bestand das Problem darin, dass npm den Repository-Bezug als slug im Sinne einer Adresse/Zuordnung speichert und im relevanten Schritt bis zum ersten erfolgreichen Publish diese slug-Logik gegenüber einem dauerhaft stabilen Identifikator bevorzugt. Myers beschreibt das anschaulich mit dem Bild eines Schlosses, das prüft, ob die Adresse an der Tür passt, und nicht, wer tatsächlich im Haus wohnt. Für Angreifer ist das besonders gefährlich, weil es dem Angriffsmodell keine Credential-Diebstähle und keinen Insiderzugriff abverlangt: Voraussetzung ist im Wesentlichen nur, dass ein slug verfügbar wird – etwa weil ein Maintainer sein Repository umbenennt, transferiert oder löscht – und dass die betroffene Trusted-Publisher-Bindung noch nicht durch einen Publish „verfestigt“ wurde. Danach kann ein Angreifer einen neuen Repository-Eintrag unter demselben owner/repository-Schema erstellen, einen npm publish-Workflow auslösen und so einen OIDC-Token erlangen, der die reclaimed slug mit einer neuen numerischen Repository-ID trägt. npm prüft die „Repository claim“ gegen den gespeicherten slug und stellt dann ein Publish-Zertifikat aus, obwohl der Angreifer nicht das ursprüngliche Repository-Team ist.
Diese Kaskade wirkt im Paket-Ökosystem besonders stark, weil npm-Pakete häufig als Abhängigkeiten in vielen Projekten landen. Bloom Security berichtet, dass die Untersuchung auf über 1.500 als verwundbar eingestufte Pakete kam, die zusammen mehr als 10 Millionen Downloads auf sich vereinten. Hinzu kommt der Effekt moderner Entwicklungsabläufe: KI-gestützte oder automatisierte Agenten auf Maintainer- und Entwicklergeräten lösen Abhängigkeiten zunehmend selbst aus, tendieren dazu, die jeweils neueste Version zu wählen, und überprüfen Herkunftsmetadaten in vielen Workflows nicht in jedem Schritt manuell. So kann eine „malicious“-Version, die auf Basis der vermeintlich legitimen Paketidentität im Registry-Kontext veröffentlicht wird, ohne menschliche Schleife in laufende Builds geraten. Genau diesen Mechanismus beschreibt Bloom Security in der Risikoabschätzung: Wenn ein Paket per reclaimed slug publiziert wird, kann die Folgewirkung im Supply-Chain-Kontext in großem Maßstab stattfinden, weil Reputation, Download-Zahlen und Abhängigkeitsbeziehungen mitgezogen werden.
GitHub setzt daher nicht nur auf Zeitablauf, sondern auch auf Kontext-Reduktion bei Token-Anforderungen. Nach den veröffentlichten Änderungen werden Trusted-Publishing-Tokens aus GitHub Actions issue_comment Events künftig abgelehnt. Zusätzlich bleibt GitHub bei der bekannten Restriktion im Umfeld von pull_request_target, das für bestimmte Angriffsflächen historisch problematisch war. Für Maintainer bedeutet das in der Praxis: Trusted Publisher Bindings sollten regelmäßig auditiert werden, insbesondere dann, wenn ein Repository umbenannt oder in einen anderen Besitz überführt wurde. Wenn sich der verlinkte slug nicht mehr auf das kontrollierte Repository auflöst, sollten Maintainer nach den Empfehlungen das bestehende Trust-Binding entfernen und neu anlegen, diesmal auf die aktuelle, korrekt aufgelöste slug-Zuordnung bezogen. Monitoring auf unerwartete npm publish Events ergänzt diese Hygienemaßnahmen; außerdem empfiehlt sich, Trusted Bindings konsequent zu löschen, wenn das Repository gelöscht, transferiert oder umbenannt wurde.
Der Vorfall reiht sich in eine größere Sicherheitslinie ein, die zuletzt auch bei anderen Paket- und Extension-Marktplätzen sichtbar wurde. Bereits im August hatte Bloom Security laut den vorliegenden Angaben eine Technik namens „Extension Resurrection“ für Open VSX und den VS Code Marketplace beschrieben: Dort konnten Angreifer angeblich nicht existente Erweiterungen in zuvor vertrauenswürdigen Extension-Bundles „wiederbeleben“, indem sie freigewordene Slots in einem Namespace beanspruchten. Die Folge wäre ähnlich: Maliziöses Codeverhalten wird dann still in bestehende, zuvor installierte Bundles hineingepusht. Bemerkenswert ist dabei der gemeinsame Kern: In beiden Fällen ist die Stabilität der Bindung zwischen einem menschenlesbaren Identifier und dem eigentlichen Zielobjekt entscheidend. Sobald diese Bindung still austauschbar wird – sei es durch Rename/Transfer beim Repository oder durch Freigabe eines Namespace-Slots in einem Marketplace – kann Trust in der Praxis kollabieren, obwohl die Kryptografie und die Token-Mechanik formal korrekt aussehen.
Für Unternehmen mit größeren Software-Lieferketten verschiebt sich damit der Fokus von „Trusted Publishing ist grundsätzlich sicher“ hin zu „Trusted Publishing braucht saubere, stabile Identitäten und klare Betriebsprozesse“. Die 48-Stunden-Validierungslogik ist dabei vor allem ein operatives Schutzgeländer gegen lang offenstehende Konfigurationen; die Ablehnung bestimmter Token-Quellen und die Beibehaltung restriktiver GitHub-Aktionskontexte verringern zusätzlich die Angriffsfläche. Wer als Maintainer oder Plattformbetreiber Releases automatisiert, sollte Trusted-Publisher-Setups jetzt als Teil des Security-Controls-Lebenszyklus betrachten: nicht nur ein einmaliges Setup bei der Erstkonfiguration, sondern ein Asset, das bei Änderungen am Repository konsequent nachjustiert wird. So lässt sich die Lücke schließen, die SlugFest ausnutzt – und gleichzeitig bleibt das grundlegende Ziel von Trusted Publishing erhalten: weniger Geheimnisse in der Pipeline, mehr Nachvollziehbarkeit über Provanienz und ein nachvollziehbarer Veröffentlichungsweg bis zur npm-Registry.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "GitHub bremst npm Trusted Publishing: 48‑Stunden-Validierung nach Flaw" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "GitHub bremst npm Trusted Publishing: 48‑Stunden-Validierung nach Flaw" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »GitHub bremst npm Trusted Publishing: 48‑Stunden-Validierung nach Flaw« bei Google Deutschland suchen, bei Bing oder Google News!