Supply Chain, oder warum die Lücke selten im eigenen Code steckt
Es gibt einen Moment, den jeder kennt, der Systeme betreibt. Der Arbeitstag ist eigentlich vorbei, man liest noch beiläufig mit, und dann steht da eine Meldung: schwere Sicherheitslücke in einem Baustein, den halb Deutschland einsetzt. Ein Paket, ein Plugin, ein Dienst. Und sofort ist der Feierabend weg, weil eine Frage im Raum steht, die man nicht liegen lassen kann:
Betrifft uns das?
Wer diese Frage nicht schnell und verlässlich beantworten kann, hat zwei schlechte Möglichkeiten. Er kann sich beruhigen und hoffen, dass es schon nicht so schlimm ist. Oder er kann anfangen zu suchen, abends, in mehreren Systemen, ohne Vollständigkeitsgarantie. Beides ist keine Antwort. Dieser Beitrag handelt davon, wie wir aus dieser Frage eine Routine gemacht haben.
Was mit Supply Chain gemeint ist
Der Begriff kommt aus der Logistik und beschreibt die Kette vom Rohstoff bis zum fertigen Produkt im Regal. In der Software bedeutet er dasselbe, nur unsichtbar.
Denn Software wird längst nicht mehr aus dem Nichts gebaut. Sie setzt sich zusammen aus fertigen Bausteinen anderer Leute, und diese Bausteine setzen wiederum auf weiteren Bausteinen auf. Eine Website, eine Warenwirtschaft, ein Shop bestehen aus hunderten solcher Teile. Wer eine Software in Auftrag gibt, wählt vielleicht ein Dutzend Werkzeuge bewusst aus. Der Rest kommt einfach mit, als Zutat einer Zutat.
Das ist keine Nachlässigkeit, sondern der Grund, warum moderne Software überhaupt bezahlbar ist. Niemand programmiert einen Kalender, eine Verschlüsselung oder einen Bildskalierer noch selbst. Der Preis dafür ist eine Abhängigkeit, die niemand vollständig überblickt: Deine Software ist so verwundbar wie das schwächste Glied einer Kette, deren Länge du nicht kennst.
Die Zahlen haben sich gedreht
Über KI und Sicherheit wird viel geraunt. Die belastbaren Zahlen sind eindeutiger als das Raunen.
Verizon veröffentlicht seit Jahren den wohl bekanntesten Untersuchungsbericht zu tatsächlichen Datenlecks. Die Ausgabe 2026, die den Zeitraum von November 2024 bis Oktober 2025 auswertet, meldet eine Verschiebung, die es so noch nie gab: 31 Prozent aller Einbrüche beginnen inzwischen mit einer Software-Schwachstelle. Damit hat das Ausnutzen von Lücken die gestohlenen Passwörter als häufigsten Einstiegsweg abgelöst, zum ersten Mal in der Geschichte dieses Berichts.
Das ist eine leise, aber tiefgreifende Verschiebung. Die alte Erzählung war: Jemand klickt auf den falschen Anhang, jemand verrät sein Passwort. Die neue Erzählung ist: Niemand muss mehr etwas falsch machen. Es reicht, dass irgendwo ein Baustein läuft, für den seit vorgestern ein Angriffsweg bekannt ist.
Der Grund dafür ist auch, aber nicht nur, künstliche Intelligenz. Eine Sicherheitslücke zu finden war früher mühsame Handarbeit, und genau diese Trägheit war ein stiller Schutz. Heute lässt sich Software automatisiert nach Schwachstellen absuchen, schneller und gründlicher als ein Mensch das könnte. Das nützt beiden Seiten. Verteidiger finden ihre Lücken früher. Angreifer eben auch, mit denselben Werkzeugen. Was bleibt, ist ein Rennen, das nicht mehr in Wochen entschieden wird, sondern in Tagen.
Ein Beispiel, das exemplarisch ist
Wie brüchig eine Lieferkette wirklich ist, hat der August 2026 vorgeführt.
Am 4. August übernahmen Angreifer das Konto eines einzelnen Entwicklers, der eine weit verbreitete Hilfsbibliothek zum Zwischenspeichern von Daten betreut. Diese Bibliothek heißt keyv und wird über 600 Millionen Mal pro Monat heruntergeladen. Ein weiteres betroffenes Paket, flat-cache, kommt auf rund 580 Millionen. Das sind keine Nischenwerkzeuge, sondern Bauteile, die in Entwicklungswerkzeugen stecken, die fast jedes JavaScript-Projekt einsetzt. Kaum jemand hat sie bewusst installiert. Sie kamen mit.
Was dann passierte, ist der eigentlich bemerkenswerte Teil. Der eingeschleuste Schadcode suchte auf befallenen Rechnern nach weiteren Zugangsdaten und veröffentlichte automatisch manipulierte Versionen aller Pakete, für die die erbeuteten Rechte reichten. Er verbreitete sich also selbst weiter, von Betreuer zu Betreuer, wie ein Wurm. Die Sicherheitsbehörde Singapurs beziffert das Ergebnis auf über 1.300 betroffene Paketversionen mit zusammen rund zwei Milliarden Abrufen im Monat; Elastic zählt über 400 einzelne Pakete.
Zwei Details sind für die Praxis entscheidend. Erstens nutzten die Angreifer Zugänge, bei denen das Veröffentlichen ohne zweiten Faktor möglich war. Zweitens lief der Schadcode nicht etwa, wenn jemand die Software benutzte, sondern bereits beim Installieren, über einen Mechanismus, den das Paketformat für Vorbereitungsschritte vorsieht. Es genügte, das Paket zu holen.
Gegen so etwas hilft keine Sorgfalt beim eigenen Programmieren. Man kann alles richtig machen und trotzdem betroffen sein, weil ein Baustein drei Ebenen tiefer über Nacht den Besitzer gewechselt hat.
Warum „wir schauen mal nach" nicht mehr reicht
Man könnte einwenden: Für all das gibt es doch Updates. Stimmt. Nur ist die Menge das Problem.
Wer jede Meldung von Hand prüfen muss, kommt irgendwann nicht mehr hinterher. Und dann entscheidet nicht mehr die Wichtigkeit darüber, was zuerst bearbeitet wird, sondern der Zufall: was man gerade gelesen hat, woran man sich erinnert, wer zuerst gefragt hat. Das ist keine Nachlässigkeit, das ist Arithmetik.
Genau an dieser Stelle nützt Automatisierung der Verteidigung mehr als dem Angriff. Denn die Frage „betrifft uns das" ist keine Denkaufgabe. Sie ist ein Abgleich zwischen zwei Listen: was gemeldet wurde, und was bei uns läuft.
Was wir daraus gebaut haben
Wir betreuen eine Reihe von Systemen für Kunden und betreiben eine ganze Menge eigene. Unser Sicherheitsnetz besteht aus drei Schichten, die aufeinander aufbauen.
Erstens: Wir wissen, was wir betreiben. Für jedes betreute System führen wir ein Verzeichnis dessen, was darauf tatsächlich installiert ist, mitsamt Versionsstand. Nicht aus dem Gedächtnis und nicht aus der Projektdokumentation von damals, sondern regelmäßig vom System selbst erhoben. Das klingt banal und ist die Voraussetzung für alles Weitere. Wer nicht weiß, was er betreibt, kann keine einzige Sicherheitsmeldung beantworten.
Zweitens: Wir gleichen Meldungen automatisch gegen diesen Bestand ab. Die Sicherheitshinweise der Hersteller und der großen Sicherheitsstellen laufen bei uns zusammen und werden gegen das Verzeichnis gehalten. Das Ergebnis ist keine Liste von Neuigkeiten, sondern eine Antwort: Diese Meldung betrifft dieses System in dieser Version, und das ist der Stand, der sie schließt.
Dass so ein Abgleich richtig rechnet, ist übrigens weniger selbstverständlich, als es klingt. Versionsnummern zu vergleichen ist ein Feld voller Fallstricke, weil verschiedene Systeme unterschiedliche Regeln dafür haben, welche Version älter ist als welche. Wir haben unseren Vergleich deshalb gegen die Originalregeln geprüft, mit Dutzenden von Grenzfällen. Ein Abgleich, der sich hier vertut, ist schlimmer als gar keiner, weil er beruhigt, wo er warnen müsste.
Drittens: ein fester Wartungstakt und ein Lagebild. Sicherheitsaktualisierungen kommen in einem engen, regelmäßigen Takt, nicht wenn gerade Zeit ist. Dazu kommt die Zusammenführung: eine Oberfläche, auf der wir für alle betreuten Systeme gleichzeitig sehen, was läuft, was hakt, was ansteht und was gerade gemeldet wurde. Ohne diese Zusammenführung liegt das Wissen an fünf verschiedenen Stellen, und das ist im Ernstfall so gut wie kein Wissen.
Was das ausdrücklich nicht leistet
Hier ist die Stelle, an der andere ein Versprechen abgeben. Wir tun das nicht, weil es unehrlich wäre.
Dieses Netz schützt nicht vor dem, was noch niemand gemeldet hat. Eine Lücke, die nur den Angreifern bekannt ist, taucht in keinem Abgleich auf. Es schützt auch nicht davor, dass jemand ein Passwort weitergibt oder auf eine überzeugend gemachte Aufforderung hereinfällt. Und es macht kein System unangreifbar. So etwas gibt es nicht.
Was es leistet, ist bescheidener und dafür belastbar: Es verkürzt die Zeit zwischen „das ist bekannt" und „bei uns ist es zu". Es sorgt dafür, dass diese Zeit nicht davon abhängt, ob abends jemand die richtige Meldung gelesen hat. Und es macht die Antwort auf die Frage „betrifft uns das" überprüfbar statt gefühlt.
Dazu gehört eine Lehre, die wir uns hart erarbeitet haben und die für jede Automatisierung gilt: Eine eingerichtete Automatik ist kein Beleg dafür, dass sie läuft. Ein Vorgang, der still nichts tut, sieht von außen genauso aus wie einer, der still funktioniert. Wir prüfen deshalb nicht nur, ob unsere Routinen eingerichtet sind, sondern ob sie tatsächlich etwas bewirkt haben. Ein Wartungslauf ohne sichtbares Ergebnis ist verdächtig, nicht beruhigend.
Warum wir das nicht für uns behalten
Der ehrlichste Grund, warum wir dieses Netz gebaut haben, ist ein egoistischer: Wir wollten die Frage loswerden, die abends im Kopf hängen bleibt. Nicht durch Verdrängen, sondern indem sie beantwortet ist, bevor sie sich stellt.
Der zweite Grund ist, dass die meisten Betriebe sich so etwas allein nicht leisten können und es trotzdem brauchen. Eine Bäckerei mit einem Kassensystem und einer Website hat dieselbe Bedrohungslage wie ein Konzern, nur ohne Sicherheitsabteilung. Genau dafür gibt es Betreuung: nicht damit jemand da ist, wenn etwas kaputt ist, sondern damit die stille Arbeit passiert, die verhindert, dass es kaputt geht.
Und den wesentlichen Teil davon zeigen wir unseren Kunden im eigenen Portal, statt ihn zu behaupten. Du sollst nicht darauf vertrauen müssen, dass wir nachsehen. Du sollst sehen können, dass nachgesehen wurde.
Quellen
- Verizon, 2026 Data Breach Investigations Report (Auswertungszeitraum November 2024 bis Oktober 2025): verizon.com/business/resources/reports/dbir
- Cyber Security Agency of Singapore, Advisory AD-2026-009 vom 6. August 2026, Ongoing npm Supply Chain Attack Affecting Keyv and Related Packages: csa.gov.sg
- Elastic Security Labs, 6. August 2026, Shai-Hulud strikes again: CHAINDROP worm hits 400+ npm packages: elastic.co/security-labs
Aus dem Labor ist unsere Rubrik über das, was wir selbst bauen und betreiben, bevor wir es jemandem empfehlen. Warum Sicherheit für uns ein Rhythmus ist und kein Zustand, steht in Sicherheit ist kein Zustand, sondern ein Takt. Fragen? Schreib uns.
