Kaum eine Technologie verändert sich derzeit so unmittelbar, wie Software entsteht. Aus einer Beschreibung in natürlicher Sprache wird in kurzer Zeit ein erster Prototyp. Bestehende Anwendungen lassen sich mit Unterstützung eines Coding Agents analysieren, verändern oder auf andere Technologieplattformen übertragen. Aufgaben, für die früher tiefes Spezialwissen oder mehrere Tage Entwicklungsarbeit nötig waren, können heute deutlich schneller erledigt werden.
Gerade darin liegt der große Nutzen. KI macht Entwicklung zugänglicher und verkürzt den Weg von einer Idee zum funktionierenden Ergebnis. Projekte, die bislang an Aufwand, fehlenden Ressourcen oder mangelnder Erfahrung mit einem bestimmten Technologiestack gescheitert wären, werden plötzlich realistisch. Mit dem Tempo entsteht allerdings ein zweiter Effekt. Wenn Software schneller und von mehr Menschen entwickelt werden kann, wächst auch die Menge des erzeugten Codes. Und mit ihr steigt die Zahl der Stellen, an denen Sicherheitsprobleme entstehen können.
Sichtbarer Erfolg verdeckt unsichtbare Arbeit
Sicherheit hatte in Entwicklungsprojekten schon immer einen strukturellen Nachteil. Neue Funktionen sind sichtbar. Sie lassen sich demonstrieren, testen und unmittelbar bewerten. Gute Sicherheitsarbeit dagegen bleibt meist unbemerkt, solange sie funktioniert. Genau deshalb wird sie leicht nach hinten geschoben. Eine Anwendung, die nach kurzer Zeit startet und die gewünschte Funktion erfüllt, vermittelt einen unmittelbaren Erfolg. Ob Eingaben ausreichend validiert werden, Berechtigungen korrekt greifen oder sensible Daten angemessen verarbeitet werden, ist dagegen auf den ersten Blick kaum erkennbar.
Coding Agents verstärken diesen Unterschied. Sie sind hervorragend darin, schnell ein sichtbares Ergebnis zu erzeugen. Damit steigt aber die Gefahr, dass ein funktionierender Zwischenstand vorschnell mit einem produktionsreifen Ergebnis verwechselt wird. Das Problem ist nicht nur theoretischer Natur. Eine Studie von Forschern der Stanford University untersuchte, wie sich KI-Unterstützung auf sicherheitsrelevante Programmieraufgaben auswirkt. Teilnehmer mit Zugriff auf einen KI-Assistenten produzierten im Versuch weniger sicheren Code als die Vergleichsgruppe ohne Assistenten. Gleichzeitig bewerteten sie ihre eigenen Lösungen häufiger als sicher.
Diese Kombination ist besonders relevant. Das eigentliche Risiko besteht nicht allein darin, dass KI fehlerhaften Code erzeugt. Kritischer wird es, wenn ein plausibel wirkendes Ergebnis das Vertrauen in die eigene Lösung erhöht und dadurch die Intensität der nachfolgenden Prüfung sinkt.
Schwachstellen bleiben klassische Schwachstellen
KI erzeugt dabei nicht automatisch völlig neue Kategorien von Sicherheitsproblemen. Häufig reproduziert sie bekannte Schwächen, die seit Jahren Bestandteil sicherer Softwareentwicklung sind. Bei Webanwendungen betrifft das beispielsweise unzureichende Eingabevalidierung, unsichere Behandlung von Ausgaben, fehlerhafte Zugriffskontrollen oder Schwächen beim Umgang mit sensiblen Informationen. Gerade solche Stellen können im normalen Funktionstest unauffällig bleiben, obwohl sie sicherheitskritisch sind. Der „2025 GenAI Code Security Report“ von Veracode liefert dafür ein konkretes Beispiel. Der Anbieter für Anwendungssicherheit testete mehr als 100 Sprachmodelle mit Aufgaben in Java, Python, C# und JavaScript. 45 Prozent der generierten Codebeispiele bestanden die jeweils vorgesehenen Sicherheitstests nicht. Bei Aufgaben zu Cross-Site-Scripting (CWE-80) erzeugten die Modelle in 86 Prozent der relevanten Fälle unsicheren Code. Da die Untersuchung von einem Security-Anbieter stammt, sollten die Zahlen entsprechend eingeordnet werden. Sie zeigen dennoch, dass bekannte Schwachstellen auch bei KI-generiertem Code keineswegs verschwinden.
Für Entwicklungsorganisationen folgt daraus eine einfache Konsequenz. KI-Code darf nicht als Sonderfall außerhalb bestehender Sicherheitsprozesse behandelt werden. Er muss mindestens denselben Qualitäts- und Sicherheitsprüfungen unterliegen wie manuell geschriebener Code.
Misstrauen schützt nicht automatisch Interessant ist, dass Entwickler den Ergebnissen von KI keineswegs blind vertrauen. Laut Stack Overflow Developer Survey 2025 nutzen 84 Prozent der Befragten KI-Werkzeuge bereits oder planen den Einsatz. Zugleich misstrauen 46 Prozent der Genauigkeit der Ergebnisse, während nur 33 Prozent der Genauigkeit vertrauen. Auf den ersten Blick klingt das nach einem gesunden Maß an Skepsis. In der Praxis löst dieses Misstrauen das Problem aber nicht automatisch. KI-generierter Code wird trotzdem übernommen, erweitert und in bestehende Anwendungen integriert.
Der Grund liegt in der Qualität vieler Vorschläge. Sie wirken plausibel, sind sauber formuliert und funktionieren häufig auch im ersten Test. Damit verschiebt sich die Herausforderung. Entwickler müssen nicht mehr jede Zeile selbst erzeugen, sondern zunehmend beurteilen, ob ein bereits vorliegender Vorschlag tatsächlich robust ist. Genau dafür braucht es Erfahrung. Wer eine unsichere Lösung nicht erkennt, produziert mit KI möglicherweise nicht weniger Fehler, sondern nur schneller mehr davon.
Selbstkontrolle ersetzt kein Vier-Augen-Prinzip
Eine naheliegende Reaktion lautet deshalb: Wenn KI den Code erzeugt, kann sie ihn anschließend doch auch prüfen. Grundsätzlich kann KI bei Security Reviews durchaus helfen. Spezialisierte Modelle können Schwachstellen identifizieren, Hinweise priorisieren oder Entwickler bei der Analyse unterstützen. Problematisch wird es jedoch, wenn dieselbe Instanz praktisch als Autor und Prüfer eingesetzt wird. Ein Modell, das mit denselben Annahmen, demselben Kontext und ähnlichen Mustern arbeitet, bildet keine wirklich unabhängige Kontrollinstanz. Eine Untersuchung aus dem Jahr 2025 zur iterativen KI-Codegenerierung macht diese Grenze deutlich. In einem kontrollierten Experiment mit 400 Codebeispielen stieg die Zahl kritischer Schwachstellen bereits nach fünf KI-gestützten Überarbeitungsrunden um 37,6 Prozent.
Das heißt nicht, dass KI-basierte Prüfungen nutzlos wären. Im Zusammenspiel mit statischer Codeanalyse, automatisierten Sicherheitstests und einem menschlichen Review können sie einen wertvollen Beitrag leisten. Sie ersetzen aber nicht die unabhängige Kontrolle. Die entscheidende Trennung lautet daher: KI kann Sicherheitsarbeit verstärken. Sie sollte aber nicht allein darüber entscheiden, ob der von ihr erzeugte Code sicher genug ist.
Der Cyber Resilience Act erhöht den Druck
Diese Frage bekommt durch den Cyber Resilience Act zusätzliche Bedeutung. Die Verordnung stellt Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen über deren gesamten Lebenszyklus hinweg. Dazu gehören unter anderem die Bewertung von Cybersicherheitsrisiken, der Umgang mit Schwachstellen sowie technische Dokumentationspflichten. Ein Teil der Vorgaben greift bereits. Die Meldepflichten nach Artikel 14 für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle gelten seit dem 11. September 2026.. Ab dem 11. Dezember 2027 gilt die Verordnung insgesamt.
Für Unternehmen verändert sich damit die Risikorechnung. Unsicherer Code ist nicht mehr nur ein mögliches Qualitätsproblem, das sich im Zweifel später korrigieren lässt. Sicherheitsanforderungen müssen systematisch in Entwicklungsprozesse eingebaut und nachvollziehbar dokumentiert werden.
Dabei spielt es keine Rolle, ob eine problematische Funktion manuell programmiert, aus einer Bibliothek übernommen oder von einem Coding Agent vorgeschlagen wurde. Die Verantwortung bleibt beim Hersteller beziehungsweise bei der Organisation, die das Produkt auf den Markt bringt. Gerade der Übergang vom Prototyp zur produktiven Anwendung wird dadurch kritisch. Coding Agents eignen sich hervorragend, um Ideen schnell umzusetzen. Was in einem Proof of Concept funktioniert, ist jedoch noch kein hinreichender Nachweis für Security, Wartbarkeit oder regulatorische Konformität.
Entwicklungsprozesse müssen mitwachsen
Die Antwort kann nicht darin bestehen, KI aus der Softwareentwicklung herauszuhalten. Die Produktivitätsgewinne sind real, und der Nutzen für Modernisierung, Prototyping und tägliche Entwicklungsarbeit ist zu groß, um diese Werkzeuge grundsätzlich auszuschließen. Entscheidend ist vielmehr, dass Sicherheitsprozesse mit der Entwicklungsgeschwindigkeit Schritt halten. Automatisierte Security Tests und statische Codeanalyse sollten fest in die Entwicklungsabläufe integriert werden. Für relevante Änderungen braucht es weiterhin menschliche Prüfungen, insbesondere bei sicherheitskritischen Komponenten und Schnittstellen.
Ebenso wichtig ist die Qualifikation der Entwickler. Wer mit Coding Agents arbeitet, muss deren Ergebnisse nicht nur nutzen, sondern bewerten können. Kenntnisse in Secure Coding werden deshalb nicht weniger wichtig, sondern gewinnen an Bedeutung. Auch die Erfolgsmessung sollte angepasst werden. Wenn Teams nur danach beurteilt werden, wie schnell neue Funktionen entstehen, entstehen falsche Anreize. Stabilität, Nacharbeit, Sicherheitsbefunde und Wartbarkeit gehören genauso zur Qualität einer modernen Entwicklungsorganisation wie reine Geschwindigkeit.
Der Cyber Resilience Act verstärkt diese Notwendigkeit zusätzlich. Unternehmen müssen bereits heute wissen, welche Produkte betroffen sind, wie Security Reviews organisiert werden, wie Schwachstellen behandelt werden und wie sich diese Prozesse dokumentieren lassen. KI kann Softwareentwicklung erheblich beschleunigen. Sie nimmt Unternehmen aber nicht die Verantwortung dafür ab, was am Ende produktiv eingesetzt wird. Genau darin liegt die eigentliche Veränderung: Je leichter es wird, Code zu erzeugen, desto wichtiger wird die Fähigkeit, seine Qualität zuverlässig zu beurteilen.
