Ich sag’s, wie es ist: Früher war Cybersecurity in vielen Köpfen ein bisschen wie Tür abschließen. Passwort stark, Firewall an, Updates rein. Fertig.
Heute ist Cybersecurity leider eher so, als würdest du deine Haustür perfekt sichern – und dann öffnest du freiwillig dem Angreifer, weil er als Paketbote mit offiziellem Logo daherkommt.
Das macht Supply-Chain-Angriffe so tückisch.
Dabei greifen Kriminelle nicht direkt dein Unternehmen an, sondern den Weg dorthin: Software-Pakete, Updates, Dienstleister, Integrationen, Build-Prozesse oder Tools, denen du vertraust. Genau dieses Vertrauen wird zur Schwachstelle.
Wir haben neulich erst über den Axios-Fall gesprochen. Ein guter Anlass für uns, das Thema „Lieferketten-Sicherheit“ mal etwas breiter zu beleuchten.
Ein Supply-Chain-Angriff zielt nicht zuerst auf dich, sondern auf einen Baustein, den du nutzt. Also auf die digitale Lieferkette. Das kann ein Open-Source-Paket sein, ein Software-Update, ein externer Anbieter oder ein automatisierter Prozess in der Softwarebereitstellung.
Die perfide Idee dahinter: Angreifer kapern nicht die Haustür, sondern den Schlüsselzulieferer.
Moderne IT besteht heute aus vielen Abhängigkeiten. Kaum ein Unternehmen betreibt nur noch „eine Software von einem Hersteller“. Stattdessen reden wir über Cloud-Dienste, APIs, SaaS-Tools, Open-Source-Bibliotheken, CI/CD-Pipelines und externe Integrationen.
Das ist effizient und sinnvoll – aber eben auch ein Spielfeld für Angreifer.
Ein besonders aufsehenerregender Fall betraf LiteLLM. Das Projekt selbst meldete Ende März 2026 einen Supply-Chain-Vorfall rund um kompromittierte PyPI-Veröffentlichungen.
Betroffen waren die Versionen 1.82.7 und 1.82.8, die laut LiteLLM am 24. März 2026 für rund 40 Minuten auf PyPI verfügbar waren. Die Schadfunktion sollte unter anderem Umgebungsvariablen, SSH-Schlüssel, Cloud-Zugangsdaten, Kubernetes-Tokens und Datenbank-Passwörter sammeln und an eine nicht offizielle Domain exfiltrieren.
LiteLLM erklärte, dass das GitHub-Repository selbst nicht kompromittiert gewesen sei und später mit v1.83.0 eine bereinigte Version veröffentlicht wurde.
Das ist deshalb so brisant, weil hier nicht irgendein dubioses Tool betroffen war, sondern ein Baustein aus dem KI- und Entwickler-Ökosystem.
Wer also sagt: „Wir machen doch nur ein bisschen KI und Automatisierung“, sollte hellhörig werden. Gerade hochgradig vernetzte, moderne Toolchains sind attraktiv, weil ein erfolgreicher Angriff potenziell viele Folgeziele erreicht.
Das zweite Beispiel wirkt auf den ersten Blick kleiner, ist aber fast noch lehrreicher. Beim Fall GhostClaw wurde ein bösartiges npm-Paket als vermeintlich legitimes OpenClaw-Installer-Tool getarnt.
Laut JFrog tarnte sich das Paket als normale CLI-Komponente, nutzte jedoch Installations- und Social-Engineering-Tricks, um Zugangsdaten, Browserdaten, Wallet-Informationen, SSH-Keys, Keychain-Daten und weitere sensible Inhalte zu stehlen.
Besonders perfide: Das Tool zeigte einen glaubwürdigen Installer und fragte das Systempasswort in einer täuschend echten Keychain-Aufforderung ab.
Das Paket wurde am 3. März 2026 hochgeladen, blieb etwa eine Woche im npm-Register und infizierte 178 Entwickler, bevor es am 10. März entfernt wurde.
Weil Supply-Chain-Angriffe drei Dinge gleichzeitig ausnutzen:
Erstens: Vertrauen.
Wenn ein Paket aus einer bekannten Quelle kommt, ein Tool aussieht wie immer oder ein Update den gewohnten Namen trägt, wird es viel seltener hinterfragt.
Zweitens: Skalierung.
Ein erfolgreicher Angriff auf einen zentralen Baustein trifft nicht nur ein Unternehmen, sondern potenziell Hunderte oder Tausende.
Drittens: Komplexität.
In vielen Unternehmen weiß niemand mehr aus dem Stand, welche direkten und indirekten Abhängigkeiten wirklich produktiv im Einsatz sind.
Und ganz ehrlich: „Das hat irgendwann mal jemand eingebaut, läuft seitdem und wir fassen es lieber nicht an“ ist kein Sicherheitskonzept. Es ist digitales Jenga.
Was diese Vorfälle so relevant macht, ist die Erkenntnis: Viele Unternehmen schützen ihre Systeme, aber nicht konsequent ihre Abhängigkeiten.
Dabei ist das heute entscheidend. Die Frage lautet nicht mehr nur: „Sind unsere Server sicher?“ Sondern auch:
Hier schließt sich der Kreis zu Themen, die bei uns ohnehin immer wieder auftauchen.
Nur weil ein Paket bekannt ist oder ein Tool in vielen Projekten genutzt wird, ist es nicht automatisch sicher. Vertrauen braucht heute technische Absicherung.
Du solltest wissen, welche Bibliotheken, Pakete, Container, SaaS-Verbindungen und Automatisierungen in deiner Umgebung tatsächlich laufen. Nicht ungefähr, sondern möglichst konkret.
„Immer sofort alles automatisch installieren“ klingt modern, ist aber ohne Prüfmechanismen riskant. Geschwindigkeit ist wichtig, aber ohne Kontrollmechanismen ist in der IT ungefähr so sinnvoll wie ein Fallschirm aus Toastbrot.
Die aktuellen Fälle zeigen, dass technische Nutzer im Fokus stehen. Wer auf Entwicklungsmaschinen, Build-Server oder Admin-Accounts zugreift, kommt oft an besonders wertvolle Daten und Berechtigungen.
Du wirst nicht jede neue Angriffsmethode verhindern. Aber du kannst dein Unternehmen so aufstellen, dass Vorfälle schneller erkannt, eingegrenzt und bewältigt werden.
Für Unternehmen heißt das konkret:
Erfasse kritische Software-Abhängigkeiten, Drittanbieter-Komponenten und automatisierte Build- bzw. Deployment-Prozesse.
Unkontrollierte, transitive Updates sind bequem, aber gefährlich. Kritische Komponenten sollten bewusst freigegeben werden.
Maintainer-, Admin-, CI/CD- und Registry-Zugänge brauchen starke Absicherung, idealerweise mit MFA, Rollenprinzip und minimalen Rechten.
Ungewöhnliche Netzwerkverbindungen, plötzliche Secret-Abfragen, verdächtige Build-Aktivitäten oder Änderungen an Release-Prozessen müssen auffallen.
Wer reagiert? Was wird isoliert? Welche Systeme haben Priorität? Welche Abhängigkeiten müssen geprüft werden? Diese Fragen sollten nicht erst im Angriffsfall auf einem Whiteboard landen.
Supply Chain heißt eben auch: Sicherheit endet nicht am eigenen Firmenrand.
Supply-Chain-Angriffe sind deshalb so gefährlich, weil sie unsere Arbeitsweise ausnutzen. Moderne IT lebt von Vernetzung, Geschwindigkeit und Wiederverwendung. Das ist ihr großer Vorteil – und leider ein wirksamer Hebel für Angreifer.
Für mich ist die wichtigste Botschaft deshalb nicht: „Vertraue niemandem mehr.“ Das wäre weder realistisch noch sinnvoll.
Die bessere Botschaft lautet: Vertrauen braucht Struktur.
Oder, etwas weniger dramatisch formuliert: Hoffnung ist keine Sicherheitsarchitektur.
Wer heute Verantwortung für IT trägt, sollte nicht nur auf Perimeter, Endgeräte und Benutzerkonten schauen, sondern auf die gesamte digitale Lieferkette.
Der nächste Angriff kommt vielleicht nicht als Alarmmeldung von außen, sondern als ganz normales Update.
Deshalb gilt mehr denn je: Cloud. Einfach. Persönlich.
Einfach, weil Sicherheit verständlich und umsetzbar sein muss.
Persönlich, weil gute IT nicht nur aus Tools besteht, sondern aus Verantwortung, Klarheit und dem richtigen Umgang mit Risiken.