So sind diese Zahlen zu lesen
Precision
Von allen Alarmen, die der Scanner auslöst, der Anteil, der echte Schwachstellen sind. Niedrige Precision = viele Falsch-Positive zum Durchsortieren.
Vollständige Definition im Glossar ↗Recall
Von allen real existierenden Schwachstellen, der Anteil, den der Scanner tatsächlich findet. Niedriger Recall = echte Bugs werden übersehen — der gefährlichere Fehlerfall.
Vollständige Definition im Glossar ↗F1
Eine einzelne Zahl, die Precision und Recall kombiniert. Praktisch zum Vergleichen, verbirgt aber, welcher der beiden Werte den Score treibt — deshalb weist diese Seite beide getrennt aus, nicht nur den F1.
Vollständige Definition im Glossar ↗Fünf Methodiken, nicht eine Zahl
Eine einzelne „Genauigkeit"-Zahl bedeutet fast nichts, ohne zu wissen, wie sie gemessen wurde. Diese fünf liefern sehr unterschiedliche — und zunehmend ehrlichere — Ergebnisse:
Interne Fixtures
Führt jede Regel gegen ihre eigenen gepaarten Testfälle aus (eine verwundbare Datei, eine saubere Datei pro Regel) — 910 Fälle über alle 8 Sprachen. Das misst, ob die Regel-Engine noch das tut, wofür sie gebaut wurde; ein ausgereiftes Regelwerk sollte hier fast per Konstruktion nahe 100% erzielen. Nützlich als Regressionssignal, nicht als externer Beweis für irgendetwas.
OWASP Benchmark (Java + Python)
Eine unabhängige Drittanbieter-Testsuite (nicht von uns geschrieben) mit fester, veröffentlichter Ground Truth, vollständig für beide Sprachen ausgeführt. Schwerer und realistischer als selbstgeschriebene Fixtures — dieselbe Methodik, die Branchen-Benchmarking-Studien verwenden. Fast vollständig um Servlet/HTTP-artige Code-Muster herum aufgebaut.
NIST Juliet (Java)
Eine synthetische Testsuite der US-Regierung (NIST SARD), 6.616 Fälle über 6 zugeordnete CWE-Kategorien. Gleiche Sprache und weitgehend dieselben Schwachstellenklassen wie OWASP Benchmark Java, aber weit vielfältigere Quellcode-Idiome — Umgebungsvariablen, Property-Dateien, Sockets, Standardeingabe, URL-Verbindungen, nicht nur HTTP-Requests. Die Lücke zwischen diesem und OWASP Benchmark Java ist selbst das ehrlichste Signal auf dieser Seite.
CVE-Testsuite
Rekonstruiert aus 45 echten, historischen CVEs über 8 reale Frameworks (Django, Flask, Express, Spring, ASP.NET, Laravel, plus die Standardbibliotheken beider Sprachen). Der härteste Test: echter verwundbarer Code, so wie er tatsächlich ausgeliefert wurde, kein idealisierter Testfall.
Ergebnisse, heute ausgeführt
| Methodik | Fälle | Precision | Recall | F1 |
|---|---|---|---|---|
| Interne Fixtures (8 Sprachen) Selbstvalidierung |
910 | 100,0% | 100,0% | 100,0% |
| OWASP Benchmark (Java) unabhängig |
2.740 | 73,7% | 100,0% | 84,8% |
| NIST Juliet (Java) unabhängig |
6.616 | 98,4% | 46,7% | 63,3% |
| OWASP Benchmark (Python) unabhängig |
1.230 | 78,8% | 96,0% | 86,5% |
| CVE-Testsuite (5 Sprachen) reale Welt |
45 | 82,9% | 75,6% | 79,1% |
Der aufschlussreichste Vergleich auf dieser Seite ist Java gegen sich selbst: OWASP Benchmark Java zeigt 100,0% Recall, während NIST Juliet — gleiche Sprache, weitgehend dieselben CWE-Klassen, in derselben Woche ausgeführt — nur 46,7% zeigt. Das ist kein Widerspruch, das ist eine Diagnose. OWASP Benchmark ist fast vollständig um Servlet/HTTP-artigen Quellcode herum aufgebaut; Juliet testet auch Umgebungsvariablen, Property-Dateien, Sockets, Standardeingabe und URL-Verbindungen. Die Regel-Engine war genau auf das Muster kalibriert, das OWASP Benchmark belohnt, und Juliet hat diesen blinden Fleck aufgedeckt. Einen Teil dieser Lücke haben wir in diesem Zyklus bereits geschlossen (der Java-Recall bei Path Traversal und SQL-Injection hat sich nach der Erweiterung erkannter Taint-Quellen grob verdoppelt — siehe unten —, und die Precision hat sich kaum verändert: 98,2% → 98,4%), und die aktuellen Zahlen auf dieser Seite spiegeln diese Korrektur wider, nicht die vorherigen. Der Recall von OWASP Benchmark Python (96,0%) und der CVE-Testsuite (75,6%) liegt dazwischen, was selbst aufschlussreich ist: weder so eng gefasst wie OWASP Java, noch so breit wie Juliet. Identische Zahlen über alle fünf hinweg wären das Signal gewesen, dass etwas an der Methodik falsch war, nicht am Tool — eine so große Streuung mit einer benannten Ursache ist, wie ein ehrlicher Benchmark aussieht.
OWASP Benchmark Java, aufgeschlüsselt nach Kategorie
Der größte und härteste unabhängige Lauf — 2.740 Fälle, null falsch-negative Ergebnisse in jeder der 11 Kategorien, aber die Precision variiert stark je nach Kategorie. Schlechteste zuerst:
| Kategorie | Precision | Recall |
|---|---|---|
| XPath-Injection | 42,9% | 100,0% |
| LDAP-Injection | 45,8% | 100,0% |
| Command-Injection | 50,2% | 100,0% |
| SQL-Injection | 55,4% | 100,0% |
| Trust-Boundary-Verletzung | 65,9% | 100,0% |
| Path Traversal | 79,6% | 100,0% |
| Schwacher Hash | 79,6% | 100,0% |
| Schwache Kryptografie | 100,0% | 100,0% |
| Schwacher Zufall | 100,0% | 100,0% |
| XSS | 100,0% | 100,0% |
| Unsicheres Cookie | 100,0% | 100,0% |
Die ehrliche Lesart: Der Recall ist überall perfekt (jede platzierte Schwachstelle wird in jeder Kategorie erkannt), aber vier taint-lastige Kategorien — XPath-Injection, LDAP-Injection, Command-Injection, SQL-Injection — liegen unter 56% Precision, was bedeutet, dass die Regel-Engine bei diesen spezifischen Mustern in dieser synthetischen Suite überdetektiert. Die Prüfungen für schwache Kryptografie, schwachen Zufall, XSS und unsichere Cookies sind exakt (100%/100%). Das ist der reale aktuelle Trade-off: darauf abgestimmt, niemals eine platzierte Schwachstelle zu übersehen, auf Kosten von mehr Falsch-Positiven, als uns bei einer Handvoll Injection-Kategorien lieb ist.
NIST Juliet Java, aufgeschlüsselt nach Kategorie
Der größte Lauf auf dieser Seite — 6.616 Fälle über die 6 CWE-Kategorien, für die Juliet 1.3 tatsächlich Daten liefert (3 der ursprünglich geplanten 9 — XXE, schwacher Zufall, Zertifikatsvalidierung, Deserialisierung — haben in diesem NIST-Download keine Entsprechung). Schlechtester Recall zuerst:
| Kategorie | Precision | Recall |
|---|---|---|
| LDAP-Injection | 98,8% | 11,4% |
| Path Traversal (absolut) | 100,0% | 33,0% |
| SQL-Injection | 98,4% | 41,9% |
| Path Traversal (relativ) | 97,5% | 64,5% |
| Schwache Kryptografie | 100,0% | 89,5% |
| Command-Injection | 98,3% | 99,4% |
Die Precision bleibt überall hoch (97,5–100%) — die Regel-Engine schlägt selten grundlos Alarm —, aber der Recall variiert enorm, und der Grund ist architektonisch, nicht zufällig. Zwei von Juliets zwölf Quellcode-Varianten pro Kategorie (Daten gelesen über einen Datenbankaufruf, oder übergeben über eine „Flow-Variante" mit abstrakter Methode) leben in einer begleitenden Klassendatei, die der Einzeldatei-Scanner des Benchmarks nie sieht — diese Fälle sind unabhängig von der Regelqualität unerreichbar und ziehen die Obergrenze jeder Kategorie herunter. Innerhalb dessen, was tatsächlich erreichbar ist, ist LDAP-Injection der aktuelle Schwachpunkt: Juliets LDAP-Testfälle stützen sich auf Quellmuster (JNDI-Context-Lookups, gespeist aus Konfigurations-/Umgebungsdaten), die dieses Regelwerk noch nicht als Taint-Quellen erkennt, anders als die gerade erweiterten Path-Traversal- und SQL-Injection-Regeln. Das ist eine eingegrenzte, offengelegte Lücke, keine versteckte.
Interne Fixtures, aufgeschlüsselt nach Sprache (Selbstvalidierung)
Der interne Lauf mit 910 Fällen, nach Sprache — noch einmal: das misst interne Konsistenz, nicht externe Schwierigkeit, da jeder Fall eine Fixture ist, die für eine existierende Regel geschrieben wurde.
| Sprache | Verwundbare Fälle | Erkannt |
|---|---|---|
| Python | 144 | 144/144 |
| JavaScript/TypeScript | 84 | 84/84 |
| Java | 55 | 55/55 |
| HTML | 38 | 38/38 |
| YAML | 33 | 33/33 |
| PHP | 27 | 27/27 |
| C# | 25 | 25/25 |
| Sonstige (Dockerfile + generisch) | 10 | 10/10 |
CVE-Testsuite, aufgeschlüsselt nach Framework
Der härteste und realistischste Test — 45 Fälle, rekonstruiert aus echten, veröffentlichten CVEs — ehrlich aufgeschlüsselt, einschließlich der Stellen, an denen er versagt:
| Framework | Sprache | Precision | Recall |
|---|---|---|---|
| Flask | Python | 100,0% | 100,0% |
| Django | Python | 100,0% | 100,0% |
| Spring | Java | 87,5% | 70,0% |
| Laravel | PHP | 100,0% | 66,7% |
| PHP stdlib | PHP | 80,0% | 66,7% |
| Python stdlib | Python | 100,0% | 66,7% |
| Express | JavaScript | 72,7% | 80,0% |
| ASP.NET | C# | 66,7% | 66,7% |
Ehrlich offengelegte Schwachstelle: ASP.NET/C# und Express/JavaScript liegen in dieser Tabelle am niedrigsten — Precision und Recall im Bereich 66–80%. Historische CVEs wie log4shell-artige Deserialisierungsketten oder komplexe Multi-Hop-Taint-Pfade in diesen Frameworks sind genau die Fälle, die die Regel-Engine noch verpasst (die 11 falsch-negativen Ergebnisse enthalten CVE-2021-44228 selbst, als offene Lücke geführt, nicht verborgen).
Was diese Seite bewusst nicht enthält
- HTML, YAML und Dockerfile sind in keiner der obigen Tabellen enthalten. Das sind keine CWE-artigen Injection-Schwachstellenklassen wie SQL-Injection oder XSS — YAML-Regeln zielen auf CI/CD-Pipeline-Fehlkonfigurationen, Dockerfile-Regeln sind Hygiene-Prüfungen (Root-User, nicht fixiertes Basis-Image), architektonisch verschieden von einem Precision-/Recall-Benchmark rund um platzierte Schwachstellen. Siehe den CI/CD-Scan-Leitfaden für das, was dort tatsächlich erkannt wird.
- Die NIST-Juliet-Testsuiten für C/C++ und .NET/C# existieren und könnten diese Seite auf weitere Sprachen ausweiten — noch nicht eingebunden. Juliet Java selbst hat auch nur 6 seiner 112 CWE-Kategorien hier zugeordnet (siehe oben); die Abdeckung auf die übrigen 103 auszuweiten (viele davon ganz ohne entsprechende Regel, z.B. Integer-Overflow, Race Condition) ist zukünftige Arbeit, kein verborgenes Ergebnis.
Warum es auf dieser Seite keine Wettbewerber-Wertung gibt
Wir haben gesucht. Öffentliche OWASP-Benchmark-Zahlen existieren für einige Wettbewerber, stammen aber aus dem eigenen Marketinginhalt eines konkurrierenden Anbieters, und eine zweite gefundene Quelle für dasselbe Tool berichtet eine deutlich abweichende Zahl für denselben behaupteten Benchmark — ohne offengelegte Methodik, Testsuite-Version oder Tool-Version bei beiden. Das ist nichts, was wir als Fakt wiederholen wollen. Wenn ein Wettbewerber einen Benchmark-Score mit transparenter, reproduzierbarer Methodik veröffentlicht, zitieren wir ihn — genau wie der Rest dieser Seite Methodik und Datum zitiert. Bis dahin vergleicht diese Seite StaticCodeAudit mit der Realität, nicht mit nicht verifizierbaren Zahlen über andere Tools.
Diese Zahlen reproduzieren
Diese vier Methodiken laufen über interne Auswertungswerkzeuge, getrennt vom Quellcode des Produkts — NIST Juliet und OWASP Benchmark sind Testsuiten von Drittanbietern, kein von uns geschriebener Code, daher werden sie nicht mit dem Tool ausgeliefert. Das ist nichts, was Endnutzer im Alltag ausführen; es ist dasselbe Tooling, das die obigen Zahlen erzeugt hat, ausgeführt gegen dieselbe Regel-Engine.
run_benchmark.py owasp
run_benchmark.py owasp-python
run_benchmark.py cve
run_benchmark.py julietJeder Lauf exportiert eine datierte JSON-Datei mit der vollständigen Aufschlüsselung pro Kategorie — die Tabellen auf dieser Seite sind direkt aus diesen Exports übertragen, ausgeführt zwischen dem 7. und 9. August 2026 (die beiden größten Läufe, OWASP Benchmark Java und NIST Juliet Java, dauerten 3.551 bzw. 4.611 Sekunden — jeweils unter 1,5 Stunden — über 2.740 bzw. 6.616 Fälle).
Häufig gestellte Fragen
Warum zeigt der interne Fixture-Score 100%, wenn die anderen beiden das nicht tun?
Weil er etwas anderes misst. Interne Fixtures sind gepaarte Testfälle, die spezifisch für jede Regel geschrieben wurden — eine Regel, die ihren eigenen dafür entworfenen Testfall nicht erkennen könnte, wäre eine kaputte Regel, kein subtiler Fehltreffer. 100% dort bedeutet, dass die Regel-Engine keine offensichtlichen Regressionen hat, nicht dass die Erkennung in freier Wildbahn fehlerfrei ist. OWASP Benchmark und die CVE-Suite sind unabhängig vom Regel-Schreibprozess, weshalb ihre Zahlen niedriger und aussagekräftiger sind.
Ist eine Precision/Recall von 66–80% bei einigen CVE-Testsuite-Frameworks ein Problem?
Es ist eine echte, offengelegte Einschränkung, nichts zum Schönreden. Komplexe Multi-Hop-Taint-Flüsse und frameworkspezifische Deserialisierungs-Gadgets (die Art hinter CVE-2021-44228) sind für einen regelbasierten statischen Analyzer, kommerziell oder Open Source, tatsächlich schwer konsistent zu erfassen. Diese Seite existiert genau deshalb, damit diese Einschränkung sichtbar bleibt, statt unter einer einzigen aufgeblähten Schlagzeilenzahl begraben zu werden.
Warum liegt die OWASP-Benchmark-Java-Precision nur bei 73,7%, während der Recall ein perfekter 100% ist?
Weil die Regel-Engine aktuell darauf abgestimmt ist, niemals eine platzierte Schwachstelle zu übersehen, und das hat einen Preis: Vier Kategorien — XPath-Injection, LDAP-Injection, Command-Injection, SQL-Injection — liegen zwischen 43% und 55% Precision, was mehr Falsch-Positive bedeutet, als uns bei diesen spezifischen Taint-Mustern in dieser synthetischen Suite lieb ist. Die anderen sieben Kategorien, darunter XSS und schwache Kryptografie, sind exakt. Das ist eine echte, aktuelle Einschränkung, hier offengelegt statt unter einem aggregierten F1-Score geglättet.
OWASP Benchmark Java zeigt 100% Recall, aber NIST Juliet Java nur 46,7% — gleiche Sprache, ähnliche CWEs. Wer hat recht?
Beide, für das, was sie jeweils messen — und die Lücke zwischen beiden ist der eigentliche Befund. OWASP Benchmark ist fast vollständig um Servlet/HTTP-Quellmuster herum aufgebaut; Juliet nutzt auch Umgebungsvariablen, Property-Dateien, Sockets, Standardeingabe und URL-Verbindungen als Taint-Quellen. Die Regel-Engine war auf genau das Muster kalibriert, das OWASP Benchmark belohnt, und Juliet hat das aufgedeckt. Einen Teil davon haben wir bereits korrigiert — der Recall bei Path Traversal und SQL-Injection hat sich in diesem Zyklus nach Erweiterung der erkannten Taint-Quellen grob verdoppelt, bei praktisch unveränderter Precision (98,2% → 98,4%) —, und die aktuellen Zahlen auf dieser Seite spiegeln diese Korrektur wider, nicht die vorherigen. LDAP-Injection ist die nächste bekannte Lücke.
Die rohe Erkennungsausgabe selbst ansehen
Öffnen Sie den Live-Demo-Bericht — keine Installation, keine Anmeldung — und prüfen Sie echte Funde direkt.
Live-Bericht öffnen Unterstützte Sprachen ansehen