Heinzelmännchen: Generative Künstliche Intelligenz (KI) und agentenbasierte Entwicklungswerkzeuge verändern die Softwareentwicklung. Beim Vibe Coding unterstützen KI-Assistenten und -Agenten Entwickler dabei, Code zu schreiben, Abhängigkeiten einzurichten und Entwicklungsumgebungen zu konfigurieren. Damit rückt auch das Thema Vibe Coding und IT-Sicherheit stärker in den Fokus. Denn während KI-Werkzeuge neue Komponenten installieren können, bleibt deren spätere Aktualisierung oder Bereinigung häufig eine separate Aufgabe.
KI verändert den Softwarebestand auf Entwicklerrechnern
Wer eine Entwicklungsumgebung manuell einrichtet, der entwickelt ein Bewusstsein dafür, welche Komponenten er benötigt und welche nicht. Ein KI-Agent verfolgt ein anderes Ziel: Er soll eine konkrete Aufgabe möglichst schnell und zuverlässig erledigen. Benötigt ein Projekt eine bestimmte .NET-Version, kann der Agent das entsprechende SDK installieren. Für eine andere Aufgabe kommt möglicherweise eine weitere Version hinzu. Die alte Installation wird dadurch nicht überflüssig – und schon gar nicht automatisch entfernt.
So können sich auf einem Entwicklerrechner im Laufe der Zeit zahlreiche SDK-Versionen verschiedener .NET-Generationen und Feature-Bands ansammeln. Das ist zunächst kein Fehler: Die parallele Installation unterschiedlicher SDK-Versionen ist bei .NET grundsätzlich vorgesehen und für die Entwicklung verschiedener Projekte sogar notwendig. Bleiben allerdings nicht mehr benötigte Versionen dauerhaft auf dem System, entsteht ein Security-Problem. Besonders tückisch wird die Situation beim klassischen Patch-Management.
Gepatcht bedeutet nicht zwangsläufig sicher
Microsoft veröffentlicht regelmäßig Sicherheitspatches für .NET. Diese schließen Schwachstellen in den jeweiligen Runtime-Komponenten und können dabei eine Vielzahl bekannter Schwachstellen adressieren, deren Schweregrad von „hoch“ bis „kritisch“ reicht. Die Updates ersetzen jedoch nur die eigene Runtime-Komponente (WinRT), die über Windows Update oder WSUS (Windows Server Update Services) bereitgestellt wird. Sie können die Laufzeitversion, von der ein bereits installiertes SDK noch abhängt, nicht entfernen. Das Update erkennt diese Abhängigkeit und verzichtet auf die Bereinigung, um das SDK nicht unbrauchbar zu machen.
Es handelt sich dabei nicht nur um eine einzige Laufzeitumgebung. Jedes SDK enthält eigene Kopien der .NET-Laufzeitumgebung, der ASP.NET-Core-Laufzeitumgebung und der .NET-Desktop-Laufzeitumgebung, die alle nebeneinander im selben Ordner „dotnet\shared“ liegen – ein Satz pro SDK-Feature-Band –, wobei ältere Versionen erst entfernt werden, wenn keine Abhängigkeiten mehr bestehen. Von der Konzeption her sind .NET-SDK-Feature-Bands so ausgelegt, dass sie nebeneinander existieren können, und nichts entfernt automatisch SDKs aus anderen Bändern oder Hauptversionen.
Ein aktualisiertes System erscheint deshalb in herkömmlichen Patch- und Compliance-Dashboards zunächst als sicher. Das bedeutet allerdings nicht zwingend, dass auf dem Rechner keine verwundbaren .NET-Komponenten mehr vorhanden wären. Der Grund liegt in der Architektur des .NET-SDK. Ein SDK bringt eigene Runtime-Komponenten mit, darunter die .NET Runtime, die ASP.NET Core Runtime und die .NET Desktop Runtime. Diese Komponenten werden parallel zu anderen Versionen installiert und befinden sich unter anderem im Verzeichnis dotnet\shared.
Ein Sicherheitsupdate für eine eigenständige Runtime entfernt nicht automatisch alle älteren Runtime-Versionen, die ein installiertes SDK noch benötigt. Solange entsprechende Abhängigkeiten bestehen, bleiben diese Komponenten auf dem System. Damit können zwei scheinbar widersprüchliche Zustände gleichzeitig existieren: Das zentrale Patch-Management meldet einen aktuellen Stand, während auf demselben Rechner eine ältere, weiterhin ausführbare und verwundbare Runtime-Version vorhanden ist.
Veraltete Entwicklungs-Kits als blinder Fleck
In einer Entwicklungsumgebung können sich mehrere gemeinsam genutzte Runtime-Verzeichnisse nebeneinander befinden. Enthalten sie unterschiedliche .NET-Hauptversionen, vervielfacht sich die Zahl der installierten Runtime-Komponenten. Beim Überprüfen eines solchen Systems kann sich beispielsweise zeigen, dass eine ältere ASP.NET-Core-Version weiterhin vorhanden ist und eine inzwischen bekannte Schwachstelle aufweist – obwohl eine andere Installation derselben Runtime auf dem Rechner bereits aktualisiert wurde.
Für einen Angreifer ist entscheidend, welche verwundbaren Komponenten tatsächlich auf dem Endpunkt vorhanden und ausführbar sind. Damit verschiebt sich die sicherheitsrelevante Frage von „Wurde der Patch installiert?“ zu „Welche verwundbaren Komponenten existieren noch auf dem System?“.
Visual Studio verschärft das Problem
Eine zusätzliche Komplexität entsteht durch Visual Studio. SDKs, die zusammen mit Visual Studio installiert werden, unterliegen nicht zwangsläufig demselben Aktualisierungsmechanismus wie eigenständige .NET-Runtimes. In vielen Fällen hängt ihre Aktualisierung an der Pflege der Visual-Studio-Installation. Das kann dazu führen, dass ein Sicherheitsupdate für das Betriebssystem oder eine eigenständige .NET-Runtime erfolgreich eingespielt wurde, während ältere Komponenten innerhalb einer Visual-Studio-Installation weiterhin vorhanden sind.
Hinzu kommt das typische Verhalten in Entwicklungsumgebungen: Updates der IDE werden häufig zurückgestellt. Gründe dafür können die Kompatibilität von Erweiterungen, bestehende Build-Prozesse oder schlicht die Sorge sein, eine funktionierende Entwicklungsumgebung zu verändern. Damit treffen zwei Entwicklungen aufeinander: KI-Tools erhöhen die Geschwindigkeit, mit der neue SDKs und Abhängigkeiten auf Entwicklerrechner gelangen. Gleichzeitig können bestehende Prozesse dafür sorgen, dass diese Komponenten lange Zeit nicht wieder entfernt oder aktualisiert werden.
Klassische Compliance-Scans reichen nicht mehr aus
Für Unternehmen entsteht daraus ein strukturelles Problem. Klassische Endpoint- und Compliance-Lösungen konzentrieren sich oft auf den Status bekannter installierter Produkte und deren Patches. Ein Gerät, auf dem die aktuelle eigenständige .NET-Runtime installiert ist, kann deshalb als konform erscheinen. Eine vollständige Bestandsaufnahme muss berücksichtigen, welche .NET-SDK-Versionen installiert sind, welche Runtime-Versionen diese SDKs mitbringen, welche Visual-Studio-Komponenten vorhanden sind, welche Versionen inzwischen veraltet oder verwundbar sind und welche Komponenten Entwicklungsprojekte tatsächlich noch von benötigen.
Erst die Kombination dieser Informationen ermöglicht eine realistische Bewertung des Risikos. Das ist deshalb relevant, weil Entwicklerrechner keine gewöhnlichen Arbeitsplatzsysteme sind. Sie haben häufig Zugriff auf Quellcode-Repositories, Paket-Feeds, Zugangsdaten, Zertifikate sowie Infrastrukturen für Entwicklung und Deployment. Ein kompromittierter Entwicklerendpunkt kann deshalb die Unternehmenssicherheit deutlich stärker gefährden als ein gehackter Office-PC.
KI abschalten ist keine Lösung
Aus diesem Befund lässt sich allerdings nicht ableiten, dass Unternehmen KI-Coding-Tools grundsätzlich verbieten sollten. Vielmehr muss sich das Sicherheitsmodell an die veränderte Realität der Softwareentwicklung anpassen. „Update installiert“ sollte nicht als vollständiger Sicherheitsindikator für Entwicklungsumgebungen gelten. Der Status sagt zunächst nur aus, dass eine bestimmte Komponente aktualisiert wurde.
Erforderlich ist eine Bestandsaufnahme der tatsächlich vorhandenen SDKs und Runtime-Versionen. Auf dieser Grundlage lassen sich nicht mehr benötigte Versionen identifizieren und kontrolliert entfernen. Wichtig ist es dabei, zwischen Entwicklungs- und Laufzeitabhängigkeiten zu unterscheiden. Eine Bereinigung sollte nicht einfach pauschal alte Versionen löschen, sondern zunächst prüfen, ob ein SDK oder eine Runtime noch für Builds oder andere Prozesse benötigt wird.
Sicherheitskontrolle ohne zusätzlichen Agenten
Für Unternehmen stellt sich dabei eine weitere Frage: Wie lässt sich diese Transparenz herstellen, ohne auf jedem Entwicklerrechner zusätzliche Software installieren und betreiben zu müssen? Ein möglicher Ansatz ist die inhaltsgesteuerte Erkennung. Dabei werden Informationen genutzt, die bestehende Endpoint-Management- oder Security-Agenten ohnehin erfassen – etwa installierte Anwendungen, Komponenten und Patch-Zustände. Diese Daten werden mit Sicherheitsinformationen und Regeln abgeglichen, die nicht nur einzelne Produktversionen betrachten, sondern auch Abhängigkeiten zwischen SDKs, Runtimes und Entwicklungsumgebungen.
So lässt sich beispielsweise erkennen, dass eine ältere .NET-Runtime nicht deshalb sicher ist, weil eine neuere Version auf demselben System installiert wurde. Entscheidend ist vielmehr, ob die alte Version weiterhin vorhanden ist und welche Abhängigkeiten an ihr hängen. Ein entsprechender Erkennungs- und Bereinigungsprozess kann veraltete SDK- und Visual-Studio-Versionen markieren und vor einer Entfernung zunächst prüfen, ob diese noch für Kompilierung oder andere Entwicklungsprozesse benötigt werden.
Jede Entwicklungsumgebung braucht Hygiene
Die eigentliche Herausforderung liegt damit nicht in der KI selbst. Diese Technologie beschleunigt lediglich einen Prozess, der in der Softwareentwicklung schon lange existiert: die zunehmende Zahl von Abhängigkeiten und Komponenten. Der Unterschied besteht darin, dass KI-Agenten diese Veränderungen wesentlich schneller und autonomer durchführen können. Wo ein Entwickler früher bewusst eine Entwicklungsumgebung eingerichtet und später bereinigt hat, können heute innerhalb kurzer Zeit zahlreiche automatische Installations- und Konfigurationsvorgänge stattfinden.
Damit wird die Pflege der Entwicklungsumgebung zu einem Bestandteil des Software-Supply-Chain- und Endpoint-Security-Managements. Unternehmen sollten deshalb nicht nur kontrollieren, welchen Code KI erzeugt, sondern auch beobachten, welche Softwarekomponenten durch den Einsatz von KI auf den Entwicklerrechnern entstehen.
Der blinde Fleck liegt im Bestand
KI-Coding-Tools beschleunigen die Softwareentwicklung, können aber auch den Bestand an installierten Komponenten und Abhängigkeiten schneller wachsen lassen. Für Unternehmen reicht es deshalb nicht aus, allein den Patch-Status ihrer Entwicklerrechner zu überwachen. Sie müssen wissen, welche SDKs, Runtimes und Entwicklungswerkzeuge tatsächlich installiert sind, welche davon noch benötigt werden und wo bekannte Schwachstellen bestehen. Erst diese Transparenz ermöglicht es, Sicherheitsrisiken gezielt zu reduzieren, ohne notwendige Entwicklungsumgebungen zu beeinträchtigen. jf
