Nach Mythos: Warum Bug-Bounty-Programme jetzt härtere Beweise brauchen

Vor ein paar Wochen habe ich über Anthropic Mythos und Project Glasswing geschrieben. Damals ging es vor allem um die grosse Linie: Wenn Modelle wirklich besser darin werden, alte Schwachstellen zu finden, Exploit-Pfade zu kombinieren und ganze Codebasen zu verstehen, dann verändert das Vulnerability Research.

Der neue Sophos-Beitrag zu Bug-Bounties im Mythos-Zeitalter zeigt jetzt die operative Seite davon.

Es geht nicht mehr nur um die Frage, ob KI bessere Schwachstellen findet. Es geht darum, ob Bug-Bounty-Programme, Security-Teams und Engineering-Organisationen überhaupt schnell genug zwischen Müll, plausiblen Behauptungen und echten Sicherheitsproblemen unterscheiden können.

Das eigentliche Problem ist nicht nur KI-Slop

Bei KI und Bug-Bounties denkt man im Moment schnell an Slop: automatisch erzeugte Reports, halb verstandene Fehlermeldungen, erfundene Exploit-Ketten, nicht reproduzierbare Behauptungen und viel Text mit wenig Substanz.

Das ist real. Und es ist für Maintainer, Product-Security-Teams und Triage-Leute brutal nervig.

Aber es ist nur die eine Seite.

Die andere Seite ist gefährlicher: Gute Forscher können dieselben Modelle nutzen, um echte Schwachstellen schneller zu finden, Hypothesen über grössere Codebasen hinweg zu testen und Varianten eines Musters systematisch durchzugehen. Was früher Tage oder Wochen manuelle Arbeit brauchte, kann in Zukunft in Stunden in der Queue landen.

Damit verschiebt sich das Problem. Früher war oft die Frage: Bekommen wir genug gute externe Findings? Heute wird die Frage eher: Können wir die echten Findings schnell genug erkennen, validieren, priorisieren und in Fixes übersetzen, während gleichzeitig der Lärm steigt?

Warum Sophos hier eine interessante Quelle ist

Der Sophos-Artikel ist nicht nur ein generischer Kommentar zu KI. Sophos schaut auf das eigene Bug-Bounty-Programm zurück und nennt konkrete Zahlen.

Nach eigenen Angaben läuft das öffentliche Sophos-Programm seit Dezember 2017 auf Bugcrowd. Sophos schreibt, dass bis zum Zeitpunkt des Artikels 1'343 Schwachstellen vergütet wurden, bei 7'091 Gesamteinreichungen und insgesamt 599'695 US-Dollar Auszahlung.

Für 2025 nennt Sophos unter anderem:

• 59'400 US-Dollar Auszahlung für mehr als 52 Reports
• etwa 420 beteiligte Forscher
• bis zu 80'000 US-Dollar für Intercept X Endpoint unter bestimmten Bedingungen
• bis zu 50'000 US-Dollar für Sophos Central
• bis zu 50'000 US-Dollar für Sophos Firewall
• 13 gültige Sophos-Firewall-Bugs im Jahr 2025 mit 21'500 US-Dollar Gesamtauszahlung
• 13 gültige Sophos-Central-Bugs im Jahr 2025 mit 11'650 US-Dollar Gesamtauszahlung

Das sind keine astronomischen Zahlen, aber genau deshalb sind sie interessant. Sie zeigen, wie viel Sortierarbeit hinter einem halbwegs reifen Programm steckt. Tausende Einreichungen bedeuten nicht automatisch tausende relevante Sicherheitsprobleme. Und KI wird dieses Verhältnis vermutlich nicht entspannen.

Sie wird es härter machen.

Reproduzierbarkeit wird zur Eintrittskarte

Die wichtigste Konsequenz ist aus meiner Sicht banal, aber unbequem: Ein Security-Report ohne saubere Reproduzierbarkeit wird weniger wert.

Nicht weil Triage-Teams faul sind. Sondern weil ihre Zeit knapper wird.

Wenn ein Report behauptet, eine Remote Code Execution, ein Auth-Bypass oder eine kritische Datenfreigabe zu zeigen, muss er sauber belegen:

• welche Version betroffen ist
• welche Konfiguration notwendig ist
• welche Rechte der Angreifer braucht
• welche Schritte reproduzierbar zum Ergebnis führen
• welche Logs, Requests, Traces oder Screenshots die Behauptung stützen
• welcher Impact tatsächlich nachgewiesen ist
• wo die Grenze zwischen Vermutung und Beweis liegt

Das klingt streng. Ist es auch. Aber genau das wird nötig, wenn Security-Teams nicht in plausibel klingenden Texten ertrinken sollen.

Ein KI-generierter Report kann sprachlich sehr überzeugend wirken. Er kann Code zitieren, CVE-artig formulieren und eine saubere Struktur vortäuschen. Das macht ihn nicht wahr. Umgekehrt kann ein knapper, trockener Report mit gutem Proof of Concept extrem wertvoll sein.

Die neue Währung ist nicht Formulierung. Die neue Währung ist Nachweis.

KI macht Authorization-Bugs besonders unangenehm

Ein Punkt im Sophos-Beitrag ist für mich besonders praxisnah: KI kann dabei helfen, einen gefundenen Authorization-Bypass über grössere Scope-Flächen zu skalieren.

Das passt zu dem, was man in echten SaaS-Umgebungen ohnehin sieht. Autorisierung ist selten ein einzelner Schalter. Sie lebt in Rollen, Tenants, Objekt-IDs, Subdomains, API-Versionen, Admin-Oberflächen, mobilen Endpunkten, Legacy-Routen und halb migrierten Features.

Wenn ein Forscher ein Muster findet, kann KI helfen, Variationen davon systematisch abzuklopfen:

• Gilt der Bypass nur für einen Endpoint oder für eine ganze Endpoint-Familie?
• Funktioniert er nur in einem Tenant oder tenantübergreifend?
• Gibt es dieselbe Logik in alten und neuen APIs?
• Sind Admin- und User-Rollen wirklich überall sauber getrennt?
• Kann ein Objekt über eine direkte ID geladen werden, obwohl die UI es nicht anzeigen würde?

Genau dort wird KI gefährlich nützlich. Nicht als magischer Hacker, sondern als Beschleuniger für langweilige, breite, systematische Prüfung.

Und das ist schlecht für Organisationen, deren Security stark davon abhängt, dass niemand genug Zeit hat, die langweiligen Varianten durchzutesten.

Bug-Bounty ist kein PR-Postfach

Viele Firmen behandeln Bug-Bounties noch immer halb als Image-Thema: Wir haben ein Programm, also sind wir offen, modern und security-minded.

Das reicht nicht mehr.

Ein Bug-Bounty-Programm ist ein Produktionssystem. Es braucht klare Regeln, gute Triage, technische Reproduktion, Produktnähe, Engineering-Verantwortung und Incident-Response-Anbindung. Sonst wird es einfach ein öffentliches Postfach, in dem sich externe Forscher, KI-Slop und echte Angreifer denselben Eingang teilen.

Sophos bringt im Artikel zwei unangenehme Punkte zusammen:

Erstens: Gute Forscher helfen. Externe Sicht, andere Denkmuster und kontinuierlicher Druck sind wertvoll.

Zweitens: Ein System mit Geld und Vertrauen kann auch missbraucht werden. Sophos verweist auf Erfahrungen rund um Pacific Rim, Asnarök und Personal Panda, bei denen zeitliche Nähe zwischen aktiver Ausnutzung und späteren Bug-Bounty-Reports zumindest Fragen aufwarf. Sophos sagt ausdrücklich nicht, dass jeder solche Report böse war. Aber der operative Punkt bleibt: Ein Bug-Bounty-Programm darf nicht naiv gebaut sein.

Das heisst konkret:

• Reports gehören mit Telemetrie korreliert.
• Ein neues Finding sollte auch rückwirkende Threat Hunts auslösen können.
• Triage muss wissen, ob ähnliche Exploit-Versuche bereits sichtbar waren.
• Forscherreputation hilft, ersetzt aber keine technische Prüfung.
• Safe Harbor ist wichtig, aber kein Ersatz für Missbrauchserkennung.

Das ist die nüchterne Realität: Bug-Bounties sind Teil von Secure by Design, nicht Ersatz dafür.

Härtere Beweise bedeuten auch härtere Verantwortung

Hier gibt es eine Spannung, die man nicht wegmoderieren sollte.

Historisch sagt man Forschern oft: Bitte stoppt früh genug. Zeigt den Bug, aber geht nicht zu tief. Keine Kundendaten anfassen. Keine laterale Bewegung. Keine destruktiven Aktionen.

Das ist richtig.

Gleichzeitig wird die Beweislast steigen. Wenn KI massenhaft plausible, aber falsche Reports erzeugt, werden Programme mehr Evidenz verlangen. Dann entsteht die schwierige Frage: Wie kann ein Forscher Impact stärker belegen, ohne in gefährliches Verhalten abzurutschen?

Die Antwort kann nicht sein: “Macht einfach mehr.” Die Antwort muss kontrollierter werden:

• klarere Rules of Engagement
• dedizierte Testumgebungen
• sichere Reproduktionspfade
• vereinbarte Grenzen für Impact-Nachweise
• bessere Sandbox- und Lab-Systeme
• automatisierte Replays von Proofs of Concept

Für grössere Hersteller wird das fast zwingend. Wer ernsthaft hohe Bounties zahlt, sollte auch Infrastruktur haben, um Reports sauber und schnell zu validieren.

Für kleinere Projekte ist das bitterer. Sie bekommen dieselbe Slop-Welle, aber nicht dieselben Ressourcen. Genau deshalb werden manche Projekte finanzielle Bug-Bounties reduzieren oder ganz abschalten. Nicht weil sie Sicherheit nicht ernst nehmen, sondern weil der Betrieb des Programms selbst zur Belastung wird.

Was Admins und MSPs daraus lernen können

Man könnte jetzt sagen: Das betrifft nur Hersteller und Bugcrowd-Programme.

Ich glaube das nicht.

Der gleiche Mechanismus trifft auch MSPs, interne IT-Teams und Security-Verantwortliche. Überall dort, wo externe oder interne Findings bewertet werden müssen, steigt der Druck:

• Scanner liefern mehr Findings.
• KI-Assistenten erklären Findings überzeugender.
• Entwickler bringen KI-generierte Security-Hinweise mit.
• Kunden fragen nach CVEs, bevor sie den Kontext kennen.
• Management will wissen, ob ein Risiko echt ist oder nur laut.

Die praktische Antwort ist nicht, alles zu ignorieren. Die Antwort ist ein härterer Validierungsprozess.

Für mich gehören dazu mindestens diese Fragen:

1. Ist das Problem reproduzierbar?
2. Ist der betroffene Scope klar?
3. Gibt es einen realistischen Angreiferpfad?
4. Ist der Impact technisch belegt oder nur behauptet?
5. Gibt es Logs oder Telemetrie, die eine Ausnutzung zeigen könnten?
6. Ist der Fix ein Patch, eine Konfiguration, ein Workaround oder nur ein Pflaster?
7. Muss rückwirkend gesucht werden, ob das bereits ausgenutzt wurde?

Das klingt nach mehr Arbeit. Ist es auch. Aber es ist bessere Arbeit als hektisches Reagieren auf jeden gut geschriebenen Report.

Warum das gut zu Mythos passt

Der entscheidende Punkt an Mythos war für mich nie nur: “Wow, ein Modell findet Bugs.”

Der Punkt war: Wenn solche Fähigkeiten realer werden, sinkt die Zeit zwischen Finden, Verstehen, Reproduzieren und Ausnutzen. Genau dort trifft es Bug-Bounty-Programme. Sie sitzen an der Schnittstelle zwischen Forschung, Angriffspotenzial, Engineering und Verantwortung.

Sophos formuliert es im eigenen Artikel ähnlich: Die Frage ist nicht, wie man KI-Submissions stoppt. Die Frage ist, wie man Vertrauen und Signal erhält, wenn gute Forschung und Lärm beide mit Maschinengeschwindigkeit produziert werden können.

Das ist für mich die sauberste Zusammenfassung des Problems.

Nicht jede Organisation braucht ein eigenes grosses Bug-Bounty-Programm. Aber jede Organisation braucht bessere Mechanismen, um technische Behauptungen zu prüfen. Denn die Flut an Sicherheitsinformationen wird nicht kleiner. Sie wird schneller, lauter und besser formuliert.

Meine Einordnung

Ich halte den Sophos-Beitrag für einen sinnvollen Follow-up zu Mythos, weil er die Debatte aus dem Modellraum in den Betriebsraum holt.

Mythos ist das spektakuläre Signal. Bug-Bounty-Triage ist die Werkbank, auf der sich zeigt, ob Security-Prozesse mithalten.

Meine These ist deshalb einfach:

• Wer nur mehr Reports sammelt, wird verlieren.
• Wer reproduzierbare Evidenz verlangt, wird besser priorisieren.
• Wer Bug-Bounty, Telemetrie, Engineering und Incident Response verbindet, wird schneller reagieren.
• Wer KI nur als Textgenerator versteht, unterschätzt ihren Wert für systematische Security-Arbeit.
• Wer KI-Slop nicht filtert, verbrennt die Zeit der Menschen, die echte Probleme lösen müssten.

Das klingt weniger glamourös als ein Frontier-Modell, das Zero-Days findet. Aber genau dort entscheidet sich, ob der Sicherheitsgewinn bei den Verteidigern ankommt oder ob alle nur in mehr Lärm untergehen.

Bis zum nächsten Mal,
Euer Joe