Zwei-Faktor-Authentifizierung und Kurzzeittokens : GitHub verschärft Sicherheitsregeln für npm : Neue Maßnahmen sollen Supply-Chain-Angriffe eindämmen und das Vertrauen in Open-Source-Pakete stärken

In den vergangenen Monaten hat sich die Zahl der Angriffe auf Open-Source-Ökosysteme dramatisch erhöht. Besonders npm, die zentrale Plattform für JavaScript-Pakete, geriet ins Visier. Beim Shai-Hulud-Angriff wurde ein selbstreplizierender Wurm in Hunderte npm-Pakete eingeschleust. Dieser suchte auf Entwicklerrechnern nach geheimen Zugangsdaten und leitete sie an Server unter Kontrolle der Angreifer weiter.

Die Besonderheit: Die Malware kombinierte Selbstvermehrung mit der Fähigkeit, eine Vielzahl unterschiedlicher Secrets abzugreifen – nicht nur npm-Tokens. Experten warnen, dass ohne das schnelle Eingreifen von GitHub und der Open-Source-Community eine unendliche Angriffswelle drohte.

GitHubs Antwort: Neue Regeln für Authentifizierung und Publishing

Um diese Bedrohung einzudämmen, hat GitHub umfassende Sicherheitsänderungen angekündigt. Diese betreffen sowohl den Authentifizierungsprozess als auch die Art und Weise, wie Pakete veröffentlicht werden können.

Die Maßnahmen im Überblick:

• Verpflichtende Zwei-Faktor-Authentifizierung (2FA): Künftig muss jede Veröffentlichung von npm-Paketen über 2FA abgesichert sein.
• Kurzlebige Tokens: Tokens für granulare Berechtigungen sind nur noch sieben Tage gültig.
• Trusted Publishing: Pakete können direkt aus Continuous-Integration-Workflows über OpenID Connect veröffentlicht werden, ohne Tokens.
• Kryptografische Nachweise: Jedes veröffentlichte Paket enthält künftig eine kryptografische Bestätigung von Quelle und Build-Umgebung.

„Jedes Paket, das über Trusted Publishing veröffentlicht wird, enthält einen kryptografischen Nachweis seiner Quelle und seiner Build-Umgebung“, erklärte GitHub Ende Juli 2025. „Ihre Nutzer können überprüfen, wo und wie Ihr Paket erstellt wurde – das stärkt das Vertrauen in Ihre Lieferkette.“

Diese Schritte sollen verhindern, dass Angreifer gestohlene oder geleakte Tokens langfristig missbrauchen. Durch Trusted Publishing entfällt zudem die Notwendigkeit, Tokens in Build-Umgebungen zu hinterlegen, was ein hohes Risiko für Exfiltration eliminiert.

Umfassende Änderungen im npm-Ökosystem

Um die neuen Sicherheitsstandards durchzusetzen, setzt GitHub auf eine Reihe tiefgreifender Anpassungen:

• Abkündigung klassischer Legacy-Tokens
• Migration von zeitbasierten Einmalpasswörtern (TOTP) hin zu FIDO-basierter Zwei-Faktor-Authentifizierung
• Begrenzung granularer Tokens mit Veröffentlichungsrechten auf kurze Gültigkeit
• Standardmäßige Sperre für Veröffentlichungsrechte über Tokens, mit Förderung von Trusted Publishing oder lokalem Publishing unter 2FA
• Entfernung der Möglichkeit, 2FA beim lokalen Publishing zu umgehen
• Erweiterung der zugelassenen Anbieter für Trusted Publishing

Diese Maßnahmen zielen darauf ab, Angriffsflächen systematisch zu reduzieren und den Missbrauch von Zugangsdaten zu erschweren.

Blick über den Tellerrand: Andere Ökosysteme ziehen nach

Die npm-Community steht mit diesen Veränderungen nicht allein. Kurz zuvor hatte NuGet für .NET Trusted Publishingeingeführt, während Ruby Central neue Regeln zur Absicherung von RubyGems ankündigte. Nur noch direkt von Ruby Central beschäftigte oder beauftragte Entwickler dürfen künftig administrative Rechte über RubyGems.org und die zugehörigen GitHub-Repositories halten.

Dieser Trend zeigt: Die Sicherung von Software-Lieferketten entwickelt sich zu einem Standard, dem sich kein Ökosystem entziehen kann.

Neue Angriffstechniken: Malware in QR-Codes versteckt

Parallel zu den GitHub-Ankündigungen machte ein weiterer Vorfall Schlagzeilen. Das Sicherheitsteam von Socket entdeckte ein bösartiges npm-Paket mit dem Namen fezbox. Dieses tarnte sich als harmlose JavaScript-Bibliothek mit Helferfunktionen, enthielt jedoch eine raffinierte Payload.

Das Besondere: Die Schadsoftware nutzte ein QR-Code-basiertes Verfahren, um den eigentlichen Angriffscode zu verschleiern. Dabei wurde ein QR-Code von einem entfernten Server geladen, in dem sich der versteckt eingebettete JavaScript-Code befand. Dieser versuchte, über Cookies gespeicherte Anmeldedaten auszulesen und an einen externen Server zu senden.

Das Paket steht nicht länger zum Download über npm bereit. Seit seiner Erstveröffentlichung am 21. August 2025 wurde es insgesamt 490 Mal heruntergeladen.

Zwar speichern moderne Anwendungen selten Passwörter in Cookies, dennoch zeigt diese Technik, wie kreativ Angreifer bei der Tarnung ihrer Malware vorgehen. Für Sicherheitsforscher ist klar: Solche innovativen Methoden verdeutlichen die Notwendigkeit spezialisierter Werkzeuge zur Überprüfung von Abhängigkeiten.

Bedeutung für Unternehmen und Entwickler

Die Ankündigungen von GitHub markieren einen Wendepunkt in der Absicherung von Open-Source-Ökosystemen. Für Entwickler bedeutet dies zunächst eine Anpassung ihrer Arbeitsweise, insbesondere durch die verpflichtende Zwei-Faktor-Authentifizierung und die Umstellung auf kurzlebige Tokens oder Trusted Publishing.

Langfristig jedoch entsteht dadurch ein robusteres Sicherheitsmodell, das das Vertrauen in die Integrität von npm-Paketen stärkt. Unternehmen können sicherer darauf vertrauen, dass Pakete aus nachprüfbaren Quellen stammen und Manipulationen frühzeitig erkannt werden.

Fazit: Ein Schritt hin zu widerstandsfähigeren Lieferketten

Die jüngsten Angriffe haben einmal mehr gezeigt, wie verwundbar Software-Lieferketten sind. Mit den neuen Sicherheitsmaßnahmen reagiert GitHub konsequent auf die Bedrohungslage. Durch verpflichtende Zwei-Faktor-Authentifizierung, Kurzzeittokens und Trusted Publishing wird die Basis für eine widerstandsfähigere Infrastruktur gelegt.

Zugleich zeigt der Fall fezbox, dass Angreifer weiterhin nach innovativen Wegen suchen, um Sicherheitsmechanismen zu umgehen. Der Schutz der Lieferkette bleibt daher ein fortlaufender Prozess – und GitHubs Schritt dürfte nur der Anfang einer breiteren Bewegung sein.