Die Sicherheit der Software-Lieferkette bedeutete für mich während des größten Teils meiner beruflichen Laufbahn, genau zu prüfen, was Entwickler einbinden: Abhängigkeiten, Basis-Images und Pakete von Drittanbietern.
Diese Betrachtungsweise ist inzwischen gefährlich unvollständig.
Im vergangenen Jahr gingen Angreifer stromaufwärts, über die Pakete hinaus und hinein in die Tools, die Entwickler überhaupt zum Schreiben von Code verwenden.
IDE-Erweiterungen, KI-Coding-Assistenten und Model-Context-Protocol-(MCP-)Server gehören heute zur Standardinfrastruktur für Entwickler.
Sie haben Zugriff auf Codebasen, Zugangsdaten und CI/CD-Pipelines. Und die meisten Sicherheits-Frameworks wurden nie dafür entwickelt, sie zu erkennen.
Das ist ein struktureller Wandel, keine hypothetische Möglichkeit. Laut dem JFrog-Bericht „2026 Software Supply Chain Security State of the Union“setzen inzwischen 41 % der Unternehmen aktiv KI- und ML-Bibliotheken ein, gegenüber 34 % im Vorjahr, und das durchschnittliche Unternehmen verwaltet 47 % mehr dieser Pakete als im vergangenen Jahr.
Die Lieferkette hat nicht einfach eine KI-Kategorie hinzugefügt. Zunehmend ist KI die Lieferkette.
Wichtigste Erkenntnisse
- Entwicklertools sind inzwischen Teil der Software-Lieferkette; IDE-Erweiterungen, MCP-Server, KI-Modelle und Agentenfähigkeiten eröffnen neue Angriffswege.
- Die Governance hinkt der Einführung hinterher: Nur 43 % der Unternehmen verfügen über eine per Richtlinie durchgesetzte Liste zugelassener Entwicklertools.
- KI-Ökosysteme werden bereits für Angriffe missbraucht; in weit verbreiteten Registries finden sich bösartige Erweiterungen, Agentenfähigkeiten und Modelle.
- Die Ausnutzbarkeit ist wichtiger als die Zahl der Schwachstellen: Nur 12 % der 337 untersuchten, öffentlich stark beachteten CVEs erwiesen sich in realen Umgebungen als hochgradig ausnutzbar.
- Transparenz muss in Handeln münden. Dafür müssen Sicherheitsteams Herkunft, Anwendbarkeit, Richtlinien und Auditnachweise über den gesamten Entwicklungslebenszyklus hinweg miteinander verknüpfen.
Die Angriffsfläche folgte den Entwicklern
Betrachten wir, was allein auf der Tooling-Ebene geschah. Die von KI-nativen IDEs verwendete OpenVSX-Registry wuchs von rund 1.000 Erweiterungen im Jahr 2023 auf 3.803 im Jahr 2025 – ein Anstieg um 262 %.
Im selben Jahr wurden dort 56 bösartige Erweiterungen entdeckt, darunter GlassWorm, der erste sich selbst verbreitende Wurm, der es auf VS-Code-Erweiterungen abgesehen hatte.
GlassWorm verbarg bösartigen Code in unsichtbaren Unicode-Zeichen, stahl Zugangsdaten von Entwicklern, um sich selbstständig zu verbreiten, und erreichte rund 35.800 Installationen.
Auch die Agentenebene schnitt nicht besser ab. JFrog Security Research identifizierte 2025 mehr als 20 kritische Schwachstellen zur Ausführung von Code aus der Ferne in MCP-Servern, darunter CVE-2025-6514, eine Schwachstelle mit einem CVSS-Wert von 9,6 im weit verbreiteten Dienstprogramm mcp-remote.
Als das Team Anfang 2026 die Suche auf Registries für Fähigkeiten von KI-Agenten ausweitete, fand es 969 bösartige Agentenfähigkeiten mit Schadcode von kritischer Tragweite.
Auf der Modellseite wurden in öffentlichen Registries wie Hugging Face 495 bösartige Modelle entdeckt – aus denselben Registries beziehen 53 % der Unternehmen Modelle für das Hosting in eigener Umgebung.
Jeder Ort, an dem Entwickler inzwischen arbeiten – der Marktplatz für Erweiterungen, die Registry für Agentenfähigkeiten, der Modell-Hub –, ist zu einem Verbreitungsweg geworden.
Der Perimeter ist längst keine Netzwerkgrenze mehr. Er umfasst den gesamten Vorgang des Erstellens, Paketierens und Betreibens von Software.
Das Governance-Paradoxon
Hier werden die Daten unangenehm. Auf die Frage, wie sie die MCP-Nutzung steuern, geben 97 % der Unternehmen an, irgendeine Form einer zertifizierten Liste zu betreiben.
Auf dem Papier wirkt das ausgereift. Doch Governance ohne kontinuierliches Scannen ist eine Liste, keine Kontrolle.
Das Gesamtbild beim Tooling bestätigt diese Lücke.
Nur 43 % der Unternehmen verfügen über eine zertifizierte, per Richtlinie durchgesetzte Liste vorab genehmigter Entwicklertools, und 39 % setzen automatisierte Kontrollen ein, um nicht genehmigte Tools zu blockieren.
Unterdessen haben 18 % überhaupt keine Governance oder nur eine Governance dem Namen nach – und weitere 10 % überlassen die Selbstregulierung vollständig den Entwicklern, die unter Termindruck stehen. Dadurch steigt der effektiv ungesteuerte Anteil auf fast ein Viertel der Unternehmen.
Angesichts einer Bedrohungslandschaft, die in einem einzigen Jahr GlassWorm und eine MCP-Schwachstelle mit einem Schweregrad von 9,6 hervorgebracht hat, ist das heute die deutlichste Lücke in der Unternehmenssicherheit.
Präzision ist das Gegenmittel gegen das Rauschen
Nichts davon erfordert mehr Warnmeldungen. Die Untersuchung spricht für das Gegenteil.
Wir entwickelten Scanner zur Prüfung der Anwendbarkeit für 337 öffentlich stark beachtete CVEs, die 2025 veröffentlicht wurden – und testeten nicht nur, ob anfälliger Code vorhanden ist, sondern auch, ob die Bedingungen für eine Ausnutzung in realen Unternehmensumgebungen tatsächlich gegeben sind.
Nur 40 dieser CVEs, etwa 12 %, erwiesen sich in der Praxis als hochgradig ausnutzbar.
Eine volumenbasierte Triage lässt Sicherheitsteams im Stich: Mehr CVEs, die verfolgt werden müssen, bedeuten nicht automatisch ein höheres tatsächliches Risiko.
Sie bedeuten mehr Rauschen, und in diesem Rauschen verbergen sich die echten Bedrohungen.
Für CISOs ist das das Argument, das sie dem Vorstand vorlegen sollten.
Die Frage ist nicht, wie viele Befunde Ihre Tools erzeugen, sondern ob Sie nachweisen können, welche davon in Ihrer Umgebung relevant sind, und gegen sie vorgehen können, bevor es ein Angreifer tut.
Transparenz ohne Verantwortlichkeit ist keine Governance
Eine weitere Zahl sollte jeden Sicherheitsverantwortlichen innehalten lassen: 59 % der Unternehmen geben an, vollständige Transparenz über die Herkunft von Produktionsartefakten zu haben, doch 48 % benötigen weiterhin eine Woche oder länger, um Nachweise für Compliance-Audits zu erstellen.
Diese Zahlen können nicht beide für ein gesundes Programm stehen.
Wäre die Transparenz tatsächlich gegeben – strukturiert, zugänglich und auditbereit –, würde der Nachweis Minuten statt Wochen dauern.
Für viele Unternehmen bedeutet „vollständige Transparenz“, dass die Daten irgendwo vorhanden sind, nicht, dass jemand darauf reagieren kann.
Deshalb stehe ich der reflexhaften Reaktion der Branche skeptisch gegenüber, für jede neue KI-Angriffsfläche eine weitere Punktlösung anzubauen.
Hier eine MCP-Registry, dort ein Scanner für Erweiterungen und anschließend noch ein Anbieter zur Modellprüfung.
Bemerkenswert ist, dass inzwischen 38 % der Unternehmen angeben, sich in erster Linie auf die Sicherheitsfunktionen ihrer bestehenden DevOps-Plattform zu verlassen – eine Erkenntnis, dass fragmentierte Datensilos selbst ein Risiko darstellen.
Ihre Aufgabe war nie, jeweils nur eine kleine Artefaktklasse abzusichern.
Sie besteht darin, die gesamte KI-Anwendung abzusichern – von der ersten Zeile KI-gestützten Codes bis zum Agenten, der in der Produktion läuft.
Die Aufgabe des modernen CISO besteht darin, dem Unternehmen zu helfen, sich schnell zu bewegen und zugleich sicher zu bleiben – die vom agentischen Zeitalter geforderte Geschwindigkeit zu ermöglichen, statt sie zu bremsen.
Dafür braucht es ein einheitliches Verzeichnis über alles, womit Entwickler arbeiten, und alles, was KI berührt: einen Ort, an dem Herkunft, Anwendbarkeit und Richtlinien gemeinsam verwaltet werden.
Die Unternehmen, die dieses Ziel zuerst erreichen, werden nicht nur sicherer sein. Sie werden auch schneller sein, weil sie ihre Zeit auf das tatsächliche Risiko konzentrieren können und nicht auf das Rauschen, das keines ist.