Sehr geehrte Leserinnen und Leser,

Diese Woche war seltsam. In den letzten Monaten gab es eine Reihe schwerwiegender Lieferkettenangriffe. Die Community schlägt schon seit einiger Zeit Alarm, und in Wahrheit bewegen wir uns auf dünnem Eis. Es scheint unvermeidlich, dass etwas Größeres, etwas Schlimmeres bevorsteht.

In diesem Beitrag möchte ich einige der wichtigsten Erkenntnisse dieser Woche mit Ihnen teilen. Ich hatte die Gelegenheit, mich mit Josh Junon, besser bekannt als Qix, zu unterhalten und ihn zu seinen Erfahrungen während dieser schwierigen Zeit zu befragen. Josh ist der Maintainer, der Opfer des Phishing-Angriffs wurde, und er steht auch hinter einigen der am häufigsten verwendeten Pakete im npm-Ökosystem.

Bevor wir uns diesem Gespräch zuwenden (siehe Interview unten), lassen Sie uns einen kurzen Rückblick auf die Ereignisse werfen, die uns hierher geführt haben.

Prolog – Auswirkungen

Als ich am Montag zum ersten Mal die Warnmeldungen in unserem internen Aikido sah, war mir sofort klar, dass dies eines der schlimmsten Szenarien sein könnte, die mich nachts wach halten. Wichtige Pakete wie Debug, Chalk und sechzehn weitere waren mit Malware infiziert worden. Die potenziellen Folgen waren geradezu katastrophal.

Die Zahlen sprechen für sich:

• Insgesamt werden die kompromittierten Pakete jede Woche rund 2,6 Milliarden Mal heruntergeladen.
• JFrog schätzt, dass allein die bösartigen Versionen etwa 2,6 Millionen Mal heruntergeladen wurden.
• Wiz , dass 99 % ihrer Cloud-Umgebungen auf mindestens eines dieser Pakete angewiesen sind und in 10 % der Fälle der bösartige Code vorhanden war.

Es war in jeder Hinsicht eine knappe Sache. Wie viele seitdem festgestellt haben, sind wir nur knapp einer Katastrophe entgangen. Dass der Schaden nicht noch viel schlimmer ausgefallen ist, ist auf zwei Faktoren zurückzuführen:

• Die Angreifer hatten es ausschließlich auf den Diebstahl von Kryptowährung abgesehen.
• Sie unternahmen große Anstrengungen, um unentdeckt zu bleiben.

Die Geschichte erinnert uns jedoch daran, wie fragil 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 sorgfältig vorgeht.

Prolog – Nx-Kompromiss

Am 26. August wurde der Nx-Paketmanager kompromittiert, aber die Angreifer wählten eine ganz andere Vorgehensweise:

• Sie haben secrets Tokens von Entwicklerrechnern exfiltriert und öffentlich auf GitHub veröffentlicht.
• Anschließend nutzten sie diese Tokens, um sich Zugang zu GitHub-Konten zu verschaffen und private Repositorys öffentlich zugänglich zu machen.

Es war ein klassischer Raubüberfall. Eine deutliche Erinnerung daran, dass die Kompromittierung eines weit verbreiteten Pakets nicht nur Unannehmlichkeiten verursacht. Es kann echte, dauerhafte Schäden verursachen. In vielerlei Hinsicht war es ein Warnschuss, der zeigte, wie verwundbar wir sind.

Das Gespräch mit Josh

Nachdem wir Josh kontaktiert hatten, um ihn über den Kompromiss zu informieren, und unsere Gespräche danach fortgesetzt hatten, kamen meine Kollegin Mackenzie und ich zu dem Schluss, dass es faszinierend wäre, uns mit ihm zusammenzusetzen und aus erster Hand zu erfahren, wie diese Erfahrung für ihn war. Glücklicherweise war Josh dafür offen. 

Was folgte, war ein nachdenkliches und offenes Gespräch, das mich sehr beeindruckt hat. Ich möchte Ihnen hier einige meiner wichtigsten Erkenntnisse mitteilen. Wenn Sie den vollständigen Kontext sehen möchten, können Sie sich hier die gesamte 45-minütige Diskussion ansehen:

Einblick: Vertrauen durch Verletzlichkeit

Bei der Sicherheit geht es in der Regel darum, Schwachstellen zu beseitigen. Bei Open Source hingegen ist Vertrauen nur aufgrund von Schwachstellen möglich. Die Entwickler veröffentlichen ihren Code und damit einen Teil ihrer selbst und setzen ihn damit Milliarden von Downloads und unzähligen Nutzern aus. Diese Offenlegung erfordert einen Vertrauensvorschuss.

Als Josh offen darüber sprach, wie er Opfer eines Phishing-Angriffs geworden war, zeigte er eine Verletzlichkeit, die das Vertrauen tatsächlich stärkt. Indem er Fehler zugab, transparent war und mit der Community in Kontakt blieb, erinnerte er uns daran, dass Open Source nicht von anonymen Unternehmen, sondern von Menschen betrieben wird. Und das Vertrauen in diese Menschen ist es, was das gesamte System funktionieren lässt.

Letztendlich besteht das Paradox darin, dass Sicherheit darauf abzielt, Schwachstellen zu beseitigen, während Vertrauen in Open Source gerade darauf aufgebaut ist.

Ich denke, was einen großen Unterschied gemacht hat, ist die allgemeine Reaktion. Ich weiß, dass mehrfach darauf hingewiesen wurde, dass die Offenlegung der Schwachstelle sehr geschätzt wurde. Und ich glaube, das wusste ich auch schon vorher. Ich hatte schon einige Fälle im Open-Source-Bereich, in denen ich selbst Fehler gemacht habe, nicht in Bezug auf die Sicherheit, sondern einfach in Bezug auf Transparenz und Ehrlichkeit – und dadurch habe ich vielen Menschen sofort eine Menge Kopfzerbrechen, Zeit und Geld erspart. Und das wird immer geschätzt.

Einblick: Der Einstieg in Open Source

Josh hatte nie vor, eine tragende Säule des JavaScript-Ökosystems zu werden. Als Teenager begann er mit dem Programmieren und experimentierte mit PHP, C# und JavaScript. Open Source war für ihn lediglich ein Ort, an dem er Projekte teilen konnte, die ihn interessierten. Er interessierte sich für Dinge wie das Hinzufügen von Farben zu Terminals oder das Erstellen kleiner Dienstprogramme und hätte nie gedacht, dass diese einmal zum Kern moderner Software werden würden.

Im Laufe der Zeit führten seine Beiträge zu größeren Verantwortlichkeiten. Bei einigen Bibliotheken, wie beispielsweise chalk, wurde er nach seinen Beiträgen zur Fehlerbehebung als Maintainer eingeladen. Bei anderen, wie beispielsweise debug, übernahm er die Verantwortung von früheren Maintainern. Was als Hobby begann, entwickelte sich nach und nach zur Pflege einiger der am häufigsten verwendeten Pakete im Ökosystem.

Jahre später war Josh für Milliarden von wöchentlichen Downloads verantwortlich. Was einst kleine Nebenprojekte gewesen waren, war zu einer wichtigen 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, an denen sie niemals hätten eingesetzt werden dürfen. Ehrlich gesagt, einige dieser Pakete sollten gar nicht existieren, und ich bin der Erste, der das zugibt. Dann wacht man eines Tages auf und stellt fest, dass ein kleines Dienstprogramm, das man geschrieben hat, um Array-Werte zu verschieben, von 55.000 Menschen genutzt und 300 Millionen Mal pro Woche heruntergeladen wird. Man hat nie um diese Verantwortung gebeten.

Einblick: Die Ohnmacht, die Kontrolle zu verlieren

Das Schwierigste an diesem Vorfall war für Josh vielleicht nicht die Erkenntnis, dass er Opfer eines Phishing-Angriffs geworden war, sondern die Hilflosigkeit, die darauf folgte. Sobald die Angreifer sein Passwort und seinen 2FA-Code hatten, waren sie in den Augen von npm im Grunde genommen er selbst. Sie setzten seine 2FA-Token zurück, änderten die Authentifizierungsdaten und sperrten ihn aus seinem eigenen Konto aus. Selbst grundlegende Maßnahmen wie das Zurücksetzen seines Passworts oder die Wiederherstellung des Zugriffs 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 im Gedächtnis. Wie er selbst sagte, gab es keine Transparenz und keine Instrumente, mit denen ein Maintainer in einer Krisensituation die Kontrolle zurückgewinnen konnte. Mitten in einer der größten Kompromittierungen der Lieferkette der jüngeren Vergangenheit wurde die Person, der man in Bezug auf diese Pakete am meisten vertraute, an den Rand gedrängt.

Die Schaltfläche zum Zurücksetzen des Passworts hat nicht funktioniert. Ich habe während des gesamten Vorgangs keine E-Mails erhalten. Das Zurücksetzen des Passworts hat nichts bewirkt. Selbst wenn die E-Mail-Adresse des Kontos noch dieselbe war, was ich immer noch glaube, hat das Zurücksetzen des Passworts nicht funktioniert... Es gab keine andere Möglichkeit, als npm über das öffentliche, nicht authentifizierte Hilfeformular zu kontaktieren.

Einblick: Eine Kugel ausgewichen

Die in Chalk, Debug und anderen kompromittierten Paketen eingeschleuste Malware war zwar schwerwiegend, aber ihr Anwendungsbereich war seltsamerweise sehr begrenzt. Sie versuchte, Kryptowährung zu stehlen, indem sie sich in Browserkontexte einschleuste. Diese Entscheidung der Angreifer, sei es aus Gier oder Kurzsichtigkeit, ist der einzige Grund, warum die Folgen nicht weitaus schlimmer waren.

Wie Josh es ausdrückte, hätte dies leicht katastrophale Folgen haben können. Diese Pakete laufen überall: auf Laptops, Unternehmensservern, CI/CD-Pipelines und in Cloud-Umgebungen. Sie hätten AWS-Schlüssel exfiltrieren, secrets preisgeben oder Dateien verschlüsseln können, um Lösegeld zu erpressen. Stattdessen beschränkten sich die Angreifer auf ein einziges, eng gefasstes Ziel.

Es hätte alles Mögliche anrichten können und wurde auf Unternehmensrechnern, Privatcomputern, in kleinen Unternehmen und CI/CD-Pipelines ausgeführt. Und die Tatsache, dass es nichts [Schlimmeres] angerichtet hat, war ein Glück im Unglück.

Die Lehre daraus ist nicht, dass das System funktioniert hat. Es ist vielmehr so, dass wir dieses Mal Glück hatten. Es als „Nichts Besonderes“ abzutun, verfehlt den Punkt. Der nächste Angreifer könnte weniger zurückhaltend sein.

Einblick: Die menschlichen Kosten von Open Source

Hinter jedem weit verbreiteten Paket steht ein Mensch, der oft still und ohne großes Aufsehen arbeitet. Für Josh war nicht nur der technische Kompromiss die größte Herausforderung. Es war auch die emotionale Belastung, die darauf folgte. Er beschrieb den ersten Tag als reinen Autopiloten, an dem er sich bemühte, den Schaden zu begrenzen. Erst danach wurde ihm die Last bewusst: Verlegenheit, Angst und der beunruhigende Gedanke, dass sein Fehler Menschen hätte verletzen können.

Das war am Montag. Als ich am Nachmittag oder Abend mein Konto zurückbekam, dachte ich mir: Okay, jetzt kann ich abschalten und mich einfach ins Bett legen, an die Decke starren und darüber nachdenken, was gerade passiert ist... Am nächsten Tag war ich einfach nur beschämt. Ich wollte mich nicht blicken lassen. Ich wollte nicht nach draußen gehen.

Das ist die verborgene Realität von Open Source. Kleine Projekte, die „aus Spaß“ entstanden sind, werden zu kritischer Infrastruktur, die Milliarden von Downloads bewältigen muss. Die Betreuer haben nie um diese Verantwortung gebeten, doch sie tragen die Last, wenn etwas schiefgeht. Die Community sieht den Code, übersieht jedoch oft die menschlichen Kosten, die mit seiner Pflege verbunden sind.

Joshs Erfahrung erinnert uns daran, dass es bei der Sicherheit von Ökosystemen nicht nur um eine stärkere MFA oder eine schnellere Reaktion auf Vorfälle geht. Es geht auch darum, die Verantwortlichen 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.

Aufruf zum Handeln

Dieser Vorfall hat deutlich gemacht, wie sich ein einziger Kompromiss auf die gesamte Software-Lieferkette auswirken kann. Diesmal war es nicht katastrophal, aber es hätte leicht so kommen können. Die Lehre daraus ist, nicht in Panik zu geraten, sondern zu handeln.

• Für Register (npm, PyPI usw.): Setzen Sie eine phishing-resistente MFA für wichtige Maintainer durch und stellen Sie klare Kanäle für schnelle Reaktionen bereit, wenn Konten kompromittiert werden.
• Für Organisationen: Verbessern Sie die Abhängigkeitshygiene. Fixieren Sie Versionen, überwachen Sie Manipulationen und integrieren Sie Sicherheitsprüfungen der Lieferkette in CI/CD-Pipelines.
  Für Betreuer: Verwenden Sie Hardware-Schlüssel, vermeiden Sie schnelle Sicherheitsentscheidungen unter Stress und setzen Sie auf Transparenz, wenn etwas schief geht.
• Für die Community: Unterstützen Sie die Menschen hinter Open Source. Respektieren Sie ihre Grenzen, stellen Sie nach Möglichkeit Ressourcen zur Verfügung und reagieren Sie mit Empathie, wenn Fehler passieren.

Der eigentliche Aufruf zum Handeln ist einfach: Behandeln Sie die Sicherheit des Ökosystems als gemeinsame Verantwortung. Plattformen, Unternehmen und Communities müssen alle ihren Teil dazu beitragen, dass der nächste Vorfall nicht zu etwas Schlimmerem eskaliert.

Nachwort

Es war eine surreale Woche, in der wir uns im Auge eines Sturms befanden, der aus gutem Grund so viel Aufmerksamkeit und Berichterstattung in den Medien auf sich zog. Die Ereignisse in Echtzeit zu verfolgen, von den ersten Warnmeldungen in unserem Dashboard bis hin zur Flut öffentlicher Berichte, fühlte sich an, als stünden wir auf einer Verwerfungslinie, während sich der Boden unter uns verschob. Dies erinnert uns daran, wie fragil unser Ökosystem ist.

Was sich dann abspielte, kam dem schlimmsten Szenario, über das ich mir tagtäglich im Bereich Open-Source-Sicherheit Gedanken mache, unangenehm nahe. Aber was ich am meisten fürchte, sind nicht die Phishing-E-Mails, die Malware oder gar die Schlagzeilen. Es ist vielmehr, dass wir diesen Moment ungenutzt verstreichen lassen.

Wenn die Branche dies als einen weiteren Vorfall abtut und wieder zum Tagesgeschäft übergeht, haben wir nichts gelernt. Und beim nächsten Mal – denn es wird ein nächstes Mal geben – haben wir vielleicht nicht mehr so viel Glück. Beim ersten Mal sind die Angreifer zu beschämen. Beim zweiten Mal sind wir zu beschämen.

Und wenn wir keine Maßnahmen ergreifen, um daraus zu lernen, könnte sich die stille Erosion des Vertrauens in Open Source als die schädlichste Folge von allen erweisen.

​