OWASP LLM Top 10: Open-Source-Tools 2026 verglichen

Kurzantwort. Es gibt 2026 kein einzelnes OSS-Tool, das die OWASP LLM Top 10 vollständig abdeckt. Garak (NVIDIA) hat die breiteste Probe-Bibliothek für offensive Tests, Promptfoo das beste Entwickler-Workflow für CI-Integration, LLM Guard liefert Runtime-Sanitisation, inspect_ai (UK AISI) reproduzierbare Benchmarks, PyRIT (Microsoft) agentische Angriffsmuster. Wer LLM01 (Prompt Injection) abdecken will, kombiniert Garak und Promptfoo. Wer LLM02/LLM06 (Output Handling, Sensitive Information Disclosure) ergänzen will, fügt LLM Guard hinzu. Severity-Scoring und procurement-grade Reports liefert keines.

Dieser Artikel vergleicht die fünf relevantesten OSS-Optionen für Teams, die strukturierte LLM-Security-Tests in ihre Pipeline ziehen wollen. Stand der Daten in den Vergleichszellen: 2026-05-01. Wir nennen die Tools, was sie können, was sie strukturell nicht können — und am Ende, an welcher Stelle der Sprung zu einer Managed-Platform sich rechnet und an welcher nicht.

Welche Tools gehören in den Vergleich?

Die Auswahl folgt drei Kriterien: aktive Maintenance (mindestens ein Release in den letzten 12 Monaten), produktiver Einsatz in mindestens einem dokumentierten Engineering-Team, und Probe-/Test-Coverage für mindestens drei der OWASP-LLM-Top-10-Kategorien. Was hier fehlt — z. B. ältere Forschungs-Repos ohne Maintenance — ist nicht “schlecht”, sondern für CI-Integration nicht mehr tragfähig.

Jede Zelle ist mit dem jeweiligen GitHub-Repository verlinkt — die Aussagen lassen sich über README, Release-Notes und Commit-History dort verifizieren. Wir markieren bewusst keine Versionsnummern: alle fünf Projekte taggen häufig, und eine Aussage wie “ab v0.x.y” altert in Wochen.

Promptfoo — das Eval-Framework, das Red-Team wurde

Promptfoo startete als Output-Quality-Eval-Framework für LLM-Pipelines: YAML-Definitionen, Assertions auf Modell-Output, Vergleichs-Runs zwischen Provider und Modell. Über die letzten 18 Monate ist ein Red-Team-Plugin-Ökosystem dazugekommen, das Probes für Prompt Injection, Jailbreaks, Datenleakage und Tool-Call-Hijacking liefert. Die GitHub Action ist offiziell, der CLI-Exit-Code ist semantisch (0 = pass, 1 = fail) — beides Voraussetzung für eine ehrliche CI-Integration nach OWASP-LLM01-Muster.

Gotchas in der Praxis: Promptfoo ranked über Pass/Fail-Quoten, nicht über Severity. Ein erfolgreicher Exfiltrations-Bypass zählt strukturell gleich viel wie eine harmlose Refusal-Inkonsistenz — die Triage muss extern passieren. Das Red-Team-Plugin-Set ist breiter als alles andere im Promptfoo-Universum, aber jede Plugin-Quelle hat eigene Maintenance-Zyklen; Updates passieren asymmetrisch. Wer Promptfoo als CI-Backbone wählt, baut implizit ein Plugin-Inventar mit eigenem Pflegeaufwand auf.

Garak (NVIDIA) — die breiteste Probe-Bibliothek für offensives Testing

Garak ist von Anfang an als Red-Team-Scanner gebaut: Generators (Modell-Endpoints), Probes (Angriffe), Detectors (Erkennen von Treffern) und Buffs (Payload-Mutationen) als feste Pipeline. Die mitgelieferte Probe-Bibliothek deckt Jailbreaks, Encoding-Bypässe, Tool-Call-Hijacking, Prompt-Leakage und Generationskontamination ab. NVIDIA pflegt das Repository aktiv, neue Probe-Familien landen regelmässig — die Probe-Kataloge sind dokumentiert direkt im Repository.

Gotchas: Garak kennt keinen Continuous-Modus — jeder Run ist explizit, mit per-Run-Konfig. Wer nightly testen will, baut den Scheduler selbst (cron + Storage + Diff-Engine). Die Output-Logs sind JSONL pro Probe, ohne übergreifendes Severity-Schema; Befunde werden über externe Tools (oder per Hand) zu OWASP-Kategorien gemappt. Eine offizielle GitHub Action existiert nicht — der CLI-Exit-Code lässt sich aber im CI-Job einfach prüfen, das Wrapping ist Stunden, nicht Tage. Für Teams mit Marcus-Profil (siehe Persona unten) ist Garak die ehrlichste Antwort auf “ich will Probes, kein Marketing”.

LLM Guard (Protect AI) — Runtime-Guardrail, kein Offensive-Tool

LLM Guard ist konzeptionell ein anderes Werkzeug als die ersten beiden: kein Test-Runner, sondern eine Library, die im Produktions-Pfad zwischen Nutzer-Input und Modell (bzw. Modell-Output und Nutzer) eingehängt wird. Die Scanner — Prompt Injection Detector, Anonymisierung, Toxicity, Banned-Substrings, Code-Injection-Detection — laufen inline und blocken oder annotieren Requests/Responses. Das macht LLM Guard relevant für die Mitigation-Seite von LLM01 und LLM02/LLM06, nicht für Pre-Deploy-Testing.

Gotchas: Wer LLM Guard als “Sicherheits-Tool” einkauft und es nicht testet, hat dasselbe Problem wie jeder andere Klassifikator-basierte Schutz — Bypässe (Übersetzung, Encoding, Unicode-Confusables) werden nicht zuverlässig erfasst. LLM Guard gehört in die Production-Pipeline, nicht in die Probe-Toolchain. Sinnvolle Kombination: Garak/Promptfoo testen kontinuierlich gegen den geschützten Endpoint, LLM Guard ist die Schicht, die getestet wird. Wer das umdreht, misst die Klassifikatoren statt das Modell.

inspect_ai (UK AISI) — akademisch reproduzierbar, produktiv plumbing-arm

inspect_ai ist ein Eval-Framework, das vom UK AI Safety Institute entwickelt wurde. Es liefert das Pattern (Tasks, Solvers, Scorers) und ein CLI, mit dem sich Benchmark-Suites in Python definieren und reproduzierbar ausführen lassen. Für Forschungs- und Benchmark-Arbeit — “wie verhält sich Modell X auf Suite Y” — ist es exzellent: explizite Trace-Logs, deterministische Konfigurationen, sauberes Score-Reporting. Das Repository wird aktiv gepflegt.

Gotchas: inspect_ai ist kein Probe-Set. Wer es für Prompt-Injection-Testing einsetzt, schreibt die Probes selbst oder zieht sie aus inspect_evals (das Companion-Repository mit kuratierten Tasks). Out-of-the-box gibt es keine Garak-äquivalente Bibliothek mitgelieferter Angriffe. Sinnvoller Use-Case: ein internes Sicherheits-Benchmark, das du ein-, zweimal pro Quartal gegen alle deine Modell-Versionen fährst und in den Audit-Anhang legst. Für nightly CI-Probing ist Garak/Promptfoo praktischer; für eine reproduzierbare jährliche Standortbestimmung ist inspect_ai sauberer.

PyRIT (Microsoft) — agentisches Red-Teaming als Framework

PyRIT (Python Risk Identification Toolkit) ist Microsofts Ansatz, automatisiertes Red-Teaming als Framework zu liefern: Orchestrators steuern Multi-Turn-Angriffe, Converters mutieren Payloads (Übersetzung, Base64, Tone-Shifting), Scorers bewerten die Antwort — oft selbst per LLM-as-Judge. Damit deckt PyRIT eine Klasse von Angriffen ab, die statische Probe-Bibliotheken nicht abdecken: Multi-Turn-Jailbreaks, agentische Tool-Call-Manipulation, kontextuelle Eskalation. Das Repository ist aktiv gepflegt.

Gotchas: PyRIT ist ein Framework, kein Out-of-the-box-Scanner. Es zu produktiv zu nutzen heisst Python schreiben — Orchestrator-Konfig, Scorer-Auswahl, Memory-Backend, Modell-Credentials. Die Lernkurve ist steiler als bei Garak oder Promptfoo. Wer agentische Angriffsmuster systematisch will (z. B. für Tool-Call-Hijacking auf Function-Calling-Endpoints), bekommt mit PyRIT mehr als mit allen anderen vier Tools zusammen — aber bezahlt mit Engineering-Zeit. Für ein zweiköpfiges AppSec-Team ohne dedizierten ML-Engineer ist es die falsche erste Wahl.

Welches Tool deckt welche OWASP-LLM-Kategorie ab?

Eine ehrliche Mapping-Aussage, ohne Punktwertung — die Probe-Tiefe pro Kategorie variiert stark zwischen Tools:

• LLM01 (Prompt Injection): Garak (breit), Promptfoo (Plugin), PyRIT (agentisch), inspect_ai (mit eigenem Probe-Code), LLM Guard (nur Detect, kein Probe)
• LLM02 (Insecure Output Handling): Promptfoo (Assertions), Garak (Detector-Layer), LLM Guard (Output-Scanner)
• LLM03 (Training Data Poisoning): Out-of-Scope für alle fünf — das ist eine Pre-Training-Frage
• LLM04 (Model DoS): Keine echten Probes; Last-Tests sind separates Tooling
• LLM05 (Supply Chain): Out-of-Scope für alle fünf — SBOM-Tooling, kein LLM-Tool
• LLM06 (Sensitive Information Disclosure): Garak, Promptfoo, LLM Guard
• LLM07 (Insecure Plugin Design / Tool-Call): Garak (partiell), PyRIT (am stärksten), Promptfoo (Plugin)
• LLM08 (Excessive Agency): PyRIT (agentische Tests), sonst kaum
• LLM09 (Overreliance): Eher UX-/Process-Frage, kein Probe-Thema
• LLM10 (Model Theft): Garak (Extraction-Probes partiell), sonst nichts

Die ehrliche Folgerung: kein einzelnes Tool deckt mehr als sechs der zehn Kategorien wirklich ab — und die fehlenden vier (LLM03, LLM04, LLM05, LLM09) sind keine Probe-Themen, sondern Process-/Supply-Chain-/UX-Themen. Wer “100 % OWASP-Coverage” verspricht, verkauft Marketing.

Wann reicht OSS, wann braucht man eine Platform?

Die Antwort ist für die meisten Teams sequentiell, nicht binär: man fängt mit OSS an, kommt damit überraschend weit, und stösst an einer von drei Wänden an, an der eine Managed-Platform sich rechnet.

OSS reicht für: Engineering-Teams in Pre-Audit-Phase, Internal-Tools ohne externe Compliance-Anforderung, Modell-Vergleichs-Benchmarks, einmalige Pre-Launch-Sicherheits-Reviews. Kombiniert man Garak (offensiv) + Promptfoo (CI) + LLM Guard (Runtime) + inspect_ai (Benchmark), hat man für den nominellen Engineering-Aufwand von ein bis zwei Wochen Setup und ein bis zwei Tagen pro Quartal Pflege ein technisch ehrliches Sicherheits-Bild. Das ist mehr, als die meisten Series-A-Companies aktuell haben.

Eine Managed-Platform rechnet sich, sobald (a) Procurement, SOC 2 oder ISO 42001 ein signiertes Evidence-PDF mit OWASP-Severity-Scoring pro Befund verlangen — siehe reproduzierbare Test-Kataloge mit Provenance als notwendige Vorstufe; (b) mehr als zwei Personen Befunde triagieren und ein gemeinsames UI brauchen; (c) Continuous-Scanning gegen mehrere Modell-Endpoints zur SLA-Pflicht wird und der Self-Hosting-Aufwand für Scheduler, Storage, Diff-Engine und Notification-Layer den Subscription-Preis übersteigt. PromptShield besetzt genau diese Schicht — managed Continuous-Scanning auf Basis derselben offenen Probe-Konzepte plus signiertes Evidence-PDF. Wer die drei Indikatoren oben nicht erfüllt, fährt mit der OSS-Kombination billiger.

Die ehrliche Empfehlung an Teams, die heute starten: Promptfoo oder Garak in die CI, LLM Guard inline in Production, vier Wochen Daten sammeln, dann anhand realer Befund-Volumen entscheiden. Tooling-Entscheidungen vor Daten sind Lotterie.

Weiterlesen

• Praktische Pipeline-Integration: OWASP LLM01 in der CI-Pipeline absichern
• Test-Reproduzierbarkeit als Audit-Voraussetzung: Reproduzierbare Prompt-Injection-Tests: Katalog und Provenance
• Die strukturell schwierigste Kategorie: Indirekte Prompt Injection: Warum die RAG-Pipeline das schwächste Glied ist
• Audit-Output-Anforderungen: Pentest-Reports als signiertes Evidence-PDF