KI hat das Finden von Bugs billig gemacht. Das Beheben ist jetzt der Engpass

Die Kosten der Entdeckung sind zusammengebrochen

Eine plausible Schwachstelle zu finden erforderte früher Können, Zeit und ein gutes Verständnis der Codebasis. Große Sprachmodelle haben den Großteil dieser Kosten beseitigt. Forschende und automatisierte Werkzeuge können heute in wenigen Stunden große Mengen an Kandidatenberichten gegen beliebte Open-Source-Projekte erzeugen. Das Problem ist, dass die Arbeit mit der Entdeckung nicht endet. Jemand muss das Problem noch reproduzieren, den Schweregrad einschätzen, einen Fix schreiben, ihn prüfen und an die Nutzer ausliefern. Keiner dieser Schritte ist billiger geworden.

Diese Asymmetrie zwingt Bug-Bounty-Programme, ihre Regeln zu ändern. curl hat sein Bug-Bounty-Programm im Januar 2026 ausgesetzt. Google hat sein Open-Source-Belohnungsprogramm im März 2026 verschärft und verlangt für bestimmte Auszahlungsstufen belastbarere Nachweise, etwa eine Reproduktion mit OSS-Fuzz oder einen zusammengeführten Patch. Google hat erklärt, dass viele KI-generierte Einreichungen erfundene Auslösebedingungen enthalten oder Fehler mit geringer tatsächlicher Sicherheitsrelevanz melden. Im April hat HackerOne die Auszahlungen des Internet Bug Bounty pausiert. Das Programm hatte seit 2012 mehr als 1,5 Millionen US-Dollar ausgezahlt und verteilte historisch rund 80 Prozent der Prämien auf neue Funde und 20 Prozent auf die Unterstützung bei der Behebung.

Die Erklärung von HackerOne ist die bislang deutlichste Beschreibung des Problems. Das Unternehmen sagte, KI-gestützte Forschung erweitere die Entdeckung von Schwachstellen im gesamten Ökosystem und steigere Abdeckung wie Geschwindigkeit, und das Gleichgewicht zwischen Funden und der Behebungskapazität in Open Source habe sich wesentlich verschoben. Node.js, eines der ersten betroffenen Projekte, nimmt Berichte weiterhin über HackerOne entgegen, zahlt dafür aber keine Prämien mehr.

Warum schlechte Berichte teuer sind

Ein falscher Bericht ist für den Empfänger nicht kostenlos. Der Maintainer muss ihn lesen, reproduzieren und erklären, warum er nicht funktioniert, oft in einem Thread voller höflicher, aber wenig hilfreicher Nachrichten. Beschreibt der Bericht einen Auslösepfad, den es nicht gibt, kann der Maintainer Stunden mit Code verbringen, der nie ausgeführt wird. Multipliziert man das mit Dutzenden Einreichungen, kann ein ehrenamtliches Team seine ganze Woche allein an der Triage verlieren. Berichte, die glaubwürdig wirken, aber falsch sind, kosten mehr als offensichtlich schlechte, weil man sie nicht auf einen Blick verwerfen kann.

Die Antwort der Programme war, die Beweislast zurück zum Meldenden zu verschieben. Eine Reproduktion mit einem Fuzzer, ein Proof of Concept, das auf der aktuellen Version läuft, oder ein Patch verlangt vom Meldenden einen Teil der Arbeit, die sonst beim Maintainer läge. Außerdem filtert das Einreichungen heraus, bei denen die Autorin oder der Autor den Code nie tatsächlich ausgeführt hat.

Warum das über Open Source hinaus wichtig ist

Die Einsätze sind nicht theoretisch. Der Verizon Data Breach Investigations Report 2026 ergab, dass inzwischen etwa 31 Prozent der Datenpannen auf der Ausnutzung von Softwareschwachstellen beruhen, nach etwa 20 Prozent im Vorjahr. In diesem Datensatz hat die Ausnutzung von Schwachstellen den Diebstahl von Zugangsdaten als häufigsten initialen Zugangsweg überholt. Der Großteil der Unternehmenssoftware baut auf Open-Source-Komponenten auf, daher wird ein Rückstand bei der Behebung im Upstream zu einem Rückstand in jedem nachgelagerten Produkt.

Die Berichterstattung über die Finanzierungslücke hat zudem das Ausmaß des Problems verdeutlicht. Berichten zufolge hat die Linux Foundation KI-Unternehmen um finanzielle Unterstützung gebeten, und Google, Anthropic, AWS, Microsoft und OpenAI haben zusammen 12,5 Millionen US-Dollar für Sicherheitsarbeit in Open Source zugesagt. Das ist eine bedeutende Summe, aber ein einmaliger Beitrag im Vergleich zur laufenden Pflege weit verbreiteter Bibliotheken.

Was sich ändern sollte

Der richtige Schritt ist, für den teuren Teil der Arbeit zu bezahlen. Entdecken ist jetzt billig; ein bestätigter Fix, der ausgeliefert wird, ist es nicht. Daraus folgen mehrere Änderungen.

• Maintainer sollten einen expliziten Nachweisstandard in ihre Sicherheitsrichtlinie schreiben. Berichte ohne Reproduktion, ohne fehlschlagenden Test und ohne Proof of Concept können automatisch geschlossen werden, mit einer kurzen Vorlage, die erklärt, was nötig ist. Die Einrichtung dauert Minuten und spart später Stunden.
• Maintainer sollten die Prüfung von Patches als budgetierte Tätigkeit behandeln. Hängt ein Projekt an Freiwilligen, sollte die Finanzierung die Prüfzeit abdecken, nicht nur Bounties für Berichte.
• Unternehmen, die auf Open-Source-Software setzen, sollten die Zeit bis zur Behebung messen, nicht die Zeit bis zur Meldung. Ein Sicherheitsteam, das zählt, wie viele Fälle es triagiert hat, optimiert auf Volumen. Ein Team, das verfolgt, wie lange eine Schwachstelle in seinen Abhängigkeiten ungepatcht bleibt, finanziert die Arbeit, die zählt.
• Bounty-Plattformen sollten für zusammengeführte Fixes mehr zahlen als für Berichte und erwägen, auch Reproduktionsartefakte vor Beginn der Triage zu vergüten.
• Forschende, die echte Fehler finden, sollten einen Patch zusammen mit dem Bericht einreichen. Ein Patch, der die Testsuite besteht, ist das Nützlichste, was eine meldende Person einem Maintainer geben kann.

Was das für Ihr Team bedeutet

Wenn Sie ein Produkt betreiben, das auf Open-Source-Komponenten aufbaut, beginnen Sie mit einer Liste der Upstream-Projekte, von denen Sie abhängen, und prüfen Sie, ob diese einen aktiven Sicherheitsprozess haben. Fordern Sie von Ihren Anbietern Service-Level für Patches, nicht nur Scan-Ergebnisse. Wenn eine Schwachstelle upstream gemeldet wird, bestimmt die Zeit bis zu einer behobenen Version Ihre Exposition, und diese Zeit hängt von der Kapazität der Maintainer ab, die Sie mitfinanzieren können.

Das Entdeckungsproblem wird nicht verschwinden, und das sollte es wahrscheinlich auch nicht. Mehr gefundene Bugs sind an sich kein Versagen. Versagen wäre, weiter den billigen Schritt zu belohnen, während der teure Schritt auf einigen erschöpften Freiwilligen lastet. Die Programme, die jetzt ihre Regeln ändern, versuchen, genau das zu korrigieren, und die Teams, die auf diese Software angewiesen sind, sollten ebenfalls aufmerksam sein.