Top 10 für LLM-Anwendungen 2026: Was die neue Sicherheitsliste über Code von KI-Assistenten sagt und was vor dem Einchecken folgt

Das Open Worldwide Application Security Project (OWASP) hat im August 2026 die Top 10 für LLM-Anwendungen (Large Language Models) vorgelegt. Die Liste der wichtigsten Sicherheitsrisiken von Anwendungen mit großen Sprachmodellen zählt in ihrer Ausgabe 2026 unsicheren Code, den Programmierassistenten in großer Menge erzeugen, nun zum Eintrag „Improper Output Handling“, der fehlerhaften Verarbeitung von Modellausgaben. Schon die OWASP Top 10:2025 für Webanwendungen nennen im Kapitel „Next Steps“, knapp außerhalb der Rangliste, blindes Vertrauen in KI-Code. Beide Listen liegen bereits vor, wenn Anfang November 2026 in San Francisco die OWASP Global AppSec USA beginnt, die größte US-Konferenz der OWASP. Die Provimedia GmbH aus Bietigheim-Bissingen, Herausgeberin des Prüfpakets Code Guardian für KI-Programmierassistenten, ordnet ein, was daraus für die Prüfung vor dem Einchecken folgt.

Herausgeber der Liste ist das OWASP GenAI Security Project, und ihr Datum hängt vom Dokument ab: Die Projektseite nennt den 3. August 2026, das PDF selbst den 4. August 2026. Die zugehörige Pressemitteilung folgte Anfang September 2026. Die OWASP-Listen sind Empfehlungen einer offenen Fachgemeinschaft, kein Gesetz. Die OWASP Foundation nennt ihre Top 10 für Webanwendungen selbst einen Referenzstandard und ein Dokument zur Sensibilisierung, das einen breiten Konsens über die kritischsten Risiken abbildet.

Die Top 10 für LLM-Anwendungen ordnen Assistenten-Code der Ausgabeverarbeitung zu

Die OWASP-Liste für 2026 führt den Code von Programmierassistenten unter dem Eintrag LLM10 (Improper Output Handling). Der Eintrag beschreibt Schäden, die entstehen, wenn Ausgaben eines Sprachmodells ungeprüft an andere Systeme weiterlaufen. In ihrer Einleitung schreiben die Projektleiter, der Eintrag umfasse nun auch den unsicheren Code, den Assistenten in großer Menge erzeugen. Eines der Angriffsszenarien schildert eine Anwendung, die KI-erzeugten Code ohne menschliche Durchsicht und ohne Sicherheitstests kompiliert und ausliefert. Der unsichere Code erreicht so den Produktivbetrieb und wird dort ausgenutzt.

Als erste Gegenmaßnahme nennt die LLM-Liste 2026, das Modell wie jeden anderen Nutzer zu behandeln, nach dem Zero-Trust-Prinzip also ohne Vertrauensvorschuss. Datenbankabfragen aus einem Modell sollen parametrisiert laufen, Ausgaben passend zum Zielkontext kodiert werden. Übertragen auf Programmierassistenten folgt daraus, ihren Code wie Eingaben aus einer nicht vertrauenswürdigen Quelle zu behandeln. Eine zweite Spur führt die Liste unter LLM04 (Supply Chain): erfundene Paketnamen, die Angreifer vorab registrieren, bekannt als Slopsquatting.

Im Ranking der Ausgabe 2026 fiel der Eintrag zur Ausgabeverarbeitung von Platz fünf auf Platz zehn, weiter als jeder andere Eintrag. Die Projektleiter führen die Verschiebungen allgemein auf Abweichungen zwischen Expertenurteil und Vorfallsdaten zurück. Die Rangfolge der OWASP-Liste beruht zu drei Vierteln auf einer Abstimmung unter Fachleuten und zu einem Viertel auf Vorfallsdaten. Dafür hat das Projekt nach eigenen Angaben 7.714 Vorfälle aus öffentlichen Schwachstellendatenbanken und einer Datenbank für KI-Schäden gesammelt und 6.639 davon maschinell eingeordnet.

Was empfiehlt das Kapitel „Next Steps“ der OWASP Top 10:2025 zu Vibe Coding?

Die OWASP Top 10:2025 für Webanwendungen liegen seit Ende Dezember 2025 in endgültiger Fassung vor; der Veröffentlichungskandidat war am 6. November 2025 erschienen. Im Kapitel „Next Steps“ steht der Eintrag X03:2025 „Inappropriate Trust in AI Generated Code (‚Vibe Coding‘)“, also unangemessenes Vertrauen in KI-erzeugten Code. Als Vibe Coding bezeichnet OWASP Code, der fast ohne menschliche Aufsicht geschrieben und eingecheckt wird. Der Eintrag hält fest, dass es bisher weder Schwachstellenmeldungen (CVE) noch Schwächeklassen (CWE) speziell zu KI-erzeugtem Code gibt. Dass solcher Code oft mehr Schwachstellen enthält als von Menschen geschriebener, nennt OWASP bekannt und dokumentiert, ohne an dieser Stelle eine Messung anzugeben.

Allen Programmierenden rät der Eintrag unter anderem zu fünf Schritten:

Jeden eingereichten Code lesen und vollständig verstehen können, auch wenn ihn eine KI geschrieben hat; verantwortlich ist, wer eincheckt.

KI-gestützten Code gründlich auf Schwachstellen prüfen, mit eigenen Augen und mit Werkzeugen wie statischer Analyse.

Code möglichst selbst schreiben, die KI Verbesserungen vorschlagen lassen und deren Vorschläge prüfen.

Einen MCP-Server, also eine Werkzeugschnittstelle nach dem Model Context Protocol, zwischen Entwicklungsumgebung und KI schalten, der die eigenen Prüfwerkzeuge durchsetzt.

Regeln für den KI-Einsatz im Entwicklungsprozess festlegen und Entwickler darin schulen.

Für komplexe Funktionen, geschäftskritische Programme und langlebige Software rät der Eintrag X03:2025 ausdrücklich von Vibe Coding ab.

Warum reicht bei KI-Agenten der Blick auf einzelne Codezeilen nicht?

Die OWASP Top 10 für agentische Anwendungen erschienen am 9. Dezember 2025 und behandeln KI-Systeme, die selbst Werkzeuge aufrufen und handeln. Erarbeitet wurden sie nach Angaben des Projekts mit mehr als 100 Fachleuten. Unter ASI05 (Unexpected Code Execution) beschreibt die Agentenliste, dass agentische Systeme, darunter verbreitete Vibe-Coding-Werkzeuge, oft Code erzeugen und ausführen. Ein Szenario, angelehnt an einen Fall beim Entwicklungsdienst Replit, schildert einen Agenten, der ungeprüfte Installations- und Shell-Befehle ausführt und Produktionsdaten löscht oder überschreibt.

Als Gegenmaßnahme nennt die Agentenliste, KI-Agenten keinen direkten Zugriff auf Produktivsysteme zu geben. Vibe-Coding-Systeme sollen nur mit Prüfungen vor dem Produktivbetrieb laufen, etwa mit Sicherheitsbewertungen und Unit-Tests aus Angreifersicht. Die LLM-Liste 2026 zieht die Grenze zwischen beiden Dokumenten ausdrücklich: Solange das Modell ein Baustein einer Anwendung ist, gilt sie. Sobald es mit Werkzeugen, Gedächtnis und Folgen selbst handelt, empfehlen die Projektleiter, die Agentenliste dazuzunehmen.

Was folgt aus den OWASP-Listen für die Prüfung vor dem Einchecken?

Aus den drei OWASP-Dokumenten lassen sich drei Prüffragen vor dem Einchecken ableiten. Versteht die Person, die eincheckt, den Code vollständig? Wurde der Code wie eine nicht vertrauenswürdige Eingabe geprüft, mit Durchsicht und mit Werkzeugen? Und führt von einem Agenten kein ungeprüfter Weg in den Produktivbetrieb? Verbindlich ist keine dieser Fragen, denn die Listen empfehlen und schreiben nichts vor.

Code Guardian der Provimedia GmbH setzt am Arbeitsablauf an, nicht allein am Quelltext. Nach Angaben der Produktseite prüft das Skill-Paket für Claude Code und Codex, ob eine Behauptung mit einer Kommando-Ausgabe belegt ist. Ebenso prüft es, ob eine Auslieferung auf den Server oder eine Datenbankmigration überhaupt losgehen darf. Einen Plan vor der Änderung, in Claude Code auch dessen Freigabe, sieht das Paket als Arbeitsweise vor; eine Sperre erzwingt das nicht. Prüf-Agenten des Pakets lesen den Code kalt, ohne das Gespräch, den Plan und das Urteil des Autors. Was das Paket nicht leistet, beschreibt die Anleitung zu Stand und Grenzen von Code Guardian: Es findet nicht jeden Fehler, und über Änderung, Freigabe und Auslieferung entscheiden die Nutzer selbst.

„Die OWASP-Listen verschieben die Frage vom Werkzeug zum Menschen: Nicht wer den Code geschrieben hat, zählt, sondern ob ihn vor dem Einchecken jemand verstanden hat. Ein Prüfwerkzeug kann helfen, diese Frage zu stellen. Beantworten muss sie weiterhin, wer eincheckt“, sagt Alexander Weipprecht, Geschäftsführer der Provimedia GmbH.

Die Listen lassen offen, wie viele Schwachstellen auf KI-Code zurückgehen

Wie groß der Anteil von KI-erzeugtem Code an ausgenutzten Schwachstellen ist, beantworten die OWASP-Listen nicht. Das Kapitel „Next Steps“ der Top 10:2025 ordnet dem Eintrag X03 keine einzige Schwächeklasse zu, und die Vorfallsdaten der LLM-Liste 2026 gehen nur zu einem Viertel in die Rangfolge ein. Die Projektleiter nennen die Daten eines einzelnen Jahres selbst unvollkommen. Das Programm der OWASP Global AppSec USA am 5. und 6. November 2026 in San Francisco gliedert sich unter anderem in Themenschienen zu Planung und Design, Implementierung und Tests.

Die Provimedia GmbH ist ein Online-Verlag mit Sitz in der Region Stuttgart. Wir schaffen wertvolle Informationen in unterschiedlichen Branchen um Wissen schnell und einfach zugänglich zu machen. Wir haben uns auf übersichtliche Webseiten und Auffindbarkeit von Informationen spezialisiert.