OWASP Top 10 für LLM-Anwendungen

Definition

Die OWASP Top 10 für LLM-Anwendungen ist eine von der Community gepflegte Liste der kritischsten Schwachstellenklassen in Anwendungen, die auf großen Sprachmodellen basieren. Sie wird vom OWASP GenAI Security Project veröffentlicht und regelmäßig an Veränderungen im Ökosystem angepasst.

Anwendungsbereich

Jede Anwendung, die auf einem großen Sprachmodell basiert – Chat-Schnittstellen, Retrieval-Systeme, Agenten und die von ihnen aufgerufenen Tools. Sie ist freiwillig, nicht zertifizierbar und bewusst deskriptiv: Sie klassifiziert Risiken, schreibt jedoch keine Kontrollen vor und gewährt keine Compliance.

Kernanforderungen

• Prompt Injection führt die Liste seit der ersten Ausgabe an und bleibt die Klasse, für die es keine saubere Lösung gibt – sondern nur eine mehrschichtige Eindämmung.
• Die Ausgabe 2025 umfasst Prompt Injection, Offenlegung sensibler Informationen, Lieferkette, Daten- und Modell-Poisoning, unsachgemäße Ausgabebehandlung, übermäßige Handlungsbefugnis, System-Prompt-Leakage, Vektor- und Embedding-Schwächen, Fehlinformationen und unbegrenzten Ressourcenverbrauch. Die Liste wird regelmäßig überarbeitet. Prüfen Sie daher die aktuelle Ausgabe, anstatt sich auf eine veraltete Version zu verlassen.
• Einige Einträge wirken sich speziell auf Agenten aus: Übermäßige Handlungsbefugnis und unsachgemäße Ausgabebehandlung werden erst dann kritisch, wenn das Modell selbstständig agieren kann.
• Es handelt sich um eine Taxonomie, nicht um ein Kontrollset. Die Zuordnung eines Befunds zu LLM06 zeigt Ihnen, um welche Art von Problem es sich handelt, nicht aber, was Sie entwickeln müssen.
• Es ist die Lingua Franca des Fachbereichs: Sicherheitsüberprüfungen, Anbieterfragebögen und Bug-Reports beziehen sich alle darauf, weshalb es sich vor allem lohnt, sie namentlich und nach Nummern zu kennen.
• Das Abdecken der Liste stellt noch kein Sicherheitskonzept dar. Jeder Eintrag erfordert eine Sicherheitsmaßnahme (Control) in Ihrer Architektur, und ein Eintrag ohne Maßnahme ist ein akzeptiertes Risiko, unabhängig davon, ob dies schriftlich festgehalten wurde.

Kontrollen

Die Liste auf die eigene Architektur übertragen

Gleichen Sie jeden Eintrag mit Ihren tatsächlichen Eingaben, Tools, Datenspeichern und Ausgaben ab. Diese Übung ist wertvoller als die Liste selbst, da sie aufzeigt, welche Einträge nicht zutreffen und welche Angriffsflächen die Liste nicht nennt.

Einen Verantwortlichen und eine Sicherheitsmaßnahme pro Eintrag zuweisen

Jede anwendbare Klasse benötigt eine definierte Komponente, die sie eingrenzt, und eine Person, die diese Komponente pflegt. Ein Eintrag ohne Zuordnung ist eine Sicherheitslücke mit einer Referenznummer.

Prompt Injection als Schadensbegrenzung statt als Prävention behandeln

Für LLM01 gibt es keine zuverlässige Lösung auf der Modellebene. Die entscheidenden Maßnahmen sind Tools mit minimalen Rechten (Least Privilege), ausgehende Beschränkungen (Egress Restriction), Ausgabebehandlung und Freigabeprozesse für folgenschwere Aktionen.

Handlungsbefugnisse explizit einschränken

Schreiben Sie für LLM06 auf, was der Agent mit welchen Anmeldedaten und für welche Ziele tun darf – und setzen Sie dies unterhalb der Modellebene durch, anstatt im Prompt.

Modellausgaben als nicht vertrauenswürdige Eingaben behandeln

Für LLM05 gilt: Alles, was das Modell ausgibt und was einen Renderer, eine Shell, eine Abfrage oder ein anderes System erreicht, erfordert dieselbe Codierung und Validierung, die Sie bei Eingaben von Fremden anwenden würden.

Ressourcenverbrauch begrenzen

Für LLM10 verwandeln Ratenbegrenzungen (Rate Limits), Quoten und Timeouts einen Angriff auf Verfügbarkeit und Kosten in eine protokollierte Verweigerung. Dies ist der Eintrag, den Teams am häufigsten überspringen, weil er erst dann wie ein Sicherheitsproblem aussieht, wenn die Rechnung eintrifft.

Die Zuordnung erneut durchführen, wenn sich die Liste oder das Systemändert

Die Liste wird überarbeitet und Ihr Tool-Katalog wächst. Eine einmalig durchgeführte Zuordnung ist lediglich ein Dokument über ein System, das so nicht mehr existiert.

Checkliste

• 01Lesen Sie die aktuelle Ausgabe anstelle einer Zusammenfassung – einschließlich dieser hier.
• 02Erstellen Sie eine Zuordnungstabelle: Eintrag → Anwendbar? → Maßnahme → Verantwortlicher.
• 03Erfassen Sie jeden anwendbaren Eintrag ohne Maßnahme als akzeptiertes Risiko mit einer Begründung und einer kompensierenden Erkennungsmaßnahme.
• 04Schreiben Sie einen Test für jede Maßnahme und stellen Sie sicher, dass der Test fehlschlägt, bevor Sie ihm vertrauen.
• 05Prüfen Sie die Einträge, die erst im Zusammenspiel mit Tools gefährlich werden: übermäßige Handlungsbefugnis, unsachgemäße Ausgabebehandlung, Lieferkette.
• 06Stellen Sie sicher, dass Ratenbegrenzungen und Quoten existieren und korrekte Signale an ordnungsgemäß agierende Clients zurückgeben.
• 07Führen Sie die Zuordnung jedes Mal neu durch, wenn sich ein Tool, eine Datenquelle oder ein Autonomiegrad ändert.
• 08Verwenden Sie die Nummerierung der Liste in Ihren Befunden, damit Prüfer und Anbieter über dieselbe Klasse diskutieren.

Typische Fallstricke

• Die Liste als Compliance-Ziel behandeln: Zehn Überschriften abhaken, während die tatsächliche Architektur ungeprüft bleibt.
• Anzunehmen, dass die Sicherheitsvorkehrungen des Modellherstellers LLM01 abdecken. Sie reduzieren zwar die Versuche, aber die Konsequenzen tragen Sie weiterhin allein.
• Die Zuordnung auf Basis einer veralteten Ausgabe vornehmen. Die Liste wird überarbeitet, und eine alte Zuordnung deckt aktuelle Klassen unbemerkt nicht mehr ab.
• LLM10 überspringen, weil unbegrenzter Ressourcenverbrauch eher wie ein Betriebsproblem als ein Sicherheitsproblem aussieht.
• Das Benennen einer Klasse mit deren Beherrschung verwechseln. Eine ordentliche Zuordnungstabelle ohne Durchsetzung dokumentiert das Risiko lediglich, anstatt es zu verringern.

Beispiele

• Ein Agent, der Kunden-E-Mails zusammenfasst, lässt sich LLM01 (der E-Mail-Text ist eine nicht vertrauenswürdige Anweisungseingabe), LLM02 (die Zusammenfassung kann Daten enthalten, die der Anforderer nicht sehen darf) und LLM06 (das CRM-Tool macht aus einer Übernahme eine Aktion) zuordnen – drei Einträge aus einer einzigen Funktion, die jeweils eine andere Sicherheitsmaßnahme erfordern.
• Ein RAG-System über ein internes Wiki lässt sich LLM01 über indirekte Injection durch jeden Seiteneditor, LLM04, falls der Index manipuliert (poisoned) werden kann, und LLM08 für Abfragen, die Dokumente außerhalb der Berechtigungen des Anforderers zurückgeben, zuordnen.
• Ein öffentlicher MCP-Endpunkt lässt sich am ehesten LLM10 zuordnen: Nur-Lese-Zugriff, öffentliche Daten, sodass die Begrenzung des Ressourcenverbrauchs – Ratenbegrenzungen mit korrekten Headern – die eigentliche Arbeit leistet.

FAQs

Kann man mit den OWASP LLM Top 10 konform (compliant) sein?

Nein. Es ist ein Dokument zur Sensibilisierung und Klassifizierung, kein zertifizierbarer Standard. Es lässt sich ideal mit einem Managementsystem wie ISO 42001 oder einem Framework wie dem NIST AI RMF kombinieren, in denen die eigentlichen Governance-Verpflichtungen verankert sind.

Welche Einträge ändern sich am meisten, wenn man einem Modell Tools hinzufügt?

Übermäßige Handlungsbefugnis (Excessive Agency) und unsachgemäße Ausgabebehandlung (Improper Output Handling). Ohne Tools führen sie zu einer falschen Antwort; mit Tools führen sie zu einer Aktion, und der Schweregrad verschiebt sich von einer Peinlichkeit zu einem Sicherheitsvorfall.

Wie verhält es sich im Vergleich zu MITRE ATLAS?

Sie beantworten unterschiedliche Fragen. OWASP benennt die Schwachstellenklassen in Ihrer Anwendung; ATLAS katalogisiert die Taktiken und Techniken, die ein Angreifer gegen KI-Systeme einsetzt. Das eine ist eine Checkliste für Ihr Design, das andere eine Übersicht über das Playbook des Angreifers.

Referenzen

• OWASP — Top 10 for LLM Applications
• OWASP — LLM01: Prompt Injection
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• NIST — AI Risk Management Framework (AI RMF 1.0)

Verwandte Governance-Themen