Nur ein Bruchteil aller Schwachstellen ist real ausnutzbar. Transparenz schlägt Grundrauschen – gerade bei komplexen KI-Modellen.
CISOs verbringen ihre Tage damit, ihre Mitarbeitenden, ihr Unternehmen und dessen Werte vor Bedrohungen zu schützen. Dabei sehen sie sich mit einer ständigen Flut von Alarmsignalen und Warnungen konfrontiert. Doch genau hier liegt das große Missverständnis: Es sind nicht die Alarmsignalen und Warnungen, die uns nachts wach halten, sondern das unkontrollierte Risiko. Also all das, was wir nicht sehen, nicht messen können oder von dem wir gar nicht wussten, dass es existiert.
Unwissenheit ist für CISOs kein Verbündeter. Der eigentliche Feind ist die fehlende Transparenz. Wenn man versteht, was eine Bedrohung ist, wie sie sich verhält und wo sie sitzt, kann man gezielt gegensteuern. Manchmal kennen wir die Bedrohung, können aber nicht abschätzen, wie groß das Problem tatsächlich ist. Manchmal trifft sie uns völlig unvorbereitet. Hinzu kommt: Das Tempo ist heute so hoch, dass wir Risiken immer schneller erfassen müssen, um mit den Innovationen Schritt zu halten, die wir eigentlich ermöglichen sollen.
Denn genau darin besteht heute unsere Aufgabe. Das Office-CISO soll Unternehmen helfen zu innovieren, also schnell voranzukommen und dabei sicher zu bleiben. Sie sind nicht mehr die Neinsager. Dieses Verständnis von Security hat ausgedient. Die Mission von CISOs ist es, das Business zu unterstützen, und nicht, noch eine blinkende Box ins Rack im Rechenzentrum zu schrauben. Die Aufgabe ist es, Wachstum zu ermöglichen, nicht es auszubremsen.
Warum das alte Playbook versagt
Derzeit hört man immer wieder dieselbe Botschaft: Mythos und vergleichbare KI-Modelle seien im Grunde nur eine weitere Bedrohung. Nichts wirklich Neues, also keine Panik. Ruhe zu bewahren und vorbereitet zu sein ist essentiell. Doch aus Ruhe wird leider schnell und unbemerkt Stillstand, und genau darin liegt die Gefahr. Die Bedrohung mag vertraut wirken, doch das Spielfeld hat sich grundlegend verändert.
Jahrelang hatte das CISO-Office Application Security nur aus der Distanz im Blick, ohne sich mit den Details zu befassen. Erst in den letzten Jahren haben wir uns eingestanden, dass die Bedrohungslandschaft nicht einfach nur gewachsen ist – sie hat sich auf eine völlig neue Welt ausgedehnt: die Softwareentwicklung. CI/CD-Pipelines, Entwickler-Workstations, KI-Coding-Agenten und IDE-Plugins. All das müssen wir heute absichern.
Typischerweise führen Teams eine Software Composition Analysis durch, prüfen, was in einem Paket steckt, und haken es ab. Den Daten, die diese Pakete erzeugen, und den Bedrohungen, die sich darin verbergen, schenken sie kaum Beachtung. Dabei nehmen Angreifer heute gezielt und massenhaft Repository-Betreiber ins Visier und schleusen Schadcode in weit mehr als nur Open-Source-Pakete ein. Sie zielen auf LLMs, MCP-Server, Agent Skills – und die Liste wird immer länger. Die Angriffsfläche endet nicht mehr am Perimeter. Sie umfasst den gesamten Lebenszyklus von der Entwicklung über Paketierung und Verteilung bis zum Betrieb.
Der Beginn einer neuen Ära
Diese Ära ist tatsächlich anders, und dem Argument „nichts Neues” sollte man behutsam widersprechen. Die klassische Frage im Schwachstellenmanagement lautete: Wird die verwundbare Funktion überhaupt aufgerufen? Denn eine verwundbare Funktion macht noch kein gefährliches Paket. Wer sie nicht aufruft, ist auch nicht angreifbar.
Der Bericht Software Supply Chain Security State of the Union 2026 von JFrog zeigt, dass sich nur 12 Prozent der prominentesten CVEs des Jahres 2025 in realen Unternehmensumgebungen tatsächlich gut ausnutzen ließen. 66 Prozent erreichten auf JFrogs Applicability-Skala lediglich Werte zwischen 0 und 20 Prozent.
Heutige Frontier-Modelle machen die Lage deutlich komplexer. Es geht nicht mehr nur um einen Funktionsaufruf, sondern auch um Datenmanipulation, Datenflüsse und tief verborgene, inhärente Schwachstellen. Im Idealfall benennen künftige Alerts daher nicht nur das betroffene Paket, sondern auch die eingesetzte Manipulationstechnik. Nur so können Threat-Intelligence-Teams fundiert einschätzen, ob eine Bedrohung real ist. Genau diese Unterscheidung ist entscheidend, wenn es darum geht, echte Bedrohungen vom Grundrauschen der Alerts zu trennen. Und genau daran scheitern die meisten.
Insellösungen: Ein altes Problem in neuem KI-Gewand
Der Report unterstreicht, wie wichtig es ist, Tools zu konsolidieren und eine einheitliche Software-Pipeline zu schaffen, die alle im Unternehmen nutzen. Security-, DevSecOps- und Product-Security-Teams sollten auf dieselbe Plattform und dieselben Daten zugreifen. Mit widersprüchlichen Informationen umzugehen ist schon schwierig genug. Ergibt es angesichts zahlreicher Threat Feeds wirklich Sinn, dass mehrere Lösungen dieselben Daten erzeugen? Das ist keine Redundanz, sondern ein Risiko.
Laut Report sank der Anteil der Unternehmen, die sieben oder mehr AppSec-Lösungen einsetzen, im Jahresvergleich von 73 auf 35 Prozent. Der Markt erkennt das Problem also. Für die Mehrheit, die weiterhin mit fragmentierten Toolsets arbeitet, bleibt es jedoch mühsam, die Ergebnisse der einzelnen Tools miteinander abzugleichen. Wer auf Tools setzt, die als verlässliche Single Source of Truth dienen, senkt den Aufwand und vereinfacht die Konsolidierung. Dass das in vielen Unternehmen nicht gelingt, liegt an strukturellen Hürden. Security wird weiterhin erst nachträglich mitgedacht, während die Entwicklung eigene, unabhängige Pipelines aufbaut. So entstehen verstreute Datensilos, die im Nachhinein zusammengeführt werden müssen. In Gesprächen mit CISOs und Führungskräften ist das ein Dauerthema.
Der reflexhafte Umgang mit KI verschärft das Problem noch. Ich beobachte, wie Unternehmen MCP-Registries als Insellösungen kaufen oder selbst entwickeln und glauben, das Problem damit gelöst zu haben. Dabei übersehen sie, dass sie nur einen winzigen Ausschnitt abdecken. Sie führen eine Lösung für MCP ein, suchen sich dann einen weiteren Anbieter für den nächsten Baustein und noch einen für den übernächsten, ohne je innezuhalten und zu fragen, worin die eigentliche Mission besteht. Dabei bestand sie nie darin, einzelne Bausteine abzusichern, sondern die gesamte KI-Anwendung.
