Der zunehmende Einsatz von KI-Kodierungstools – kurz Vibe-Coding – beschleunigt zwar die Softwareentwicklung erheblich. Allerdings verändert die Nutzung dieser Tools unbemerkt die Zusammensetzung von Entwicklungsumgebungen und schafft damit ein Sicherheitsproblem, das klassische Patch- und Compliance-Prozesse übersehen können. Besonders betroffen sind Entwicklerrechner mit zahlreichen .NET-SDK- und Runtime-Versionen.
Generative KI und agentenbasierte Entwicklungswerkzeuge sind inzwischen fester Bestandteil moderner Softwareentwicklung. Copiloten und Coding-Agenten schreiben Codes, installieren Abhängigkeiten und konfigurieren Entwicklungsumgebungen in Sekunden. Was dabei häufig fehlt, ist ein ebenso automatisiertes Aufräumen.
Genau hier entsteht ein sicherheitsrelevanter Nebeneffekt: Mit jeder neuen Entwicklungsaufgabe können zusätzliche Versionen des .NET-SDK auf dem Rechner eines Entwicklers landen. Ältere Versionen bleiben dabei häufig installiert – auch dann, wenn sie für aktuelle Projekte längst nicht mehr benötigt werden. Das Problem liegt weniger in der Installation selbst als in der fehlenden Transparenz darüber, welche Komponenten tatsächlich noch vorhanden und potenziell verwundbar sind.
KI verändert den Softwarebestand auf Entwicklerrechnern
Wer eine Entwicklungsumgebung manuell einrichtet, entwickelt mit der Zeit ein Bewusstsein dafür, welche Komponenten benötigt werden und welche nicht. Ein KI-Agent verfolgt dagegen 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 automatisch ü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. Aus Security-Sicht entsteht jedoch ein Problem, wenn nicht mehr benötigte Versionen dauerhaft auf dem System verbleiben. 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 von CVEs 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. Und es handelt sich 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 noch von einem installierten SDK benötigt werden. 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.
Ein konkretes Beispiel für den blinden Fleck
In einer Entwicklungsumgebung können sich ohne Weiteres mehrere gemeinsam genutzte Runtime-Verzeichnisse nebeneinander befinden. Enthalten sie unterschiedliche .NET-Hauptversionen, vervielfacht sich entsprechend die Zahl der installierten Runtime-Komponenten. Bei einer Überprüfung 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 nicht relevant, welche Version das Patch-Dashboard als aktuell ausweist. Entscheidend ist, 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.
Warum klassische Compliance-Scans nicht ausreichen
Für Unternehmen entsteht daraus ein strukturelles Problem. Klassische Endpoint- und Compliance-Lösungen konzentrieren sich häufig 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 müsste 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,
• welche Komponenten tatsächlich noch von Entwicklungsprojekten benötigt werden.
Erst die Kombination dieser Informationen ermöglicht eine realistische Bewertung des Risikos. Das ist insbesondere deshalb relevant, weil Entwicklerrechner keine gewöhnlichen Arbeitsplatzsysteme sind. Sie haben häufig Zugriff auf Quellcode-Repositories, Paket-Feeds, Zugangsdaten, Zertifikate sowie Entwicklungs- und CI/CD-Infrastrukturen. Ein kompromittierter Entwicklerendpunkt kann deshalb einen deutlich größeren Einfluss auf die Unternehmenssicherheit haben als ein klassischer Office-PC.
Die Lösung ist nicht das Abschalten von KI
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 verstanden werden. Der Status sagt zunächst nur aus, dass eine bestimmte Komponente aktualisiert wurde.
Erforderlich ist stattdessen eine Bestandsaufnahme der tatsächlich vorhandenen SDKs und Runtime-Versionen. Auf dieser Grundlage können nicht mehr benötigte Versionen identifiziert und kontrolliert entfernt werden. Wichtig ist 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 können mit Sicherheitsinformationen und Regeln abgeglichen werden, die nicht nur einzelne Produktversionen betrachten, sondern auch Abhängigkeiten zwischen SDKs, Runtimes und Entwicklungsumgebungen berücksichtigen.
Auf diese Weise 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.
KI erhöht den Bedarf an Hygiene in der Entwicklungsumgebung
Die eigentliche Herausforderung liegt damit nicht in der KI selbst. KI 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.
Fazit: Der blinde Fleck liegt nicht im Patch, sondern im Bestand
KI-Coding-Tools stellen Unternehmen vor eine neue Sicherheitsfrage: Nicht nur der erzeugte Code, sondern auch die von den Werkzeugen hinterlassene Entwicklungsumgebung muss kontrolliert werden. Gerade bei .NET kann ein Rechner gleichzeitig aktuelle und veraltete SDK- und Runtime-Versionen enthalten. Ein erfolgreich installierter Sicherheits-Patch beseitigt dabei nicht zwangsläufig jede ältere, verwundbare Komponente. Visual Studio kann diesen Effekt zusätzlich verstärken.
Für IT- und Security-Verantwortliche bedeutet das, dass klassische Patch-Compliance allein nicht mehr ausreicht. Entscheidend ist eine vollständige Sicht auf den Softwarebestand – einschließlich der Komponenten, die innerhalb von SDKs und Entwicklungsumgebungen verborgen sind. Die Konsequenz muss nicht sein, KI-Coding zu bremsen. Im Gegenteil: Je stärker Unternehmen auf autonome Entwicklungswerkzeuge setzen, desto wichtiger wird eine automatisierte und möglichst reibungslose Hygiene der Entwicklungsumgebungen.
Die zentrale Frage lautet nicht mehr, ob ein Entwicklerrechner gepatcht ist. Sie lautet: Welche ausführbaren Komponenten befinden sich tatsächlich noch darauf – und warum? Wer diese Frage zuverlässig beantworten kann, schließt einen blinden Fleck, den klassische Compliance-Mechanismen bislang leicht übersehen. Denn angesichts der zunehmenden Komplexität und Anzahl solcher Vorfälle müssen Unternehmen die Cyber-Resilienz über alle Endpunkte und ihre gesamte digitale Umgebung hinweg sicherstellen, um ihre Angriffsfläche zu minimieren.
Von Ashley Leonard, SVP of Product Management bei Absolute Security
