KI findet Zero Days, scheitert aber an sicherem Code

width="1024" height="576" sizes="auto, (max-width: 1024px) 100vw, 1024px">



Wie diverse Studien zeigen, bereichert KI die Cybersecurity eher einseitig.Gorodenkoff | shutterstock.com



Künstliche Intelligenz (KI) hat im Security-Bereich in den letzten Monaten einiges bewegt. Mit Hilfe der Technologie werden inzwischen regelmäßig Zero-Day-Schwachstellen identifiziert, die teilweise jahrelang unentdeckt geblieben sind.



In entscheidenden Bereichen der Cyberabwehr scheint sich die KI allerdings weit weniger schnell und zielführend zu entwickeln. Zum Beispiel, wenn es um Code geht: Wird dieser per KI generiert, finden sich darin regelmäßig grundlegende Sicherheitslücken. Das ist nicht nur wegen des Verbreitungsgrads dieser Tools kritisch, sondern auch mit Blick darauf, Patches für die Lücken bereitzustellen, die diese mittlerweile mühelos finden.



So hat der Sicherheitsanbieter Veracode in seinem aktuellen „GenAI Code Security Report“ ermittelt, dass 44 Prozent des KI-generierten Codes mindestens eine bekannte Schwachstelle aus der OWASP-Top-10 beinhaltet. Dabei konnten die neuesten Spitzenmodelle zwar bessere Werte erzielen, allerdings erreichte kein Modell eine „Security Pass Rate“ von mehr als 68 Prozent. Jeder dritte Programmierversuch der KIs resultierte also in unsicherem Code.



Dass sämtliche getesteten KI-Modelle parallel in 99 Prozent der Fälle syntaktisch korrekten Code ausspuckten, macht die Sache nicht besser. Im Gegenteil. „Warum wird KI in Sachen Syntax und Exploit Code immer besser und fähiger, ist aber immer noch nicht in der Lage, sicheren Code zu schreiben?“, bringt Chris Wysopal, Chief Security Evangelist bei Veracode, die entscheidende Frage aus Sicht von Security- und IT-Entscheidern auf den Punkt.



Diese und weitere Fragestellungen beleuchten wir gemeinsam mit verschiedenen Security- und KI-Profis in diesem Artikel.



Die KI-getriebene Security-Asymmetrie



Nicht nur Veracode beobachtet eine wachsende Asymmetrie zwischen den offensiven und defensiven Security-Fähigkeiten von Large Language Models (LLMs). So kommt auch die niederländische Software Improvement Group (SIG) in ihrem Report „State of Software 2026“ (PDF) zu dem Ergebnis, dass KI-generierter Code im Vergleich etwa doppelt so viele Security Incidents verursacht wie manuell erstellter.



„Wir haben außerdem festgestellt, dass 71 Prozent des gesamten Codes – also nicht nur KI-generierter – lediglich über ein geringes Maß an Sicherheitskontrollen verfügt“, konstatiert Jasper Geurts, CTO von SIG. Die KI habe dieses Problem zwar nicht verursacht, aber verstärkt, meint der Manager: „Wo Unternehmen die Codequalität gemessen und gesteuert haben, beschleunigt die KI die Delivery. Wo das nicht der Fall war, beschleunigt sie nun die technische Verschuldung und erhöht die Cybersecurity-Risiken.“



Im Juli 2026 analysierten Forscher der Security-Testing-Plattform Xint.io (im Besitz des Sicherheitsanbieters Theori) zudem fünf aktuelle KI-Modelle von Anthropic und OpenAI hinsichtlich ihrer Code-Sicherheit. Die Modelle sollten einerseits Anwendungen im Vibe-Coding-Verfahren von Grund auf neu erstellen. Andererseits auch eine manuell geschriebene umgestalten – und absichern.



Das unschöne Ergebnis: In den resultierenden 28 App-Varianten fanden und validierten die Forscher insgesamt 434 Sicherheitslücken. Davon identifizierten sie 196 in den neu generierten Codebasen und 238 in der umstrukturierten Anwendung.



„Wie wir festgestellt haben, sind die am häufigsten auftretenden Schwachstellen in KI-generiertem Code solche, bei denen der Code selbst noch kompiliert werden kann – also läuft. Aber dieser enthält eingebettete Secrets oder sorgt für übermäßige Ressourcennutzung“, erklärt Kay Kwak, Product Owner für Xint bei Theori.



Das sei zum Teil auf Shortcuts und Schnellschüsse in Zusammenhang mit den Trainingsdaten zurückzuführen – sowie darauf, dass Entwickler eine Funktion anforderten, ohne dabei ausdrücklich nach entsprechenden Guardrails zu fragen, hält Kwak fest und ergänzt: „Wir haben zudem festgestellt, dass die KI analog zur steigenden Größe und Komplexität einer Codebasis zunehmend den Überblick über granulare Benutzerberechtigungen verliert.“



Probleme damit, sicheren Code zu generieren, haben KI-Modelle leider auch, wenn sie gezielt Sicherheitslücken beheben sollen. Das konnte die Research-Abteilung von 1Password im Rahmen einer Untersuchung (PDF) feststellen: Die Forscher ließen verschiedene KI-Modelle Patches für sechs bekannte (und bereits behobene) Schwachstellen in sechs komplexen Open-Source-Projekten generieren.



Die Zielsetzung war dabei, die Schwachstellen vollständig zu beheben, ohne das Anwendungsverhalten wesentlich zu verändern. Bei mehr als 6.000 Durchläufen lag die durchschnittliche Erfolgsquote der KI bei gerade einmal 26 Prozent. Mehr als 50 Prozent der von den LLMs generierten Patches behob die Schwachstelle nicht, führte stattdessen eine neue ein – oder beides.



„Wir haben bei unserer Untersuchung das Thema Patching fokussiert – als eher einen Bearbeitungsprozess. Deshalb sollten unsere Ergebnisse als komplementär zu denen von Veracode betrachtet werden. Beide Untersuchungen weisen in dieselbe Richtung“, erklärt Keith Hoodlet, Head of Research bei 1Password.



Deshalb reicht optimiertes Training nicht



Warum die KI zwar Sicherheitslücken aufdeckt und Exploit-Code schreibt, aber hinterherhinkt, wenn es darum geht, Schwachstellen zu beheben und sicheren Code zu erzeugen, ist unter Experten strittig.



Theori-Manager Kwak gibt an dieser Stelle zu bedenken, dass es sich in beiden Fällen um Probleme handelt, die naturgemäß diffizil sind: „Die Schwierigkeit ist nicht auf KI beschränkt. Die Softwareentwicklung hat generell ein Problem mit unvollständigen Spezifikationen. Niemand schreibt alles auf, was der Code nicht tun darf.“



Die Diskrepanz erklären, könnten auch unterschiedliche Definitionen von Erfolg für offensive und defensive Security-Szenarien. Im erstgenannten Fall verhält es sich relativ simpel: Wenn ein Angreifer eine Schwachstelle reproduzieren oder ausnutzen kann, ist das ein konkretes Ergebnis. Festzustellen, ob ein Patch jeden relevanten Exploit-Vektor und jeden anfälligen Code-Pfad schließt, ist hingegen ungleich schwieriger.



Dennoch ist die Qualität der Trainingsdaten entscheidend für die Performance von LLMs. Man kann deshalb davon ausgehen, dass bestehende Modelle in weiten Teilen auf öffentlich verfügbarem Code trainiert wurden – dessen Qualität und Sicherheit stark variiert.



Veracode-Manager Wysopal appelliert deshalb an KI-Anbieter, das zu ändern: „Legt euch zukünftig den bestmöglichen Trainingscode zu. Vielleicht von Banken oder aus anderen Bereichen wie der Luftfahrt, wo dieser bekanntermaßen strengen Prüfungen unterzogen wird. Das ist die richtige Trainingsgrundlage. Aber eben schwierig und zeitaufwendig. Deshalb gehen die Anbieter auch nicht so vor, soweit ich informiert bin.“



Sicherheitsexperte Hoodlet weist indes auf eine weitere Limitation von LLMs hin: Die Attention-Mechanismen, anhand derer die Modelle den Kontext und die Relevanz von Input-Token bewerten. „Diese grundlegenden Mechanismen könnten verhindern, dass KI-Modelle Schwachstellen jemals vollumfänglich beheben können. Im Rahmen unserer Forschungsarbeit haben wir Situationen beobachtet, in denen der Patch eines KI-Agenten nur einen einzigen Code-Pfad aus dem Proof-of-Concept-Exploit abdeckte – während die KI reihenweise identische Instanzen desselben Fehlers in benachbarten Pfaden übersehen hat.“



Wie viel mehr Training erforderlich ist, um angesichts dieser inhärenten Einschränkung sicherere Coding-Ergebnisse zu erzielen, sei unklar, so der Chef-Researcher.



SIG-CTO Geurts ist hingegen davon überzeugt, dass optimiertes Training nur in begrenztem Maße helfen kann: „KI-Modelle verfügen standardmäßig nicht über die Architektur, die Sicherheitsrichtlinien, das Bedrohungsmodell und anderen, anwendungsspezifischen Kontext einer Organisation. Ein KI-Harness kann diesen bereitstellen und dafür sorgen, deterministische Sicherheitsüberprüfungen in den Entwicklungs-Workflow einzubetten.“



Auf das Harness kommt es an



Damit spricht Geurts einen wichtigen Punkt an. Denn zur Wahrheit gehört auch: Veracode nutzte für seine Studie bewusst minimal ausgestaltete Prompts ohne zusätzliche Sicherheitsanweisungen.



Das entspricht allerdings nicht der Art und Weise, wie Entwicklungs-Teams LLMs in der Praxis einsetzen. Die anderen genannten Untersuchungen nutzten ein unterschiedlich robust ausgestaltetes Grundgerüst.



Allerdings bezog keine der Studien die gesamte Bandbreite an Kontrollmechanismen mit ein, die in einer Entwicklungs-Pipeline im Enterprise-Umfeld möglicherweise vorhanden sind. Etwa spezialisierte KI-Assistenten, die über detaillierte Spezifikationen verfügen, Validierungs-Workflows, System-Prompts, MCP-Verbindungen, Skill-Definitionen und weitere unterstützende Tools.



Ein Harness dieser Art kann:




relevante Dateien und Architekturdokumentation abrufen,



Informationen zu Threat-Modellen bereitstellen,



genehmigte Codierungs-Pattern auflisten,



Compiler und Tests ausführen,



SAST- und DAST-Tools aufrufen, sowie



„Approval Gates“ etablieren, die KI-Agenten daran hindern, fortzufahren, bis identifizierte Fehler behoben sind.




Wie KI-Forscher Kwak berichtet, konnte sein Unternehmen im Rahmen von internen Tests zeigen, wie groß der Unterschied ist, wenn ein Harness zum Einsatz kommt: „Wir haben Frontier-KI-Modelle mit 208.000 Codezeilen konfrontiert, die 17 eingebettete Schwachstellen enthielten. Simple Prompt-Loops führten dazu, dass gar keine bis eine Schwachstelle gefunden wurde. Die Modelle, die innerhalb unserer speziellen Harness operierten, konnten hingegen zwischen elf und 14 Schwachstellen identifizieren.“  



Das KI-Harness kann insofern mindestens ebenso wichtig sein wie die Wahl des Modells selbst. Ganz besonders, wenn dieses mit ausgedehnten Repositories arbeiten soll, wie SIG-Experte Geurts erklärt: „Das Harness ist das Betriebssystem für KI-Agenten. Dort legt man die Einschränkungen fest, die die KI zuverlässig machen. Ohne ein Harness ist KI schnell und überzeugend. Aber eben auch, wenn sie falsch liegt.“



Allerdings ist selbst ein gut konzipiertes KI-Harness keine Garantie dafür, dass keine Schwachstellen zurückbleiben.



Der Mensch bleibt (vorerst) im Loop



Validierungs-Gates und automatisierte Prüfungen können die Menge an fehlerhaftem Code reduzieren, der die Entwickler erreicht. Das verlagert die Verantwortung für das Ergebnis aber nicht auf das LLM. Ein KI-Agent kann auf die Scan-Ergebnisse reagieren, Tests durchführen und seinen Output überarbeiten.



Letztendlich entscheidet aber weiterhin das Anwenderunternehmen, ob die Anforderungen vollständig erfüllt sind, die Validierung ausreichend und das Restrisiko akzeptabel ist. Bewährte Sicherheitskontrollen wie Type Checking, Unit- und Integrationstests oder Secrets Scanning durch KI-basierte Code-Reviewer zu ersetzen, ist also nicht zu empfehlen.



Veracode-Manager Wysopal rät stattdessen zu einem komplementären Ansatz: „Security-Tests auf Agenten-Basis können konventionelle Sicherheitskontrollen ergänzen. Beide Verfahren können potenziell Probleme identifizieren, die dem jeweils anderen entgehen.“



Letztendlich sollten sicherheitsrelevante Änderungen jedoch unter der Kontrolle der Entwickler bleiben, die den Code um den es geht – und seine Rolle im Gesamtsystem – verstehen. Auch Research-Experte Kwak plädiert deshalb für das „Human in the Loop“-Prinzip: „Man würde eine KI auch nicht ohne menschliche Aufsicht Software bereitstellen lassen. Warum sollte man also auf automatisierte Patch-Prozesse setzen, die die Engineers umgehen?“



Natürlich ist eine manuelle Validierung der Geschwindigkeit, mit der Unternehmen KI-generierte Änderungen annehmen können, nicht zuträglich. Schließlich produzieren KI-Agenten immer mehr Code – und potenzielle Patch-Kandidaten.



Zumindest vorerst ist es jedoch mit diversen Gefahren verbunden, diesen Review-Prozess als überflüssig anzusehen, wie auch 1Password-Manager Hoodlet konstatiert: „Schneller größere Mengen an Code zu produzieren, ist nicht gleichbedeutend damit, funktionsfähigen, sicheren und langlebigen Code zu produzieren. Und gerade diese Art von Code ist besonders effizient – denn er muss nur einmal geschrieben werden.“ (fm)



Dieser Artikel ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen.