8. Warum AI-Reports im Bug-Bounty-Hunting meistens Müll sind

Planted March 14, 2026

Warum AI-Reports im Bug-Bounty-Hunting meistens Müll sind

Künstliche Intelligenz kann heute erstaunlich viel. Sie kann Quellcode analysieren, verdächtige Muster erkennen, mögliche Schwachstellen benennen und sogar direkt einen fertigen Vulnerability Report schreiben. Auf den ersten Blick klingt das wie der große Gamechanger für Bug Bounty Hunting: weniger manuelle Arbeit, mehr Findings, mehr Rewards.

In der Praxis sieht es aber oft ganz anders aus.

Mein Eindruck ist klar: AI-generierte Reports sind im Bug-Bounty-Kontext meistens Müll. Nicht, weil AI grundsätzlich nutzlos wäre. Sondern weil zwischen „da könnte etwas sein“ und einem validen, reproduzierbaren, impactstarken Sicherheitsreport ein gewaltiger Unterschied liegt. Genau an dieser Stelle scheitern die meisten AI-Reports.

AI findet Hinweise – aber keine echten Findings

Was AI ziemlich gut kann: Muster erkennen.

Sie findet fehlende Prüfungen, unsichere Funktionsaufrufe, auffällige Endpunkte, möglicherweise fehlende Autorisierungen, verdächtige Logik oder klassische Code-Smells. Gerade bei Open-Source-Projekten auf GitHub oder bei großen Codebasen kann das nützlich sein, um schnell Kandidaten für eine manuelle Prüfung zu bekommen.

Das Problem ist nur: Ein Hinweis ist noch keine Schwachstelle.

Im Bug Bounty zählt am Ende nicht, ob irgendein Modell im Code eine potenzielle Schwäche gesehen hat. Entscheidend ist:

• Ist das Verhalten tatsächlich ausnutzbar?
• Ist der Befund reproduzierbar?
• Gibt es einen realen Sicherheitsimpact?
• Fällt das Thema überhaupt in den Scope des Programms?
• Ist es mehr als nur statische Theorie?

Viele AI-Reports bleiben exakt auf dieser theoretischen Ebene stehen. Sie lesen sich dann überzeugend, technisch klingend und manchmal sogar professionell strukturiert — sind aber inhaltlich trotzdem wertlos.

Das Kernproblem: Statische Analyse ist nicht gleich Exploitability

Ein klassischer Fehler von AI ist, dass sie eine isolierte Stelle im Code bewertet, ohne den tatsächlichen Gesamtkontext der Anwendung sauber zu verstehen.

Gerade moderne Webanwendungen verteilen Sicherheitslogik über viele Ebenen:

• Routing
• Middleware
• Controller
• Service-Layer
• Policy-Checks
• Feature-Flags
• Backend-seitige Autorisierung
• Datenfilter
• Mandantenlogik
• Session-/Token-Kontext

Wenn eine AI an genau einer Stelle eine fehlende Authentifizierungs- oder Autorisierungsprüfung sieht, heißt das noch lange nicht, dass die Anwendung dadurch wirklich verwundbar ist.

Ein Beispiel aus meiner Praxis:

Eine AI hat bei mir eine Admin-Webseite als Broken Access Control eingestuft. Die Begründung: Die Seite war ohne vorgeschaltete Auth-Prüfung aufrufbar. Das stimmte sogar formal. Man konnte die URL tatsächlich direkt öffnen.

Klingt erstmal gut. Klingt reportbar. Klingt vielleicht sogar nach High.

Nur: Die Seite lieferte keinerlei sensible Daten zurück. Sie war faktisch leer, weil die eigentliche Autorisierungslogik an anderer Stelle griff. Die AuthZ-Prüfung saß also nicht dort, wo die AI sie erwartet hatte, sondern später im Ablauf. Ergebnis: kein Datenabfluss, keine Funktion nutzbar, kein Privilege Escalation, kein echter Schaden.

Die AI hat daraus trotzdem einen High-Severity-Report generiert.

Und genau das ist der Punkt: technisch auffälliges Muster, aber kein Impact. Damit ist der Report für ein Bug-Bounty-Programm im Grunde Müll.

Ohne Impact ist fast alles wertlos

Bug Bounty lebt nicht von theoretischer Unsicherheit, sondern von nachweisbarem Risiko.

Viele AI-Reports ignorieren diesen Grundsatz komplett. Sie beschreiben ein vermeintlich gefährliches Verhalten, leiten daraus aber automatisch eine hohe Severity ab, ohne die wichtigste Frage zu beantworten:

Was kann ein Angreifer damit konkret erreichen?

• Kann er Daten lesen?
• Kann er Daten verändern?
• Kann er Accounts übernehmen?
• Kann er Rechte eskalieren?
• Kann er interne Informationen exfiltrieren?
• Kann er eine sicherheitsrelevante Aktion ohne Berechtigung auslösen?

Wenn die Antwort im Ergebnis „nichts“ oder „fast nichts“ lautet, dann ist die Sache für die Praxis meist tot — selbst wenn im Code ein unsauberes Muster existiert.

Viele AI-Reports verwechseln deshalb:

• Code-Smell mit Schwachstelle
• ungewöhnliches Verhalten mit Security Impact
• potenziell interessant mit reportwürdig
• fehlende Prüfung an einer Stelle mit realem Broken Access Control

Das Ergebnis sind Reports, die vielleicht auf LinkedIn beeindruckend aussehen, aber beim Programm entweder direkt geschlossen oder als Informational ohne Wert abgelegt werden.

Reproduzierbarkeit schlägt schöne Formulierungen

Ein weiteres Problem: AI kann einen Report oft sprachlich sehr glatt formulieren, aber die eigentliche technische Substanz fehlt.

Ein guter BBH-Report braucht nicht nur eine Behauptung, sondern eine belastbare Kette:

• Ausgangssituation
• Voraussetzungen
• exakte Schritte zur Reproduktion
• Request/Response oder PoC
• beobachtetes Verhalten
• erwartetes Verhalten
• konkreter Sicherheitsimpact

AI produziert dagegen oft Reports, die eher wie „educated guesses“ aussehen. Also Berichte der Form:

This vulnerability may allow an attacker to…

It is possible that…

Under certain circumstances…

This could lead to…

Dieses could, may und might ist im Bug Bounty häufig ein Warnsignal. Natürlich darf man sauber und vorsichtig formulieren. Aber wenn der ganze Report nur aus Möglichkeiten besteht, ohne dass die Auswirkungen praktisch nachgewiesen wurden, ist er schwach.

Ein Report muss nicht literarisch gut sein. Er muss belastbar sein.

Severity wird von AI oft brutal überschätzt

AI neigt außerdem dazu, Findings dramatischer einzustufen, als sie tatsächlich sind.

Warum? Weil Modelle stark auf bekannte Schwachstellenklassen trainiert sind. Wenn irgendwo „fehlende Prüfung“, „Admin“, „ID“, „token“, „internal endpoint“ oder „authorization“ auftaucht, wird schnell eine schwere Kategorie angenommen. Der Kontext fehlt dabei oft völlig.

Das führt dann zu typischen Fehlbewertungen wie:

• „Admin page reachable“ = High
• „Internal endpoint exposed“ = Critical
• „ID parameter manipulable“ = High
• „Missing CSRF token“ = Medium oder High
• „Stack trace sichtbar“ = Medium

In der Praxis kann davon vieles am Ende Informational, Not Applicable, Won’t Fix oder schlicht kein Security Issue sein.

Severity ist eben nicht nur eine Frage des Bug-Typs, sondern der realen Auswirkung im konkreten System.

AI versteht oft nicht, was das Zielsystem wirklich macht

Ein Mensch prüft nicht nur eine Codezeile oder einen HTTP-Endpunkt. Er versucht zu verstehen:

• Welche Daten sind hier überhaupt relevant?
• Welche Rollen gibt es?
• Welche Geschäftslogik steht dahinter?
• Welche Schutzmechanismen greifen implizit?
• Welche Annahmen macht das System?
• Was wäre für das Programm tatsächlich schadensrelevant?

Genau dieses Zusammenspiel aus Technik, Anwendungskontext und Angreiferperspektive ist im BBH entscheidend.

AI fehlt hier oft das echte operative Verständnis. Sie sieht Struktur, aber nicht unbedingt Bedeutung. Dadurch entstehen Berichte, die oberflächlich plausibel wirken, aber am eigentlichen Ziel vorbeigehen.

Ein Bug-Bounty-Programm bezahlt nicht für „interessant aussehenden Code“. Es bezahlt für echte Sicherheitsprobleme mit nachvollziehbarem Risiko.

Das eigentliche Risiko: Spam und Qualitätsverlust

Ich glaube, das größte Problem an AI-Reports ist nicht einmal, dass sie falsch liegen. Das passiert Menschen auch.

Das größere Problem ist, dass AI die Hürde zum Erstellen von Reports massiv senkt. Dadurch entstehen sehr schnell viele mittelmäßige oder schlechte Einreichungen. Für Programme bedeutet das:

• mehr Triage-Aufwand
• mehr Rauschen
• mehr irrelevante Tickets
• mehr schlecht validierte Theoriefunde
• weniger Signal im Verhältnis zum Lärm

Und für Hunter bedeutet es langfristig ebenfalls nichts Gutes. Wer ungeprüfte AI-Funde einreicht, baut sich schnell einen Ruf für schwache Reports auf. Das ist im BBH kein Vorteil.

Ein einzelner sauber validierter Fund mit klarer Auswirkung ist am Ende mehr wert als zehn AI-generierte „maybe vulnerable“-Berichte.

Wo AI trotzdem nützlich sein kann

Trotz aller Kritik: AI ist nicht wertlos. Man sollte sie nur an der richtigen Stelle einsetzen.

Sinnvoll ist AI zum Beispiel für:

• erste Ideensammlung bei großen Codebasen
• Clustering verdächtiger Stellen
• Mustererkennung
• Hypothesenbildung
• Umformulieren eigener Notizen
• Strukturieren eines Reports nach der Validierung
• Generieren eines ersten Report-Entwurfs, den man anschließend technisch härtet

Mit anderen Worten: AI kann ein Assistent sein, aber kein Ersatz für Verifikation.

Die Reihenfolge sollte nie sein:

AI sieht etwas → AI schreibt Report → Report wird eingereicht

Sondern eher: AI liefert eine Hypothese → Mensch testet → Mensch prüft Impact → Mensch baut PoC → Mensch schreibt oder überarbeitet den Report

Erst dann wird aus einem vagen Hinweis ein echter Sicherheitsbefund.

Was einen guten BBH-Report wirklich ausmacht

Ein guter Report entsteht nicht dadurch, dass er professionell klingt. Er entsteht dadurch, dass er den Triage-Prozess überlebt.

Dazu gehören vor allem drei Dinge:

Erstens: Reproduzierbarkeit. Der Triage-Analyst muss das Verhalten nachvollziehen können.

Zweitens: Impact. Es muss klar sein, warum das Ganze sicherheitsrelevant ist.

Drittens: Kontextverständnis. Der Report muss zeigen, dass der Einreicher die Anwendung und die eigentliche Schwachstelle verstanden hat — nicht nur ein Pattern im Code.

Genau hier liefern Menschen derzeit noch deutlich bessere Ergebnisse als rein AI-generierte Reports.

Fazit

AI kann heute Code lesen, Auffälligkeiten markieren und Berichte formulieren. Das klingt beeindruckend, ersetzt aber nicht das, was im Bug Bounty wirklich zählt: Verifikation, Kontextverständnis und echter Impact.

Deshalb sind AI-Reports in BBH für mich in den meisten Fällen Müll — nicht weil die Technologie dumm wäre, sondern weil sie zu oft nur theoretische Schwächen beschreibt, die praktisch keine verwertbare Sicherheitsauswirkung haben.

Eine leere Admin-Seite ohne Datenabfluss ist kein High-Risk-Bug, nur weil ein Modell „Broken Access Control“ erkannt hat. Ein statischer Hinweis ist kein Fund. Und ein gut formulierter Report bleibt wertlos, wenn er keinen reproduzierbaren, relevanten Impact zeigt.

Wer AI im Bug Bounty sinnvoll nutzen will, sollte sie als Werkzeug für Hypothesen und Vorarbeit verstehen — nicht als autonome Schwachstellenmaschine.

Am Ende gilt weiterhin derselbe alte Grundsatz:

Nicht der schönste Report gewinnt, sondern der mit echtem, nachweisbarem Sicherheitswert.