Der GitHub-Sicherheitsvorfall: Ihre vertrauenswürdigsten Tools sind jetzt das Einfallstor für Angriffe.

Am Morgen des 19. Mai öffnete ein GitHub-Entwickler seinen Laptop, und eine VS-Code-Erweiterung, die er vor Monaten installiert hatte, aktualisierte sich automatisch im Hintergrund. Innerhalb weniger Minuten las Schadcode Zugangsdaten aus dem Speicher und übermittelte sie an einen Angreifer. Innerhalb weniger Stunden hatte sich dieser Angreifer Zugang zur GitHub-Infrastruktur verschafft und klonte interne Repositories mit den Zugangsdaten des Entwicklers. Schließlich wurden rund 3,800 dieser Repositories von einer Gruppe namens TeamPCP in einem kriminellen Forum zum Verkauf angeboten.

GitHubs Vorgehen war vorbildlich: schnell, kontrolliert und begrenzt. Kundendaten waren nicht betroffen, und es gab keine Auswirkungen auf den Produktivbetrieb. Für Mitglieder von GRC-Teams dürfte dies jedoch beunruhigend sein. Der Angriffspunkt war weder eine Zero-Day-Schwachstelle noch eine Phishing-Kampagne. Es handelte sich vielmehr um ein beliebtes Entwicklertool eines verifizierten Anbieters, das genau das tat, was es sollte.

Das elfminütige Zeitfenster

GitHub zählt zu den weltweit sicherheitstechnisch fortschrittlichsten Unternehmen im Technologiebereich. Die Frage ist also nicht, was übersehen wurde, sondern vielmehr, worauf der Angriff abzielte und wofür die bestehenden Sicherheitsvorkehrungen nicht ausgelegt waren.

Im Zentrum stand eine einzige Erweiterung: Nx Console. Sie verzeichnet 2.2 Millionen Installationen, ein verifiziertes Herausgeberabzeichen und eine lange Wartungshistorie. Der Angreifer drang also nicht in den Marketplace ein. Stattdessen stahl er die Zugangsdaten eines Entwicklers aus einem früheren Angriff auf die vorgelagerte Software, nutzte sie, um eine manipulierte Version unter dem Namen des legitimen Herausgebers zu veröffentlichen, und wartete auf das automatische Update.

Die manipulierte Version war elf bis achtzehn Minuten online, bevor die Nx-Entwickler den fehlerhaften Release bemerkten und sie entfernten. Microsoft meldete zunächst 28 Installationen. Die Telemetriedaten von Nx zeigten jedoch später, dass die tatsächliche Zahl über 6,000 lag. Eine dieser Installationen landete auf dem Rechner eines GitHub-Entwicklers.

Sobald der Entwickler einen Arbeitsbereich öffnete, sammelte der Schadcode Sitzungsanmeldeinformationen, SSH-Schlüssel und Cloud-Geheimnisse ein und exfiltrierte sie anschließend.

Warum Standard-Frameworks dies nicht erkannt haben

Alle gängigen Kontrollrahmenwerke fordern bereits das, was GitHub bot. SOC 2 schreibt Zugriffskontrollen und Endpunktschutz vor. ISO 27001 deckt sichere Entwicklung und Lieferantenmanagement ab. Und NIST 800-53 befasst sich mit Konfigurationsmanagement und Lieferkettenrisiken. Daher konnte GitHub mit ziemlicher Sicherheit in allen Bereichen positive Berichte vorweisen.

Das Problem liegt also nicht darin, dass die Frameworks fehlerhaft sind. Vielmehr basieren sie auf einem Vertrauensmodell, das Angreifer inzwischen umkehren können. Die erste Annahme, die sich als falsch erweist, ist, dass Entwicklerendpunkte gewöhnliche Unternehmensgeräte sind. Das sind sie nicht.

Auf dem Rechner eines Entwicklers werden aktive Cloud-Sitzungen, SSH-Schlüssel, Git-Zugangsdaten, Umgebungsvariablen, CI/CD-Token und API-Schlüssel für KI-Programmierassistenten gespeichert. Ein einziger kompromittierter Laptop fungiert somit als Schlüsselbund für alle nachgelagerten Systeme. Dennoch stufen die meisten Klassifizierungssysteme für Assets diese Endpunkte weiterhin auf dieselbe Stufe wie den Outlook-Account eines Finanzmanagers. Genau hier liegt die Lücke in der Governance, und deren Schließung ist in erster Linie ein GRC-Problem (Governance, Risk & Compliance) und erst dann ein Sicherheitsproblem.

Ein neues Glied der Vertrauenskette wird angegriffen

GitHub spielt in dieser Geschichte keine herausragende Rolle. Vielmehr lässt sich ein größeres Muster erkennen, und GitHub ist derzeit lediglich die sichtbarste Organisation.

Die Software-Lieferkette basiert seit jeher auf einer Vertrauenskette. Das heißt, ein Entwickler vertraut einer Erweiterung, die Erweiterung vertraut einem Maintainer, der Maintainer vertraut einer Registry und die Registry vertraut den Berechtigungsnachweisen des Herausgebers, die in einer Umgebungsvariablen auf dem Rechner eines anderen Benutzers gespeichert sind. Jede Verbindung setzt also voraus, dass die dahinterliegende intakt ist.

In den letzten Monaten hat TeamPCP systematische Angriffe auf die Vertrauensbasis von Entwicklern gestartet und in rund 20 Wellen Schadsoftware in über 500 Open-Source-Paketen versteckt. OpenAI, Mercor und Mistral AI sind bestätigte Opfer. Die Dunkelziffer der unentdeckten Sicherheitslücken ist jedoch deutlich höher.

TeamPCPs Vorgehensweise besteht daher darin, die Blockchain selbst anzugreifen, anstatt einzelne Glieder. Der Angriff auf die Nx Console begann mit einem Maintainer-Token, das aus einem früheren Angriff auf TanStack stammte. Und das ist der ganze Vorgang. Die Nx Console-Erweiterung war bereits genehmigt, installiert und befand sich mit Ausführungsberechtigung bereits in der Entwickler-IDE.

Der Angreifer musste also nichts davon überwinden. Er musste lediglich das System kompromittieren, dem der Entwickler bereits vertraute, und dieses Vertrauen erledigte den Rest.

Was dies für die nächste Lieferantenbewertung bedeutet

Wenn die Vertrauenskette selbst angegriffen wird, stellt sich praktisch die Frage, welche Glieder Ihrer eigenen Kette sich derzeit außerhalb Ihres Governance-Perimeters befinden.

Beginnen Sie mit dem Drittanbieter-Risikoregister, der Liste der externen Anbieter, die Ihr Unternehmen formal erfasst. Die meisten Listen umfassen Salesforce, AWS und alle Vertragspartner. Sie lassen jedoch die kleinen Entwicklertools außer Acht, die Ihre Ingenieure selbst installieren, die öffentlichen Codebibliotheken, von denen diese Tools abhängen, und die zugehörigen Entwickler. Keines dieser Tools durchläuft das Beschaffungsverfahren. Und doch führen sie alle Code auf Maschinen aus, die Schlüssel zu Produktionssystemen enthalten. Daher müssen sie wie Anbieter behandelt werden, zumindest in Bezug auf alles, was Anmeldeinformationen oder Build-Pipelines betrifft. Der Nx-Entwickler, dessen Token gestohlen wurde, hatte keinen Vertrag mit GitHub. De facto war er jedoch für jedes Unternehmen, das seine Erweiterung nutzte, ein Anbieter.

Als Nächstes steuert der Entwickler-Endpunkt die Regeln für die Nutzung der Laptops von Entwicklern. Dürfen Entwickler beliebige Erweiterungen installieren oder nur genehmigte? Installiert sich eine neue Version automatisch im Hintergrund? Und wenn auf diesem Laptop etwas Verdächtiges passiert, überwachen die Sicherheitstools ihn dann genauso genau wie einen Produktivserver? In den meisten Unternehmen lautet die Antwort auf alle drei Fragen: Nein. Daher werden die Laptops mit den mächtigsten Zugangsdaten weniger streng kontrolliert als die Server, die mit diesen Zugangsdaten entsperrt werden.

Dann gibt es noch die Anmeldeinformationen, Schlüssel und Token, die die Handlungsberechtigung eines Systems beweisen. Die meisten sind zu lange gültig und werden zu leicht weitergegeben. Ein Token, der einem Laptop zugewiesen ist, kann monatelang ungenutzt bleiben, und wenn der Laptop kompromittiert wird, erbt der Angreifer alle seine Zugriffsrechte. Die Lösung besteht also darin, die Gültigkeitsdauer zu verkürzen und die Reichweite einzuschränken: Token, die nach wenigen Stunden ablaufen, Systeme, die bei jedem Start neue Anmeldeinformationen abrufen, und Schlüssel, die auf sicherer Hardware auf dem Gerät gespeichert sind. Nichts davon ist ungewöhnlich. Doch all das erfordert, dass jemand die Verantwortung für die Migration übernimmt, und genau hier stagniert die Diskussion.

GitHub zählt zu den sichersten technischen Organisationen weltweit, und dennoch gelang es dem Angreifer, einzudringen. Das nächste Unternehmen auf der Liste wird also nicht über GitHubs Erkennungs-, Reaktions- und Kommunikationsfähigkeiten verfügen. Die von TeamPCP industrialisierte Vertrauensbasis liegt fast vollständig außerhalb dessen, was herkömmliche Governance abdecken soll. Diese Lücke schließt sich stetig.