Bugonomics: Finden ist billig, Fixen ist teuer

Im Januar 2026 hat das curl-Projekt sein Bug-Bounty-Programm abgeschaltet. Der Grund war die übliche Klage: zu viel maschinell erzeugter Müll, zu wenig Substanz. Die Quote bestätigter Lücken war von über 15 Prozent auf unter 5 Prozent gefallen. Über die gesamte Laufzeit hatte das Programm 87 echte Schwachstellen eingebracht und über 100.000 US-Dollar an Prämien gekostet. Zum 31.01.2026 war Schluss damit.

Danach kam noch ein Umweg. Mit dem Bounty-Ende wanderte die Meldestelle zu GitHub, was sich als Fehlgriff erwies, und seit dem 01.03.2026 läuft sie wieder über HackerOne, nur eben ohne Geld.

Von da an drehte sich das Bild. Drei Monate nach dem Bounty-Ende schrieb Daniel Stenberg, der curl seit 1998 pflegt, einen Nachtrag, der die interessantere Nachricht enthält: "The slop situation is not a problem anymore." Das Müllproblem hatte sich erledigt. Stattdessen lag die Bestätigungsquote wieder bei 15 bis 16 Prozent, so hoch wie vor dem KI-Zeitalter. Und die Meldungen kamen doppelt so häufig wie im Vorjahr, das selbst schon doppelt so viele gebracht hatte wie die Jahre davor.

Das ist die Wendung, um die es hier geht. Nicht mehr die schlechten Meldungen machen die Arbeit. Es sind die guten.

Die Zahlen von curl

curl veröffentlicht seine Schwachstellendaten maschinenlesbar. Wer sie sich ansieht, findet Folgendes (Stand 01.09.2026):

Der bisherige Jahresrekord in der 28-jährigen Geschichte des Projekts lag bei 24, aufgestellt 2016. Der ist mit vier Monaten Restlaufzeit bereits um die Hälfte übertroffen.Stenbergs Schätzung vom April, das Jahr könne auf knapp 50 zulaufen, sieht aus heutiger Sicht eher konservativ aus.

Ein Detail, das gegen den Alarmismus hilft: Der Schweregrad hat sich dabei nicht verschoben. Alle 36 Einträge aus 2026 sind als niedrig oder mittel eingestuft, wie schon in den beiden Vorjahren. Auf das Vierfache gewachsen ist also die Arbeit. Der Gefahrengrad blieb, wo er war.

Was "Bugonomics" heißt

Für diese Verschiebung gibt es inzwischen einen Begriff. Alfredo Pesoli, Herman Errico und Lorenzo Cavallaro haben im Mai 2026 eine Arbeit veröffentlicht, die Schwachstellenforschung konsequent als Wirtschaftsfrage betrachtet: Was kostet es, eine Lücke zu produzieren, zu belegen, zu priorisieren und zu schließen?

Die Antwort ist unbequem, weil sie eine bequeme Annahme kippt. Jahrelang war die teure Seite das Finden. Ein brauchbarer Zero-Day war Spezialistenarbeit für Regierungen, Broker und Exploit-Händler. Diese Seite ist jetzt billig geworden. Die andere nicht.

Der Kernsatz der Arbeit: "The resulting bottleneck is not only finding more bugs; it is absorbing, validating, triaging, patching, and shipping a larger stream of reports." Der Engpass liegt demnach nicht allein beim Finden. Er liegt beim Aufnehmen, Prüfen, Einsortieren, Patchen und Ausliefern eines größeren Meldungsstroms.

Besonders deutlich wird das laut den Autoren im Open-Source-Bereich, weil dort die Kapazität für Validierung, Triage, Finanzierung und Releases nicht mitwächst.

Warum Beheben so viel teurer ist

Der Grund ist strukturell. Finden ist ein Schritt, und diesen Schritt kann man beliebig parallel laufen lassen. Beheben dagegen ist eine Kette. Fast jedes Glied darin braucht einen Menschen, der eine Entscheidung trifft.

flowchart TB
  A["Finden<br/>Modell scannt die Codebasis"] --> B["Triage<br/>Ist das echt?"]
  B --> C["Reproduktion<br/>Lässt es sich auslösen?"]
  C --> D["Bewertung<br/>Wie schlimm ist es wirklich?"]
  D --> E["Patch<br/>Fix ohne Regression"]
  E --> F["Release<br/>Version bauen und ausliefern"]
  F --> G["Advisory<br/>CVE, Kommunikation, Backports"]
  G --> H["Update kommt beim Nutzer an"]
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC
  class B,C,D,E,F,G decision
  class H success

Wie teuer diese Kette ist, lässt sich an einem gut dokumentierten Fall ablesen. Anthropic hat Anfang 2026 mit Mozilla zusammengearbeitet und Claude Opus 4.6 auf Firefox angesetzt. Die erste Lücke, ein Use-after-free in der JavaScript-Engine, fand das Modell nach zwanzig Minuten. Am Ende waren knapp 6.000 C++-Dateien gescannt und 112 Meldungen eingereicht. Daraus wurden 22 bestätigte Schwachstellen, 14 davon von Mozilla als schwerwiegend eingestuft.

112 rein, 22 raus. Die anderen 90 waren kein Sicherheitsproblem, mussten aber trotzdem angesehen werden. Das ist ausdrücklich kein Vorwurf an Anthropic, im Gegenteil: Mozilla hatte selbst darum gebeten, alles ungefiltert zu schicken, statt vorzufiltern. Aber es zeigt, wo die Rechnung anfällt. Billig war der Fund. Die Sortierung nicht.

Ein zweites Zahlenpaar aus demselben Projekt ist beruhigender: Aus den gefundenen Lücken einen funktionierenden Exploit zu bauen, gelang in nur zwei von mehreren hundert Versuchen, bei rund 4.000 US-Dollar API-Kosten. Finden ist billig, Ausnutzen ist es noch nicht. Dieses Zeitfenster steht Verteidigern offen, und Anthropic schreibt selbst dazu, man solle es nutzen.

Was wir selbst dabei beobachten

Wir sind an dieser Stelle nicht neutral. Mit KIberschutz melden wir seit Juni 2026 selbst Sicherheitslücken an Open-Source-Projekte. Der Stand am 01.09.2026: 13 Projekte analysiert, 2,6 Millionen Zeilen Code, 95 Funde gemeldet. Davon sind 60 abgeschlossen, 55 wurden gefixt, 5 als "so gewollt" zurückgewiesen.

Interessanter als der Durchschnitt ist die Verteilung. Sie zerfällt in zwei klar getrennte Gruppen. Die dritte Spalte zählt Funde, die im Code repariert sind, auch wenn das Release noch aussteht:

Zwischen "am nächsten Tag" und "gar nicht" liegt fast nichts. Über alle behobenen Funde hinweg liegt der Median bei einem Tag. Gleichzeitig sind 35 der 95 Meldungen noch offen, und 29 davon hat bisher niemand angefasst, seit 25 bis 39 Tagen. Bei einem einzelnen Projekt liegen 12 Advisories, darunter drei kritische, seit dem 25.07.2026. Eine erste inhaltliche Rückmeldung kam dort erst, nachdem wir Ende August nachgefasst hatten.

Das ist der praktisch wichtigste Befund aus unseren eigenen Daten: Die Frage ist nicht, wie schnell ein Projekt fixt, sondern ob überhaupt jemand am anderen Ende sitzt. Mit technischer Schwierigkeit lassen sich die Unterschiede in der Tabelle nicht erklären. Die Funde beim Ticketing-Tool waren keinen Deut einfacher als die bei der Wissensplattform. Der Unterschied ist Kapazität.

Warum in der Tabelle keine Namen stehen: Wer reagiert hat, taucht auf unserer KIberschutz-Seite mit Namen auf, sobald die Fixes veröffentlicht sind. Wer noch offene Lücken hat, bleibt anonym, bis sie geschlossen sind. Die drei Projekte am Ende der Tabelle haben wir deshalb zu einer Zeile zusammengefasst. Namen nennen wir, wenn das Problem weg ist. Solange es offen steht, hilft ein Pranger niemandem und den Nutzern am wenigsten.

Der ehrliche Teil: Auch gute Melder liegen falsch

Zwei Vorgänge aus unseren eigenen Daten gehören hier hin, weil sie die Kostenrechnung vervollständigen. Beide betreffen denselben Maintainer beim Datei-Sync-Server, innerhalb von zwei Tagen.

Am 07.08.2026 wies er eines unserer Advisories als nicht reproduzierbar zurück, und er hatte recht: Unser Proof of Concept hatte eine Bereinigungsfunktion im Code übersehen. Die Lücke selbst gab es trotzdem, wir haben mit korrigiertem Nachweis nachgelegt, danach wurde sie gefixt. Einen Tag später widersprach er einem zweiten Advisory mit fünf sachlichen Korrekturen. Wir haben alle fünf gegen den Code geprüft, und alle fünf trafen zu. Eine Behauptung zur TLS-Absicherung mussten wir zurückziehen, die Einstufung ging von mittel auf niedrig runter.

Wir arbeiten mit verifizierten Funden, schreiben Patches dazu und prüfen jeden Befund adversarial gegen. Trotzdem passiert das. Jede dieser Korrekturen hat den Maintainer Zeit gekostet, die er nicht für den eigentlichen Fix hatte. Beim Melden übersieht man diesen Punkt leicht: Auch eine sorgfältige Meldung verursacht Kosten auf der anderen Seite, und sie werden nicht kleiner, nur weil man es gut meint.

Was das für euch heißt

Wenn ihr selbst Lücken meldet

Die drei Dinge, die Mozillas Sicherheitsteam an den Meldungen aus dem Firefox-Projekt als entscheidend genannt hat, sind eine brauchbare Mindestanforderung für jede Meldung:

1. Ein minimaler Testfall, der das Problem auslöst
2. Ein nachvollziehbarer Beleg für die tatsächliche Auswirkung
3. Ein Patch-Vorschlag

Anthropic formuliert die Begründung dafür in einem Satz, der die ganze Lage zusammenfasst: "we know that maintainers are underwater." Wer meldet, sollte die Arbeit auf der teuren Seite der Kette übernehmen, nicht nur auf der billigen.

Dazu gehört ein Punkt, der seltener ausgesprochen wird: Eine Meldung, die man nicht selbst verifiziert hat, hilft niemandem. Sie reicht die Arbeit nur weiter. Das gilt auch dann, wenn das Modell sehr überzeugend klingt.

Fazit

Die Ökonomie hat sich gedreht. Was jahrelang das Teure war, das Finden von Schwachstellen, kostet heute wenig. Was immer schon unsichtbar war, das Prüfen, Patchen und Ausliefern, ist zum Engpass geworden. curls Zahlen zeigen das im Einzelfall, die Arbeit von Pesoli und Kollegen erklärt es strukturell, und unsere eigenen 95 Funde bestätigen es in einer Härte, die uns selbst überrascht hat.

Die daraus folgende Handlungsanweisung ist unspektakulär und deshalb leicht zu übersehen. Wer Software auswählt, sollte darauf schauen, ob dort jemand sitzt, der Meldungen bearbeitet. Wie wenige davon bisher aufgelaufen sind, sagt für sich genommen wenig. Für die eigene Software zählt die Kapazität, die man fest einplant. Und beim Melden zählt, wie viel Arbeit man abnimmt statt weiterzugeben.

Stenberg beschreibt in seinem Beitrag, worauf das ohne Gegenmaßnahmen hinausläuft: "This avalanche is going to make maintainer overload even worse." Ob daraus eine Lawine oder ein Sicherheitsgewinn wird, entscheidet sich nicht beim Finden. Es entscheidet sich danach.