Illustration Absmeier foto ki designer

KI-Coding-Tools beschleunigen Entwicklung und verändern zugleich den Softwarebestand auf Entwicklerrechnern. Gerade bei .NET können mehrere SDKs und Runtimes parallel bestehen bleiben – auch dann, wenn Patch-Dashboards einen aktuellen Status melden. Für CIOs und Security-Verantwortliche wird deshalb die tatsächliche Komponenten-Inventur zum entscheidenden Kontrollpunkt: Welche Versionen sind vorhanden, welche werden noch benötigt und welche vergrößern unnötig die Angriffsfläche?

Management Summary

Patch-Status reicht nicht: Ein aktuelles Dashboard bildet nicht automatisch alle parallel installierten SDK- und Runtime-Versionen ab.
KI beschleunigt den Wildwuchs: Coding-Agenten können Werkzeuge und Abhängigkeiten in kurzer Zeit hinzufügen; ohne geregelte Bereinigung wächst der Bestand.
Entwicklerendpunkte sind Hochwertziele: Zugriff auf Quellcode, Paketquellen, Secrets und CI/CD macht verborgene Altkomponenten besonders risikoreich.
Inventar vor Aktion: SDKs, Runtimes, Feature-Bands und Visual-Studio-Komponenten müssen gemeinsam erfasst und gegen Support- sowie Sicherheitsdaten bewertet werden.
Hygiene wird Governance: Verantwortlichkeiten, Freigaben, Ausnahmen und kontrollierte Deinstallation gehören in Endpoint- und Software-Supply-Chain-Prozesse.

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.

Ashley Leonard, SVP of Product Management bei Absolute Security

Die steigende Nutzung von KI-Coding-Tools sorgt für eine neue Sicherheitslage.
Um ihre Angriffsfläche zu minimieren, müssen Unternehmen Cyberresilienz
über alle Endpunkte und ihre gesamte digitale Umgebung hinweg sicherstellen.
Bild: Absolute Security.

FAQ: Vibe Coding, .NET-SDKs und Endpoint-Sicherheit

Warum können mehrere .NET-SDKs gleichzeitig installiert sein?
Das .NET-SDK wird standardmäßig »side by side« installiert. Dadurch können mehrere Versionen auf einem Rechner koexistieren; die CLI wählt ohne abweichende Projektvorgabe in der Regel das neueste installierte SDK. [1][2]
Wie lässt sich der tatsächliche Bestand prüfen?
Für eine erste technische Inventur eignen sich dotnet –list-sdks, dotnet –list-runtimes und dotnet –info. Ergänzend sollten Softwareinventar, Installationspfade und Visual-Studio-Komponenten zentral erfasst werden. [1]
Bedeutet ein aktueller Patch-Status, dass keine alte Runtime mehr vorhanden ist?
Nein. Haupt- und teils auch Nebenreleases können parallel installiert sein. Servicing-Updates ersetzen zwar den vorherigen Patch innerhalb einer Linie, beseitigen aber nicht automatisch andere Hauptversionen oder gesondert verwaltete SDK-Bestände. [3][5]
Welche .NET-Versionen gelten aktuell als unterstützt?
Maßgeblich ist die laufend aktualisierte Support Policy von Microsoft. Zum Recherchezeitpunkt nennt sie .NET 10, .NET 9 und .NET 8 als unterstützte Versionen; für betriebliche Entscheidungen sollte stets die aktuelle Policy geprüft werden. [4]
Welche Rolle spielt global.json?
Mit global.json kann ein Projekt eine gewünschte SDK-Version beziehungsweise Roll-forward-Regeln festlegen. Vor dem Entfernen älterer SDKs sollte deshalb geprüft werden, welche Repositories daran gebunden sind. [2]
Können alte SDKs einfach automatisiert entfernt werden?
Eine pauschale Löschung ist riskant, weil Builds oder Tools eine konkrete Version benötigen können. Microsoft empfiehlt zunächst die installierten Versionen zu ermitteln; das .NET Uninstall Tool bietet unter anderem eine Vorschau per dry-run, hat jedoch dokumentierte Einschränkungen. [5][6][7]
Was sind die Grenzen des .NET Uninstall Tools?
Das Werkzeug unterstützt Windows und macOS, aber nicht Linux, und kann je nach Installationsweg nicht alle SDKs oder Runtimes entfernen. Insbesondere neuere, über den Visual Studio Installer installierte Komponenten können außerhalb seines Umfangs liegen. [6]
Warum muss Visual Studio separat betrachtet werden?
Visual Studio und mitgelieferte Komponenten können eigenen Wartungs- und Lebenszyklusregeln folgen. Deshalb sollten IDE-Kanal, Servicing-Stand und enthaltene .NET-Komponenten gemeinsam bewertet werden. [8]
Welche zusätzlichen Risiken bringen agentenbasierte Coding-Tools?
OWASP weist darauf hin, dass Coding-Agenten Shell-Befehle ausführen, Pakete installieren, Dateien ändern und auf Netzwerke zugreifen können. Sicherheitskontrollen sollten daher Berechtigungen begrenzen, Installationen protokollieren und Repository-Inhalte sowie neue Abhängigkeiten als Vertrauensgrenzen behandeln. [9][10]
Welche Management-KPI ist aussagekräftiger als reine Patch-Compliance?
Sinnvoll ist eine Kombination aus vollständiger Komponentenabdeckung, Anteil nicht unterstützter Versionen, Zeit bis zur Bewertung, dokumentierten Ausnahmen und erfolgreicher Entfernung nicht mehr benötigter SDKs beziehungsweise Runtimes. So wird nicht nur die Installation eines Updates, sondern der verbleibende ausführbare Bestand gemessen. [10]

Quellen (Abruf: 24.09.2026)

[1] Microsoft Learn: .NET SDK overview — https://learn.microsoft.com/en-us/dotnet/core/sdk
[2] Microsoft Learn: Select which .NET version to use — https://learn.microsoft.com/en-us/dotnet/core/versions/selection
[3] Microsoft Learn: .NET releases, patches, and support — https://learn.microsoft.com/en-us/dotnet/core/releases-and-support
[4] .NET: Official support policy — https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core
[5] Microsoft Learn: Remove the .NET runtime and SDK — https://learn.microsoft.com/en-us/dotnet/core/install/remove-runtime-sdk-versions
[6] Microsoft Learn: .NET Uninstall Tool overview — https://learn.microsoft.com/en-us/dotnet/core/additional-tools/uninstall-tool-overview
[7] Microsoft Learn: dotnet-core-uninstall dry-run — https://learn.microsoft.com/de-de/dotnet/core/additional-tools/uninstall-tool-cli-dry-run
[8] Microsoft Learn: Visual Studio 2022 Product Lifecycle and Servicing — https://learn.microsoft.com/en-us/visualstudio/releases/2022/servicing-vs2022
[9] OWASP: Secure Coding with AI Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html
[10] OWASP: Software Supply Chain Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html

1224 Artikel zu „KI Softwareentwicklung“

Künstliche Intelligenz | News | Services | Trends 2026 | Trends Services

KI verändert die Softwareentwicklung, der Bedarf an Entwicklern bleibt hoch

17. September 2026

KI ist in der Softwareentwicklung angekommen – doch der Sprung vom Pilotprojekt in den produktiven Maßstab gelingt nur mit Governance, sicheren Prozessen und gezieltem Kompetenzaufbau. Eine Studie zeigt, wo Unternehmen im DACH-Raum stehen, welche Effekte bereits messbar sind und warum Entwickler weiterhin gefragt bleiben. Management Summary KI ist etabliert, aber kaum industrialisiert: 91 % der…