Liebe Lesende,
Diese Woche war ungewöhnlich. In den letzten Monaten haben wir eine Reihe signifikanter Lieferkettenangriffe erlebt. Die Community schlägt schon länger Alarm, und die Wahrheit ist, dass wir uns auf dünnem Eis bewegen. Es scheint unvermeidlich, dass etwas Größeres, etwas Schlimmeres bevorsteht.
In diesem Beitrag möchte ich einige der wichtigsten Erkenntnisse dieser Woche teilen. Ich hatte die Gelegenheit, mich mit Josh Junon, besser bekannt als Qix, zusammenzusetzen und ihn zu seinen Erfahrungen inmitten dieser Tortur zu befragen. Josh ist der Maintainer, der bei dem Phishing-Angriff kompromittiert wurde, und er steckt auch hinter einigen der am weitesten verbreiteten Pakete im npm-Ökosystem.
Bevor wir in dieses Gespräch eintauchen (Siehe das Interview unten), werfen wir einen kurzen Blick zurück auf die Ereignisse, die uns hierher geführt haben.
Prolog – Auswirkungen
Am Montag, als ich die Warnmeldungen in unserem internen Aikido Intel-Dashboard zum ersten Mal sah, war sofort klar, dass dies eines jener Worst-Case-Szenarien sein könnte, die mir den Schlaf rauben. Wichtige Pakete wie debug, chalk und sechzehn weitere waren mit Malware kompromittiert worden. Die potenziellen Auswirkungen waren nichts weniger als katastrophal.
Die Zahlen sprechen für sich:
- Zusammen werden die kompromittierten Pakete etwa 2,6 Milliarden Mal pro Woche heruntergeladen.
- JFrog schätzt, dass die bösartigen Versionen allein etwa 2,6 Millionen Mal heruntergeladen wurden.
- Wiz berichtete, dass 99 % ihrer Cloud-Umgebungen auf mindestens eines dieser Pakete angewiesen sind, und in 10 % der Fälle der bösartige Code vorhanden war.
Nach jeder Einschätzung war dies ein knapper Ausgang. Wie viele seitdem bemerkt haben, sind wir nur knapp einer Katastrophe entgangen. Der einzige Grund, warum der Schaden nicht weitaus schlimmer war, liegt an zwei Faktoren:
- Die Angreifer konzentrierten sich ausschließlich auf den Diebstahl von Kryptowährungen.
- Sie unternahmen große Anstrengungen, um unentdeckt zu bleiben.
Doch die Geschichte erinnert uns daran, wie zerbrechlich dieses Glück sein kann. Wir müssen nur auf den 26. August 2025 zurückblicken, um zu sehen, was passiert, wenn ein Angreifer bei der Ausführung weniger vorsichtig ist.
Prolog – Nx-Kompromittierung
Am 26. August wurde der Nx-Paketmanager kompromittiert, doch die Angreifer wählten ein ganz anderes Vorgehen:
- Sie exfiltrierten Secrets und Tokens von Entwickelnden-Maschinen und veröffentlichten sie öffentlich auf GitHub.
- Sie nutzten diese Tokens dann, um in GitHub-Konten einzubrechen, wobei sie private Repositories öffentlich zugänglich machten.
Es war ein klassischer Smash-and-Grab-Angriff. Eine deutliche Erinnerung daran, dass die Kompromittierung eines weit verbreiteten Pakets nicht nur Unannehmlichkeiten verursacht. Sie kann echten, dauerhaften Schaden anrichten. In vielerlei Hinsicht war es ein Warnschuss, der zeigte, wie exponiert wir sind.
Das Gespräch mit Josh
Nachdem wir Josh kontaktiert hatten, um ihn über die Kompromittierung zu informieren und unsere Gespräche danach fortsetzten, erkannten mein Kollege Mackenzie und ich, dass es faszinierend wäre, sich mit ihm zusammenzusetzen und aus erster Hand zu erfahren, wie diese Erfahrung für ihn war. Glücklicherweise war Josh dafür offen.
Es folgte ein nachdenkliches und offenes Gespräch, das einen bleibenden Eindruck bei mir hinterließ. Ich möchte hier einige meiner wichtigsten Erkenntnisse mit Ihnen teilen. Wenn Sie den vollständigen Kontext wünschen, können Sie die gesamte 45-minütige Diskussion hier ansehen:
Einblick: Vertrauen durch Verletzlichkeit
Sicherheit dreht sich normalerweise um die Beseitigung von Schwachstellen. Doch im Open Source ist Vertrauen nur durch Verletzlichkeit möglich. Maintainer stellen ihren Code und einen Teil von sich selbst der Welt zur Verfügung, setzen ihn Milliarden von Downloads und unzähligen Benutzern aus. Diese Offenlegung erfordert einen Vertrauensvorschuss.
Als Josh offen darüber sprach, wie er Opfer eines Phishing-Angriffs wurde, zeigte er eine Verletzlichkeit, die das Vertrauen tatsächlich stärkt. Indem er Fehler zugab, transparent war und sich weiterhin in der Community engagierte, erinnerte er uns daran, dass Open Source nicht von gesichtslosen Konzernen, sondern von Menschen betrieben wird. Und das Vertrauen in diese Menschen ist es, was das gesamte System zum Funktionieren bringt.
Letztendlich besteht das Paradox darin, dass Sicherheit darauf abzielt, Schwachstellen zu beseitigen, aber Vertrauen im Open Source darauf aufbaut.
Ich denke, was einen riesigen Unterschied gemacht hat, war die allgemeine Reaktion. Ich weiß, es wurde einige Male darauf hingewiesen, dass die Verletzlichkeit geschätzt wurde. Und ich glaube, das wusste ich schon vorher. Ich hatte selbst schon ein paar Fälle im Open Source, wo ich Fehler gemacht habe, nicht sicherheitstechnisch, sondern einfach nur transparent und ehrlich war – und das hat sofort vielen Leuten Kopfschmerzen, Zeit und Geld erspart. Und das wird immer geschätzt.
Einblick: Der Weg in Open Source
Josh hatte nie vor, eine Säule des JavaScript-Ökosystems zu werden. Er begann als Teenager mit dem Programmieren, experimentierte mit PHP, C# und JavaScript, und Open Source war für ihn einfach ein Ort, um Projekte zu teilen, die ihn interessierten. Er fühlte sich zu Dingen hingezogen wie dem Hinzufügen von Farben zu Terminals oder dem Erstellen kleiner Utilities, ohne jemals zu ahnen, dass diese einmal den Kern moderner Software bilden würden.
Im Laufe der Zeit führten seine Beiträge zu größeren Verantwortlichkeiten. Für einige Bibliotheken, wie chalk, wurde er nach dem Beitragen von Fixes als Maintainer eingeladen. Für andere, wie debug, übernahm er die Verantwortung von früheren Maintainern. Was als spielerisches Herumbasteln begann, entwickelte sich allmählich zur Pflege einiger der meistgenutzten Pakete im Ökosystem.
Jahre später fand sich Josh für Milliarden wöchentlicher Downloads verantwortlich. Was einst kleine Nebenprojekte waren, war zu kritischer Internetinfrastruktur geworden. Nicht durch sorgfältige Planung oder Ehrgeiz, sondern einfach dadurch, dass er zur richtigen Zeit am richtigen Ort war und „Ja“ sagte, als er um Hilfe gebeten wurde.
Sie wurden an immer mehr Orten eingesetzt, wahrscheinlich sogar an einigen, wo sie niemals hätten sein sollen. Ehrlich gesagt, einige dieser Pakete sollten überhaupt nicht existieren, und ich werde der Erste sein, der das zugibt. Dann wachst du eines Tages auf und stellst fest, dass ein kleines Utility, das du geschrieben hast, um Array-Werte zu verschieben, von 55.000 Menschen genutzt und 300 Millionen Mal pro Woche heruntergeladen wird. Du hast nie um diese Verantwortung gebeten.
Einblick: Die Ohnmacht des Kontrollverlusts
Der vielleicht schwierigste Teil des Vorfalls für Josh war nicht die Erkenntnis, dass er Opfer eines Phishing-Angriffs geworden war. Es war die darauf folgende Hilflosigkeit. Sobald die Angreifer sein Passwort und den 2FA-Code hatten, waren sie in den Augen von npm im Wesentlichen er. Sie setzten seine 2FA-Tokens zurück, änderten Authentifizierungsdetails und sperrten ihn aus seinem eigenen Konto aus. Selbst grundlegende Aktionen wie das Zurücksetzen seines Passworts oder die Wiederherstellung des Zugangs funktionierten nicht.
Fast 12 Stunden lang konnte Josh nur von außen zusehen, wie sich bösartige Versionen seiner Pakete im Internet verbreiteten. Er hatte keine Möglichkeit, direkt einzugreifen, keinen Knopf zum Drücken, keinen schnellen Kanal zum npm-Support. Stattdessen war er gezwungen, sich auf öffentliche Hilfeforen zu verlassen und zu warten.
Das Gefühl der Ohnmacht blieb ihm haften. Wie er es ausdrückte, gab es keine Transparenz, keine Tools für einen Maintainer in der Krise, um die Kontrolle zurückzugewinnen. Inmitten einer der größten Supply-Chain-Kompromittierungen der jüngsten Vergangenheit wurde die Person, der diese Pakete am meisten anvertraut waren, untätig am Spielfeldrand zurückgelassen.
Der Passwort-Reset-Button funktionierte nicht. Ich habe während des gesamten Vorfalls keine einzige E-Mail erhalten. Das Zurücksetzen des Passworts bewirkte nichts. Selbst wenn die E-Mail-Adresse im Konto noch dieselbe war, was ich immer noch irgendwie glaube, funktionierte das Zurücksetzen des Passworts nicht… Es gab keine andere Möglichkeit, als npm über ihr öffentliches, nicht authentifiziertes Hilfeformular zu kontaktieren.
Einblick: Einem Unglück entgangen
Die Malware, die in chalk, debug und den anderen kompromittierten Paketen platziert wurde, war ernsthaft, aber ihr Umfang war seltsam begrenzt. Sie versuchte, Kryptowährung zu stehlen, indem sie sich in Browser-Kontexte einschleuste. Diese Entscheidung der Angreifer, sei es aus Gier oder Kurzsichtigkeit, ist der einzige Grund, warum die Folgen nicht viel schlimmer waren.
Wie Josh es ausdrückte, hätte dies leicht katastrophal sein können. Diese Pakete laufen überall: auf Laptops, Enterprise-Servern, CI/CD-Pipelines und Cloud-Umgebungen. Sie hätten AWS-Schlüssel exfiltrieren, Secrets leaken oder Dateien für Lösegeld verschlüsseln können. Stattdessen beschränkten sich die Angreifer auf ein enges Ziel.
Es hätte alles tun können und wurde ausgeführt… auf Unternehmensrechnern, persönlichen Rechnern, in kleinen Unternehmen, in CI/CD-Pipelines. Und die Tatsache, dass es nichts [Schlimmeres] getan hat, war die Kugel, der wir ausgewichen sind.
Die Lektion ist nicht, dass das System funktioniert hat. Es ist, dass das Glück diesmal auf unserer Seite war. Es als „Nothing Burger“ abzutun, verfehlt den Punkt. Der nächste Angreifer könnte nicht so zurückhaltend sein.
Einblick: Die menschlichen Kosten von Open Source
Hinter jedem weit verbreiteten Paket steht ein Mensch, der oft still und unauffällig arbeitet. Für Josh war der schwierigste Teil nicht nur die technische Kompromittierung. Es war die emotionale Belastung, die darauf folgte. Er beschrieb den ersten Tag als reinen Autopilot, bei dem er versuchte, den Schaden einzudämmen. Erst danach traf ihn die Last: Peinlichkeit, Angst und der beunruhigende Gedanke, dass sein Fehler Menschen hätte verletzen können.
Das war Montag. Als ich mein Konto an diesem Nachmittag oder Abend zurückbekam, war es so, als könnte ich den Schalter umlegen und jetzt einfach im Bett liegen, an die Decke starren und darüber nachdenken, was gerade passiert war… Der nächste Tag war nur Peinlichkeit. Ich wollte mein Gesicht nicht zeigen. Ich wollte nicht nach draußen gehen.
Das ist die verborgene Realität von Open Source. Kleine Projekte, die „zum Spaß“ erstellt wurden, werden zu kritischer Infrastruktur und verzeichnen Milliarden von Downloads. Maintainer haben nie um diese Verantwortung gebeten, doch sie tragen den Stress, wenn etwas schiefgeht. Die Community sieht den Code, übersieht aber oft die menschlichen Kosten seiner Pflege.
Joshs Erfahrung ist eine Erinnerung daran, dass es bei der Ökosystem-Sicherheit nicht nur um stärkere MFA oder schnellere Incident Response geht. Es geht auch darum, die Maintainer zu unterstützen, die diese Verantwortung tragen – Grenzen zu respektieren, Empathie zu zeigen und anzuerkennen, dass Vertrauen von den Menschen hinter dem Code abhängt.
Handlungsaufforderung
Dieser Vorfall hat gezeigt, wie eine einzige Kompromittierung die gesamte Software-Lieferkette durchdringen kann. Diesmal war es nicht katastrophal, hätte es aber leicht sein können. Die Lehre daraus ist nicht, in Panik zu geraten, sondern zu handeln.
- Für Registries (npm, PyPI, etc.): Erzwingen Sie phishing-resistente MFA für wichtige Maintainer und stellen Sie klare, schnelle Reaktionskanäle bereit, wenn Konten kompromittiert werden.
- Für Organisationen: Verbessern Sie die Abhängigkeits-Hygiene. Legen Sie Versionen fest, überwachen Sie Manipulationen und integrieren Sie Sicherheitsprüfungen der Lieferkette in CI/CD-Pipelines.
Für Maintainer: Verwenden Sie Hardware-Schlüssel, vermeiden Sie schnelle Sicherheitsentscheidungen unter Stress und setzen Sie auf Transparenz, wenn etwas schiefgeht. - Für die Community: Unterstützen Sie die Menschen hinter Open Source. Respektieren Sie ihre Grenzen, stellen Sie Ressourcen bereit, wo immer möglich, und reagieren Sie mit Empathie, wenn Fehler passieren.
Die eigentliche Handlungsaufforderung ist einfach: Betrachten Sie die Ökosystem-Sicherheit als gemeinsame Verantwortung. Plattformen, Unternehmen und Communities spielen alle eine Rolle dabei, sicherzustellen, dass der nächste Vorfall nicht zu etwas Schlimmerem eskaliert.
Epilog
Es war eine surreale Woche, im Auge eines Sturms zu sein, der so viel Presse und Aufmerksamkeit auf sich zog, und das aus gutem Grund. Die Ereignisse in Echtzeit zu beobachten, von den ersten Warnmeldungen in unserem Dashboard bis zur Flut öffentlicher Berichte, fühlte sich an, als stünde man auf einer Verwerfungslinie, während sich der Boden unter uns verschob. Dies ist eine Erinnerung daran, wie zerbrechlich unser Ökosystem ist.
Was sich ereignete, kam dem Worst-Case-Szenario, über das ich mir in der Open-Source-Sicherheit täglich Sorgen mache, unangenehm nahe. Doch das, was ich am meisten fürchte, ist nicht die Phishing-E-Mail, die Malware oder gar die Schlagzeilen. Es ist, dass wir diesen Moment ohne Veränderung verstreichen lassen.
Wenn die Branche die Achseln zuckt, dies als nur einen weiteren Vorfall behandelt und wieder zum Tagesgeschäft übergeht, werden wir nichts gelernt haben. Und das nächste Mal, denn es wird ein nächstes Mal geben, haben wir vielleicht nicht so viel Glück. Das erste Mal: Schande über die Angreifer. Das zweite Mal: Schande über uns.
Und wenn wir keine Schritte unternehmen, um daraus zu lernen, könnte die stille Erosion des Vertrauens in Open Source die schädlichste Konsequenz von allen sein.
