Was passiert
Dr. Jaushin Lee, CEO von Zentera Systems, hat sich in einem Interview mit Help Net Security zur aktuellen Bedrohungslage in der KI-Supply-Chain geäußert. Seine Analyse basiert auf der Beobachtung von Sicherheitsvorfällen und zeigt ein klares Bild: Die meisten realen Angriffe treffen derzeit Developer Workflows und Open-Source-Package-Repositories. Diese beiden Bereiche sind bereits aktive Zielscheiben von Angreifern, während andere potenzielle Angriffsflächenoptionen noch nicht im gleichen Umfang ausgenutzt werden.
Lee differenziert dabei zwischen Bedrohungen, die bereits in produktiven Umgebungen oder häufig anzutreffenden Entwicklungsprozessen entstehen, und solchen, die bislang überwiegend in Forschungsdemos auftreten. Zu letzterer Kategorie zählt er vergiftete Model Weights (manipulierte Modellgewichte) und kompromittierte MCP-Server (Model Context Protocol). Diese Angriffsvektoren sind zwar theoretisch relevant und werden in der Sicherheitsforschung intensiv untersucht, manifestieren sich aber noch nicht als Massenphänomen in realen Angriffsszenarien.
Die Einordnung ist für Unternehmen und Entwickler-Teams wichtig: Sie zeigt, wo echte Investitionen in Sicherheitsmaßnahmen derzeit den höchsten ROI liefern. Developer Workflows umfassen dabei den gesamten Entwicklungsprozess von der lokalen Umgebung über Versionskontrolle bis zur CI/CD-Pipeline. Open-Source-Repositories sind die Fundamente moderner Software – der Zugriff auf manipulierte oder backdoor-infizierte Pakete kann sich exponentiell in abhängigen Projekten ausbreiten. Lee weist zudem darauf hin, dass bestimmte Sicherungsmaßnahmen, etwa die Segmentierung von Systemen, eine bessere Risikoreduktion pro investiertem Dollar bringen als reine Tooling-Lösungen.
Einordnung
Die Supply-Chain-Sicherheit für KI-Systeme hat sich zu einem kritischen Thema entwickelt, weil KI-Modelle und die Tools zu ihrer Entwicklung nicht einfach in Isolation betrieben werden. Sie sind tief in Entwicklerprozesse, Paketmanagement-Systeme und Deployment-Infrastrukturen verflochten. Der Unterschied zu traditioneller Software-Supply-Chain-Sicherheit liegt in der Geschwindigkeit und Komplexität: KI-Modelle bringen zusätzliche Angriffsflächen mit sich – nicht nur Code, sondern auch trainierte Gewichte, Trainingsdaten und die Parameter der Modellarchitektur.
Bislang lag der Fokus vieler Diskussionen auf theoretischen Worst-Case-Szenarien wie Model-Poisoning oder vollständig kompromittierten Modell-Dateien. Lee bringt hier Klarheit ins Bild: Diese Szenarien sind im Forschungsumfeld demonstrierbar, treten aber in der Realität nicht flächendeckend auf. Das liegt auch daran, dass solche Angriffe technisch aufwendig sind und auf Modelle beschränkt bleiben, die bereits verteilt wurden – die Angreifer müssen also eine hohe Hürde überwinden und riskieren dabei Entdeckung.
Dagegen sind Developer Workflows heute massiv fragmentiert und oft nicht ausreichend isoliert. Ein Entwickler nutzt mehrere Tools, lädt Abhängigkeiten herunter, und diese Abhängigkeiten können ihrerseits wieder Abhängigkeiten haben. Open-Source-Package-Repositories wie npm, PyPI oder Maven Central sind zentralisierte, aber nicht hinreichend segregierte Systeme. Ein kompromittiertes Paket kann sich durch die gesamte Abhängigkeitskette verbreiten, bevor die Gefahr bemerkt wird.
Lee hebt hervor, dass Segmentierung – also die Isolierung von Systemen, Prozessen und Datenflüssen – ein bewährtes Konzept aus der Halbleiterindustrie ist. Diese Industrie hat gelernt, dass physische und logische Grenzen Risiken reduzieren, nicht nur abschrecken. Der Ansatz lässt sich auf Software übertragen: Wenn Entwicklungsumgebungen, Build-Systeme und Produktionsumgebungen nicht direkt verbunden sind, sinkt die Wahrscheinlichkeit, dass eine lokale Kompromittierung sich sofort global ausbreitet.
Was das bedeutet
Die praktische Konsequenz aus Lees Analyse ist eine Umkehrung der Sicherheitspriorisierung: Statt teure und oft komplexe KI-Security-Tools zu kaufen, die sich auf hypothetische Model-Poisoning-Szenarien konzentrieren, sollten Teams zunächst ihre Segmentierung überprüfen. Das ist billiger und wirksamer. Ein isolierter Build-Agent, der keine direkten Netzwerk-Verbindungen zu Produktionssystemen hat und dessen Netzwerk-Zugriff auf vertrauenswürdige Package-Repositories beschränkt ist, verhindert bereits einen großen Teil realer Angriffswege.
Das bedeutet auch: Self-Hosting eines KI-Modells ist kein Sicherheits-Allheilmittel. Wenn das Modell aus einem kompromittierten Repository heruntergeladen oder während des Trainings durch eine unsichere Abhängigkeit vergiftet wurde, hilft das Self-Hosting nicht. Der Fokus sollte auf der Kette liegen – wie wird das Modell beschafft, wie wird es validiert, welche Zugriffsrechte hat das System, das es lädt. Lee argumentiert hier für einen Defense-in-Depth-Ansatz, der mit Segmentierung beginnt, nicht endet.
Das Interview zeigt, dass KI-Security nicht aus dem Nichts anfangen kann. Die bewährten Prinzipien der Halbleiter-Industrie – Segmentierung, Isolation, Zero-Trust auf Netzwerk-Ebene – sind auf Software übertragbar und liefern heute messbare Risikoreduktion. Wer KI-Systeme sichern möchte, sollte also zuerst fragen: Sind meine Developer Workflows ausreichend isoliert? Nicht: Welches KI-Security-Tool kaufe ich?
