Automatisierter Müll ist auch ein Sicherheitsproblem

KI beschleunigt Angriffe. Das bleibt richtig.

Aber der Satz ist zu klein. Dieselben Werkzeuge, die Reconnaissance, Exploit-Variation und Phishing billiger machen, machen auch schlechte Sicherheitsmeldungen billig. Node.js, curl und OpenSSF zeigen gerade, was dann passiert: Nicht nur Angreifer skalieren. Auch Müll skaliert.

Das ist kein Randproblem und kein Maintainer-Gejammer. Wer Vulnerability Disclosure, Bug Bounty und Security-Triage mit automatisch erzeugten Reports flutet, greift eine knappe Ressource an: die Zeit der Menschen, die echte Schwachstellen von Unsinn unterscheiden können.

Diese Zeit ist Teil des Sicherheitsmodells.

Der Node.js-Fall ist nur der aktuelle Aufhänger

Heise berichtete am 6. Juli über eine Diskussion in der Node.js-Community. Der wichtigere Teil steht in den öffentlichen TSC-Issues des Projekts.

In nodejs/TSC#1826 beschreibt Rafael Gonzaga, dass Node.js in den vorherigen sechs Monaten einen deutlichen Anstieg bei Contributions und HackerOne-Reports gesehen habe. Seine Einordnung ist klar: Der Anstieg sei aus seiner Sicht weitgehend KI-getrieben. Contributors nutzten LLMs zum Fuzzing und Scannen der Codebasis; die eingehenden Reports seien auffällig ähnlich und deuteten auf gleiche oder ähnliche Tooling-Ketten hin.

Node.js hatte bereits gegengesteuert:

höhere Signal-Anforderungen für HackerOne-Reports
ein erweitertes Threat Model mit klareren Scope-Grenzen
automatisches Schließen von Reports, die die Anforderungen nicht erfüllen

Das Problem war damit nicht erledigt. Gonzaga schreibt, dass automatisch geschlossene Reports wegen zu wenig Signal nun bei der OpenJS-CNA-Mailadresse und im Eskalationspfad landeten. Anders gesagt: Ein Eingang wurde enger gemacht, also läuft der Abfluss woanders über.

Genau hier wird aus Ärger ein Sicherheitsproblem. Automatisierter Müll verschwindet nicht durch Formularlogik. Er sucht sich den nächsten Prozess.

Triage ist keine Müllpresse

Ein Security-Report ist nicht wertvoll, weil er lang ist. Er ist wertvoll, wenn er eine reale, reproduzierbare und relevante Schwachstelle beschreibt.

Vor einer belastbaren Entscheidung müssen Maintainer prüfen:

Ist der Fall überhaupt im Scope?
Ist der Befund reproduzierbar?
Ist es ein Bug oder eine Vulnerability?
Gibt es realistischen Impact?
Betrifft es unterstützte Versionen?
Ist es ein Duplikat?
Muss etwas embargoed werden?
Braucht es einen Security Release?

Das ist keine Bürokratie. Das ist Verteidigung.

Wer diese Arbeit mit halbgaren Reports füllt, verschiebt Security-Arbeit weg von echten Risiken und hin zu Müllsortierung. Bei Open Source trifft das selten eine große bezahlte Triage-Abteilung. Es trifft Maintainer, Security Teams und Projektverantwortliche, die ohnehin schon zu wenig Zeit haben.

Die harte Wahrheit: Ein schlechter Report ist nicht neutral. Er verbraucht Aufmerksamkeit. Er erhöht Unsicherheit. Er kann echte Arbeit verdrängen.

KI gegen KI löst nicht automatisch das Problem

In nodejs/TSC#1858 wird AI-assisted HackerOne-Triage diskutiert. Das vorgeschlagene Werkzeug soll einen eingehenden H1-Report nehmen, eine verwundbare Umgebung auf AWS starten, den beschriebenen Exploit ausführen und ein Triage-Verdikt zurückgeben.

Das kann sinnvoll sein. Bei hohem Volumen wird kein ernsthaftes Projekt dauerhaft ohne Automatisierung auskommen.

Aber man sollte sich nichts vormachen: Das ist kein sauberer Sieg der Automatisierung. Es ist ein Symptom. Automatisierte Reports erzeugen genug Last, dass Projekte automatisierte Systeme brauchen, um die automatisierten Reports überhaupt noch vorzusortieren.

Damit verschwindet die Sicherheitsfrage nicht. Sie wandert eine Ebene höher:

Wer überprüft das Triage-System?
Was passiert mit Grenzfällen?
Wie werden falsch verworfene echte Reports erkannt?
Wird das System selbst zum Orakel für Angreifer?
Wer trägt Verantwortung, wenn die Maschine falsch sortiert?

KI gegen KI ist keine Sicherheitsarchitektur. Es ist erst einmal ein Staubsauger im Maschinenraum. Nützlich, vielleicht notwendig, aber nicht dasselbe wie Ordnung.

curl zeigt die operative Härte

Der Node.js-Fall steht nicht allein. Bei curl beschreibt Daniel Stenberg seit Monaten sehr konkret, wie sich Security-Report-Druck anfühlt, wenn ein Projekt global kritische Infrastruktur ist.

curl ist kein Nebenprojekt, das zufällig etwas Aufmerksamkeit bekam. curl steckt in Servern, Produkten, Appliances, Betriebssystemen, Embedded-Geräten und Cloud-Diensten. Wenn dort Security Reports eingehen, kann das Projekt sie nicht einfach als lästige Kommentare behandeln.

In curl security moves again erklärt Stenberg, warum curl trotz abgeschaffter Bug-Bounty-Zahlungen wieder zu HackerOne als Report-Kanal zurückkehrt. Nicht wegen Liebe zur Plattform, sondern weil sichere, effiziente Vulnerability-Report-Infrastruktur ohne Bounty erstaunlich schwer ist.

Seine Wunschliste liest sich wie ein Betriebshandbuch für überlastete Security-Prozesse:

private Einreichung
spätere Veröffentlichung auch ungültiger Reports
klare Markierung gültig/ungültig
interne Team-Kommentare
eigene CVE-Felder für ein CNA-Projekt
Labels wie „AI slop“ für Statistik und Auswertung
Blockieren missbräuchlicher Nutzer
Rate Limits und Anforderungen an neue Accounts

Das ist keine Komfortausstattung. Das ist Schutzinfrastruktur.

Noch wichtiger ist sein späterer Text The pressure. Dort beschreibt Stenberg, dass sich die Lage seit den früheren KI-Slop-Problemen verändert habe: Es gehe inzwischen nicht nur um dumme LLM-Ausgaben, sondern um eine hohe Zahl detaillierter Reports. Die Rate eingehender Security Reports sei vier- bis fünfmal höher als 2024 und doppelt so hoch wie 2025. Im Durchschnitt komme mehr als ein Report pro Tag.

Das macht die Sache nicht harmloser, sondern härter. Schlechte Reports sind Gift. Gute Reports sind Arbeit. Viele gute Reports sind ebenfalls Druck. Und genau da liegt der Schaden der generischen KI-Reports: Sie konkurrieren mit den guten Reports um dieselbe Eingangsschlange.

Ein schlechter Report wird nicht nur selbst geschlossen. Vorher muss ihn jemand ansehen, verstehen, einordnen und oft widerlegen. Währenddessen liegt ein echter Report daneben und wartet. Der Müll ersetzt also nicht nur gute Arbeit. Er verzögert sie.

Jeder echte Fund verlangt Prüfung, Reproduktion, Bewertung, Patch, Versionsanalyse, Advisory, Kommunikation und oft Release-Planung. Security wird nicht dadurch kostenlos, dass ein Modell beim Finden geholfen hat.

Im Juli 2026 pausiert curl Vulnerability Reports deshalb für einen Monat. In curl summer of bliss steht schlicht: Während dieses Monats nimmt das Projekt keine Vulnerability Reports an und bearbeitet sie auch nicht über E-Mail.

Das ist kein PR-Stunt. Das ist ein Projekt, das Luft holen muss.

Das passt zur alten These: alte Security, schnelle Angreifer

Die bisherige Linie bleibt richtig: Alte Security trifft auf schnelle Angreifer. KI senkt Kosten für Reconnaissance, Code-Verständnis, Phishing, Exploit-Variation und operative Wiederholung. Wer dagegen mit langsamen, manuellen, schlecht integrierten Prozessen arbeitet, verliert Tempo.

Dieser Artikel ergänzt diese These, nicht ersetzt sie.

Denn dieselbe Kostenverschiebung trifft auch die Verteidigung. Nicht nur Angriffe werden billiger. Auch Pseudo-Arbeit wird billiger. Lange Reports. Plausibel klingende Impact-Abschnitte. Automatisch erzeugte PoC-Fragmente. Scanner-Funde mit Sicherheitsrhetorik. Alles sieht nach Arbeit aus. Nicht alles ist Arbeit.

Das ist gefährlich, weil Security-Prozesse oft auf gutem Glauben beruhen. Ein Report kommt rein, also schaut jemand drauf. Ein angeblicher Impact steht im Text, also muss ihn jemand widerlegen. Ein angeblicher PoC liegt bei, also muss ihn jemand ausführen, verstehen oder entkräften.

So entsteht ein hässlicher Effekt: Schlechte Automatisierung zwingt gute Leute zu manueller Gegenarbeit.

Private Disclosure wird schwieriger

Ein unbequemer Gedanke aus der Node.js-Diskussion ist besonders wichtig: Wenn ein allgemein verfügbares Modell oder Tooling denselben Befund jederzeit wiederfinden kann, ist der Befund nicht mehr im klassischen Sinn geheim.

Das ist kein Argument dafür, alles sofort öffentlich zu machen. Das wäre dumm. Es gibt echte Schwachstellen, echte Embargo-Gründe und echte Angreifer, die aus Details sehr schnell funktionierende Angriffe bauen.

Aber private Disclosure kann nicht mehr automatisch als echter Informationsschutz gelten. Manchmal schützt sie. Manchmal erzeugt sie vor allem Prozesslast. Und manchmal behandelt sie massenhaft reproduzierbare, schwach validierte Tool-Ausgaben wie seltene, handgefundene Geheimnisse.

Diese Unterscheidung wird zur Kernfrage: Was muss wirklich geschützt werden, und was blockiert nur das System?

Die Industrie hat das Problem verstanden, jedenfalls teilweise

Dass es nicht nur um genervte Einzelprojekte geht, zeigt die Reaktion rund um OpenSSF und Alpha-Omega. AWS, Anthropic, Google, Microsoft und OpenAI kündigten zusammen mit der Linux Foundation eine Finanzierung von 12,5 Millionen US-Dollar an, um Open-Source-Projekte beim Umgang mit KI-verstärkten und KI-generierten Vulnerability Reports zu unterstützen.

Der AWS-Text ist in einem Punkt bemerkenswert offen: Maintainer warnten, dass AI-generated bug reports ihre Review-Fähigkeit überlasten. Viele Reports seien sehr niedriger Qualität; der Begriff „AI slop“ wird ausdrücklich genannt.

Gleichzeitig hält der Text die zweite Seite fest: KI kann echte Schwachstellen schneller finden. Das ist der unangenehme Teil. Man kann die Werkzeuge nicht einfach aus der Security-Welt herausdefinieren. Sie produzieren Nutzen und Schaden mit derselben Skalierungslogik.

Die großen Anbieter finanzieren damit nicht nur bessere Verteidigung. Sie finanzieren auch die Aufräumarbeiten in einem Ökosystem, das ihre Werkzeuge mitbeschleunigen.

Das ist nicht verwerflich. Aber man sollte es auch nicht romantisieren.

Was Projekte jetzt brauchen

Ein pauschales Verbot KI-gestützter Reports wäre bequem und falsch. Ein Report ist nicht schlecht, weil ein Modell beteiligt war. Er ist schlecht, wenn der Einreicher ihn nicht versteht, nicht reproduzieren kann und den Impact nur ausformulieren lässt.

Projekte brauchen härtere Eingangsbedingungen:

klare Threat Models
enge Scope-Regeln
minimale Reproducer
betroffene Versionen und Konfigurationen
nachvollziehbare Impact-Erklärung
Duplikat-Erkennung
Rate Limits
Reputation oder Signal-Anforderungen
getrennte Pfade für Bugs und Vulnerabilities
schnelle Ablehnung schlechter Reports
belastbare Eskalation für echte schwere Fälle

Der letzte Punkt ist wichtig: Projekte brauchen das Recht, schlechte Reports schnell zu schließen. Ohne Gewissensdrama. Ohne zehn Runden pädagogischer Betreuung. Ohne die Fiktion, dass jeder automatisch erzeugte Absatz eine menschliche Antwort verdient.

Wenn Reports skaliert werden, muss Ablehnung ebenfalls skalieren. Sonst gewinnt nicht Qualität, sondern Volumen.

Automatisierter Müll ist ein Sicherheitsproblem

Ein guter Report reduziert Unsicherheit.

Ein schlechter Report erhöht sie.

Ein guter Report spart Maintainer-Zeit.

Ein schlechter Report verbrennt sie.

Ein guter Report macht ein Projekt sicherer.

Ein schlechter Report zwingt ein Projekt, sich zuerst gegen den Report selbst zu verteidigen.

Das ist die eigentliche Lehre aus Node.js, curl und der OpenSSF-Reaktion: KI verändert nicht nur die Angriffsgeschwindigkeit. Sie verändert die Kostenstruktur von Sicherheitsarbeit. Echte Analyse wird wertvoller, weil Pseudo-Analyse billiger wird.

Und wer Security-Prozesse mit billigem Müll füllt, schafft kein Sicherheitsniveau. Er schafft Lärm, Rückstau und schlechte Entscheidungen.

Das reicht als Urteil: Automatisierter Müll ist ein Sicherheitsproblem.