KI-Slop überflutet Bug-Bounties: Open Source zieht Grenzen

Worum es geht

Open-Source-Maintainer bekommen seit 2025 immer häufiger Sicherheitsberichte, die offensichtlich oder mutmaßlich mit KI-Tools erzeugt wurden. Am 17. Mai 2026 schrieb Linus Torvalds laut dem öffentlich verlinkten LKML-Beitrag, die Linux-Sicherheitsliste sei durch doppelte und schwach geprüfte KI-Funde fast nicht mehr handhabbar. Help Net Security fasste den Vorgang am 18. Mai 2026 auf und ordnete ihn mit GitHubs neuen Bug-Bounty-Regeln ein.

Der Kern ist unbequem: KI kann echte Schwachstellen finden. Aber wenn Menschen die Ergebnisse ungeprüft weiterleiten, entsteht eine neue Form von Sicherheitslärm. Freiwillige Maintainer, Security-Teams und Bug-Bounty-Programme verlieren Zeit mit Reports, die keine reproduzierbare Ausnutzung, keinen konkreten Schaden und oft nicht einmal ein echtes Verständnis des Codes zeigen.

Was KI-Slop bei Sicherheitsreports tatsächlich macht

Ein KI-gestützter Sicherheitsreport beginnt oft mit einem Scanner, einem LLM oder einer Kombination aus beidem. Das Tool entdeckt verdächtige Muster, formuliert daraus eine plausible Schwachstellenbeschreibung und erzeugt manchmal lange Erklärungen, die professionell klingen. Genau dort liegt das Risiko: Der Text wirkt kompetent, auch wenn der Befund nicht validiert wurde.

GitHub beschreibt in seinen am 15. Mai 2026 veröffentlichten Regeln drei Mindestanforderungen: ein funktionierender Proof of Concept, ein klarer Bezug zum Programm-Scope und manuelle Validierung vor der Einreichung. OpenSSF sammelt parallel Best Practices, weil Open-Source-Projekte besonders betroffen sind. Sie haben oft keine bezahlten Triage-Teams, sondern wenige Menschen, die nebenbei Releases, Support und echte Sicherheitsprobleme bearbeiten.

Warum das wichtig ist

Sicherheitsmeldungen sind nur wertvoll, wenn sie die knappe Aufmerksamkeit der richtigen Leute verbessern. Wenn ein Projekt zehn echte Schwachstellen und hundert KI-Halluzinationen bekommt, wird nicht mehr Sicherheit erzeugt, sondern Stau. Curl beendete sein Bug-Bounty-Programm Ende Januar 2026 und verwies auf stark fallende Trefferquoten: Daniel Stenberg schrieb, 2025 sei die Quote bestätigter Schwachstellen auf unter fünf Prozent gefallen.

Für Unternehmen ist das ebenfalls relevant. Viele Software-Lieferketten hängen an freiwillig gepflegten Bibliotheken. Wenn Maintainer durch KI-Spam ausbrennen oder legitime Reports später sehen, steigt das Risiko für alle Nutzer dieser Komponenten. Das ist keine abstrakte Debatte über Tool-Ethik, sondern ein Kapazitätsproblem in der Sicherheitsinfrastruktur.

Einfach erklärt

Stell dir eine Feuerwehrleitstelle vor. Ein guter Hinweis sagt: In Straße X brennt es im dritten Stock, hier ist ein Foto, hier ist die Telefonnummer der Person vor Ort. KI-Slop ist eher wie hundert Anrufe mit: Vielleicht riecht es irgendwo nach Rauch, ich habe das in einer App gesehen. Auch wenn einer der Anrufe zufällig stimmt, muss die Leitstelle erst jeden einzelnen prüfen.

Bei Open Source passiert Ähnliches. Maintainer brauchen präzise, überprüfbare Hinweise. Lange, automatisch geschriebene Texte ohne Testfall sind keine Hilfe, sondern zusätzliche Arbeit.

Praktisches Beispiel

Ein kleines Open-Source-Projekt erhält an einem Wochenende 40 Sicherheitsreports. Acht davon behaupten, es gebe Remote Code Execution, aber keiner enthält einen lauffähigen Angriff. Zwölf melden bekannte Konfigurationspunkte, die laut Scope gar nicht bezahlt werden. Fünfzehn enthalten fast identische KI-Erklärungen zu theoretischen Risiken.

Wenn eine Maintainerin pro Report nur 20 Minuten braucht, sind das mehr als 13 Stunden Triage. In derselben Zeit könnte sie zwei echte Patches prüfen, eine Abhängigkeit aktualisieren oder ein Release vorbereiten. Für ein Unternehmen, das diese Bibliothek in 10.000 Installationen nutzt, ist der Unterschied direkt spürbar: weniger Lärm bedeutet schnellere Reaktion auf echte Schwachstellen.

Einordnung und Grenzen

Erstens ist KI nicht der Feind. GitHub schreibt ausdrücklich, dass KI in der Sicherheitsforschung willkommen ist, wenn Menschen die Ergebnisse reproduzieren und den Impact belegen.

Zweitens ist nicht jeder kurze oder schlecht formulierte Report wertlos. Manche echten Finder schreiben knapp, manche sprechen nicht perfekt Englisch, und Maintainer dürfen Qualität nicht mit perfektem Stil verwechseln.

Drittens gibt es keine verlässliche technische Erkennung für KI-generierte Reports. OpenSSF beschreibt die Erkennung selbst als schwierig. Deshalb funktionieren pauschale KI-Verbote schlecht; robuster sind klare Anforderungen: reproduzierbarer Testfall, Scope-Prüfung, Impact-Erklärung und knappe Belege.

SEO- und GEO-Schlüsselbegriffe

AI slop, KI-Sicherheitsreports, Bug Bounty, Open Source Security, Linux Kernel, Linus Torvalds, GitHub Security Lab, OpenSSF, HackerOne, curl, Vulnerability Disclosure, Proof of Concept