Google pausiert Open-Source-Bug-Bounty, da KI-Berichte Prüfer überlasten
Google hat seine Open-Source-Bug-Bounty nach einer Welle automatisierter Meldungen pausiert und erklärt, dass die große Mehrheit davon ungültig gewesen sei. Die Aussetzung begann am 1. Oktober 2026 und betrifft neue Produkt-Schwachstellenmeldungen für das Open Source Software Vulnerability Reward Program.
Die Entscheidung verdeutlicht einen scharfen Widerspruch der KI-gestützten Sicherheitsforschung. Modelle können inzwischen mehr Code untersuchen und überzeugende Berichte in beispielloser Geschwindigkeit erstellen. Dennoch muss jede Meldung weiterhin von einem Menschen daraufhin geprüft werden, ob die behauptete Schwachstelle existiert, relevant ist und reproduziert werden kann.
Google ist nicht allein. Curl beendete seine finanziellen Prämien, nachdem die Quote bestätigter Schwachstellen im Jahr 2025 unter 5 % gefallen war. Auch Linux-Maintainer haben ihre Offenlegungspraktiken geändert, nachdem sie Wellen doppelter KI-Funde erhalten hatten. Zusammen zeigen diese Fälle, dass die Entdeckung von Schwachstellen schneller skaliert hat als ihre Prüfung.
Googles Open-Source-Bug-Bounty nimmt keine Produktberichte mehr an
Google hat einen wichtigen Eingangskanal vorübergehend geschlossen, weil automatisierte Einsendungen mehr Prüfaufwand als verwertbare Sicherheitsfunde verursachten.
Das Google OSS VRP, kurz für Open Source Software Vulnerability Reward Program, belohnt Forschende, die Sicherheitslücken in berechtigten Open-Source-Projekten verantwortungsvoll offenlegen. Google startete das Programm 2022, um Software in seinen öffentlichen Repositories und ausgewählte externe Projekte abzudecken.
Dieser Kanal für Produktschwachstellen nahm ab dem 1. Oktober keine neuen Meldungen mehr an. Google erklärte, im ersten Quartal 2027 ein weiteres Update geben zu wollen.
„Diese Pause ist auf einen deutlichen Anstieg automatisierter Einsendungen zurückzuführen, von denen die große Mehrheit nicht valide ist“, erklärte Google in seiner Mitteilung. Diese Formulierung ist wichtig, weil sie Automatisierung von verifizierter Schwachstellenforschung unterscheidet.
Die Pause löscht keine vor dem Stichtag eingereichten Meldungen. Sie schließt auch nicht jeden Weg aus, der mit dem umfassenderen Programm verbunden ist. Meldungen zu Schwachstellen in der Lieferkette bleiben laut den aktualisierten Programmregeln weiterhin berechtigt.
Einige Schwachstellen in Google-Cloud-Repositories können weiterhin über das Cloud VRP qualifiziert sein. Google hat Forschende zudem auf seine anderen Prämienprogramme verwiesen, während das Unternehmen den Aufnahmeprozess für Open Source überprüft.
Dieser engere Umfang macht „Einfrieren“ treffender als „Abschaltung“. Google hat neue Meldungen zu Produktschwachstellen innerhalb des OSS-Programms ausgesetzt, nicht externe Sicherheitsforschung im gesamten Unternehmen aufgegeben.
Das Unternehmen hat weder eine Zahl der Einsendungen noch eine Quote ungültiger Berichte oder den gesamten Triage-Rückstau für den betroffenen Kanal veröffentlicht. Behauptungen, Prüfer hätten eine konkrete Zahl schlechter Berichte erhalten, bleiben daher unbestätigt.
Was Google offengelegt hat, ist jedoch das entscheidende Signal. Automatisierte Berichte waren zahlreich genug und unzuverlässig genug geworden, um den bestehenden Prozess untragbar zu machen.
Dieser Prozess besteht aus mehr als dem Empfang eines sorgfältig formulierten Dokuments. Ein Prüfer muss den Codepfad untersuchen, die Bedingungen nachstellen, die Ausnutzbarkeit bewerten, nach Duplikaten suchen und das zuständige Projektteam identifizieren.
Ein plausibler Bericht kann beträchtliche Zeit beanspruchen, selbst wenn er falsch ist. Große Sprachmodelle verschärfen dieses Problem, weil sie detaillierte Erklärungen, Code-Snippets und selbstsichere Schweregradbewertungen liefern können, ohne die zugrunde liegende Schwachstelle nachzuweisen.
Google hatte seine Regeln bereits früher im Jahr 2026 verschärft, nachdem das Unternehmen einen „massiven Anstieg“ KI-generierter Berichte beobachtet hatte. Die Pause im Oktober deutet darauf hin, dass Filteranforderungen allein kein akzeptables Signal-Rausch-Verhältnis wiederherstellten.
Googles Open-Source-Bug-Bounty ist damit zu einem Testfall für ein breiteres Sicherheitsproblem geworden. Eine Behauptung zu erzeugen ist inzwischen billig, während sie zu widerlegen teuer bleibt.
Warum KI-Bug-Berichte asymmetrische Kosten verursachen
KI verändert die Ökonomie der Offenlegung, weil eine Maschine Berichte schneller erstellen kann, als Maintainer sie validieren können.
Traditionelle Bug-Jagd verursacht für Forschende relevante Kosten. Eine Person muss eine Codebasis verstehen, unerwartetes Verhalten isolieren, prüfen, ob daraus Sicherheitsauswirkungen entstehen, und einen reproduzierbaren Fall dokumentieren.
Generative KI verringert Teile dieses Aufwands. Ein Agent kann Repositories durchsuchen, Funktionen verfolgen, Muster vergleichen, Proof-of-Concept-Code entwerfen und vorläufige Erkenntnisse in professionell wirkende Berichte überführen.
Diese Fähigkeiten können legitimen Forschenden helfen. Sie können aber auch unerfahrenen Nutzern ermöglichen, Behauptungen einzureichen, die sie nicht verstehen und bei Rückfragen nicht verteidigen können.
Die Asymmetrie zeigt sich nach der Einreichung. Einen weiteren Bericht zu erstellen, kann wenig zusätzlichen Aufwand erfordern, doch seine Triage beansprucht weiterhin knappe Engineering-Kapazitäten.
Christopher Robinson, Chief Technology Officer der Open Source Security Foundation, beschrieb diese Belastung in einem Sicherheitsbericht vom März. Beliebte Projekte hätten früher in einer durchschnittlichen Woche zwei oder drei Berichte erhalten, schätzte er. Später hätten einige davon Hunderte auf einmal erhalten.
Robinson zufolge kann ein einzelner Bericht zwei bis acht Stunden ungeplante Arbeit für Maintainer erfordern. Diese Kosten entstehen selbst dann, wenn das Endergebnis lautet, dass keine Schwachstelle existiert.
Fehlalarme sind nicht das einzige Problem. Automatisierte Systeme können doppelte Funde senden, dokumentiertes Verhalten falsch interpretieren, Bedrohungsmodelle ignorieren oder Defekte mit geringer Auswirkung übertreiben.
Eine halluzinierte Schwachstelle ist besonders kostspielig, weil der Bericht in sich stimmig klingen kann. Prüfer können einer detaillierten technischen Argumentation folgen, bevor sie feststellen, dass eine erwähnte Funktion, ein Kontrollpfad oder eine Ausnutzungsbedingung erfunden wurde.
Vlad Ionescu, Mitgründer des KI-Sicherheitsunternehmens RunSybil, beschrieb diese Erfahrung in einer früheren Untersuchung zu AI Slop. Er sagte, Berichte könnten technisch fundiert erscheinen, bis Prüfer sie untersuchten und feststellten, dass das Modell die Details erfunden hatte.
Dadurch entsteht ein Verifizierungsengpass. KI erweitert das Angebot möglicher Funde, erhöht aber nicht automatisch die Zahl vertrauenswürdiger Prüfer.
Bug-Bounties schaffen zudem einen finanziellen Anreiz, unsichere Behauptungen einzureichen. Forschende können viele spekulative Berichte senden, während Maintainer den Großteil der Validierungskosten tragen.
Reputationssysteme und Ratenbegrenzungen können Missbrauch verringern, bringen jedoch eigene Zielkonflikte mit sich. Strenge Hürden können neue Forschende ausschließen, denen die Plattformhistorie fehlt, obwohl sie über einen legitimen Fund verfügen.
Identitätsanforderungen können verantwortungsvolle Offenlegungen von Personen abschrecken, die rechtlichen, beruflichen oder geografischen Risiken ausgesetzt sind. Einreichungsgebühren würden eine noch größere Hürde schaffen.
Automatisierte Vorabprüfungen stellen eine weitere Komplikation dar. Ein Filter, der Berichte zurückweist, weil sie maschinell erzeugt klingen, kann echte Schwachstellen verwerfen, die mit KI-Unterstützung gefunden oder dokumentiert wurden.
Die wesentliche Unterscheidung lautet nicht, ob KI an einem Bericht beteiligt war. Entscheidend ist, ob der Einreicher das Verhalten verifiziert hat und die Behauptung mit reproduzierbaren Belegen stützen kann.
Dieser Standard lässt sich schwerer durchsetzen, wenn Agenten überzeugende Dokumente im großen Maßstab erstellen können. Textqualität ist kein verlässliches Signal für Forschungsqualität mehr.
Die praktische Reaktion wird wahrscheinlich strengere Anforderungen an Belege umfassen. Programme können minimale Reproduktionen, Angaben zu betroffenen Versionen, Exploit-Traces, Testfälle oder funktionierende Patches verlangen, bevor sie eine menschliche Prüfung zuweisen.
Diese Anforderungen verlagern einen Teil der Verifizierungskosten zurück auf den Einreicher. Sie begünstigen zudem Forschende, die den Code verstehen und für Rückfragen verfügbar bleiben.
Googles Problem mit KI-Bug-Berichten ist zugleich ein Erfolg der KI-Sicherheit
Dieselbe Technologie, die minderwertige Einsendungen erzeugt, findet reale Schwachstellen, die menschliche Forschende übersehen haben.
Jeden KI-gestützten Bericht als Müll zu behandeln, würde die Belege falsch deuten. Fortschrittliche Modelle haben unter kontrollierten Bedingungen bedeutende Fähigkeiten zur Codeanalyse demonstriert.
Anthropic erklärte, Claude Opus 4.6 habe während interner Tests mehr als 500 zuvor unbekannte Schwachstellen in Open-Source-Projekten gefunden. Jede Feststellung sei laut dem Unternehmen vor der Offenlegung von menschlichen oder externen Sicherheitsforschenden validiert worden.
Mozilla erhielt innerhalb von zwei Wochen 112 Berichte aus dieser Initiative. Das Unternehmen veröffentlichte 22 Sicherheitshinweise, darunter 14 für Schwachstellen mit hohem Schweregrad, und stufte viele der übrigen Funde als nicht sicherheitsrelevante Fehler ein.
Diese Ergebnisse veranschaulichen einen Prozess, der sich von massenhaften automatisierten Einreichungen unterscheidet. Anthropic kombinierte maschinelle Entdeckung mit menschlicher Validierung, koordinierter Offenlegung und fokussierter Kommunikation mit Maintainern.
In einem Fall soll das Modell einen Proof of Concept erstellt haben, um nachzuweisen, dass eine vermutete Schwachstelle tatsächlich bestand. Dieser Schritt verwandelt ein spekulatives Muster in Belege, die Prüfer testen können.
Die Firefox-Funde zeigen auch, warum ein vollständiges Verbot von KI-Forschung kontraproduktiv wäre. Modelle können ausgereiften, intensiv getesteten Code untersuchen und dennoch folgenreiche Fehler aufdecken.
Der Konflikt lautet daher nicht Menschen gegen KI. Es geht um verifizierte Forschung gegen nicht rechenschaftspflichtige Berichtserstellung.
Ein hochwertiger KI-gestützter Workflow behält einen menschlichen Verantwortlichen. Diese Person prüft die Ergebnisse, entfernt Fehlalarme, versteht die Auswirkungen und übernimmt Verantwortung für die Kommunikation mit Maintainern.
Ein minderwertiger Workflow behandelt den Offenlegungsendpunkt als weiteres automatisiertes Ziel. Der Agent identifiziert ein Muster, formuliert eine Schweregrad-Erzählung und reicht sie ohne unabhängige Reproduktion ein.
Beide Workflows können sorgfältig formulierte Texte erzeugen. Nur einer reduziert den Arbeitsaufwand auf Empfängerseite.
Diese Unterscheidung erklärt, warum Googles Pause nicht beweist, dass KI-gestützte Bug-Jagd gescheitert ist. Sie zeigt, dass die Einreichungsarchitektur des Unternehmens die aktuelle Mischung aus wertvollen Funden, Duplikaten und Halluzinationen nicht aufnehmen konnte.
KI-gestützte Sicherheit könnte schließlich beide Seiten dieser Architektur verbessern. Programme können Modelle nutzen, um Duplikate zu gruppieren, Behauptungen mit bekannten Problemen abzugleichen, Exploit-Pfade zu testen und fehlende Belege zu identifizieren.
HackerOne und andere Plattformen haben begonnen, KI-gestützte Triage-Unterstützung einzuführen. Solche Werkzeuge können Berichte priorisieren, doch ihre Leistung muss an Raten falscher Zurückweisungen und übersehener Schwachstellen gemessen werden.
Auch ein automatisierter Prüfer kann halluzinieren. Wenn Programme ein Modell zwischen Forschende und Maintainer setzen, benötigen sie Eskalationswege für Funde, die der Filter nicht zuverlässig klassifizieren kann.
Das stärkste Modell ist wahrscheinlich mehrschichtig. Maschinen führen kostengünstige Prüfungen durch, erfahrene Triage-Teams bewerten die verbliebenen Berichte, und Projekt-Maintainer bearbeiten nur glaubwürdige Funde.
Dieser Ansatz ähnelt Continuous Integration für Softwarebeiträge. Tests weisen offensichtliche Fehler zurück, bevor ein Maintainer Zeit für eine detaillierte Prüfung aufwendet.
Sicherheitsbehauptungen bleiben schwieriger zu testen als gewöhnliche Codeänderungen. Die Ausnutzbarkeit hängt von Kontext, Konfiguration, Vertrauensgrenzen und Angreiferfähigkeiten ab, die automatisierte Prüfungen missverstehen können.
Dennoch kann die Forderung nach maschinell prüfbaren Belegen die Ausgangslage verbessern. Ein Bericht mit einem fehlschlagenden Test, einem Ausführungstrace oder einem reproduzierbaren Absturz gibt Prüfern etwas Konkretes zur Bewertung.
Organisationen benötigen für diese Arbeit außerdem belastbare Aufzeichnungen. Eine durchsuchbare Engineering-Wissensdatenbank kann Teams dabei helfen, neue Erkenntnisse mit früheren Berichten, Entscheidungen und Fehlerbehebungen zu vergleichen.
Das Ziel besteht nicht darin, legitime Entdeckungen zu verlangsamen. Es geht darum, zu verhindern, dass unbegrenzte Generierung ein begrenztes Budget für menschliche Prüfung aufbraucht.
Curl und Linux zeigen: Das ist ein Branchenproblem
Die Pause von Google folgt einem Muster, bei dem Open-Source-Projekte ihre Meldekanäle einschränken, nachdem KI bestehende Vertrauenssysteme überfordert hat.
Curl liefert das deutlichste frühere Beispiel. Das weit verbreitete Datenübertragungsprojekt beendete sein monetäres Bug-Bounty-Programm am 31. Januar 2026, nachdem es das Programm seit 2019 betrieben hatte.
Maintainer Daniel Stenberg erklärte, das Programm habe 87 bestätigte Schwachstellen hervorgebracht. Allerdings verschlechterte sich der Qualitätstrend im Laufe des Jahres 2025 deutlich.
Curl bestätigte zuvor mehr als 15 % der Einsendungen als Schwachstellen. 2025 fiel die Quote unter 5 %, was bedeutet, dass weniger als einer von zwanzig Berichten tatsächlich gültig war.
Stenberg machte drei miteinander verbundene Trends verantwortlich: KI-Schrott, die sinkende Qualität anderer Einsendungen und Meldende, die sich auf Belohnungen statt auf die Verbesserung des Projekts konzentrierten.
„Die endlosen Schrott-Einsendungen sind mental äußerst belastend zu verwalten“, schrieb er bei der Ankündigung der Entscheidung von curl.
Curl stellte die Annahme von Sicherheitsmeldungen nicht ein. Das Projekt schaffte monetäre Belohnungen ab, beließ HackerOne als empfohlenen Kanal und verwies Forschende auf private GitHub-Meldungen oder E-Mail.
Diese Reaktion zielte auf Anreize statt auf die Technologie selbst. Stenberg argumentierte, Belohnungen hätten zwar legitime Entdeckungen angezogen, spekulative Einsendungen aber zugleich zu einfach gemacht.
Er räumte den Zielkonflikt ein. Das Abschaffen von Zahlungen kann Rauschen reduzieren, aber auch die Anreize für qualifizierte unabhängige Forschende schwächen, die viel Zeit in schwierige Untersuchungen investieren.
Die Linux-Kernel-Community sah sich mit einem verwandten Problem doppelter Befunde konfrontiert. Mehrere Forschende setzten ähnliche KI-Tools auf denselben Code an und reichten dieselben Probleme über einen privaten Kanal ein.
Private Meldungen verhinderten, dass Forschende sehen konnten, ob eine andere Person einen Befund bereits gemeldet oder diskutiert hatte. Maintainer leiteten Duplikate wiederholt um oder verwiesen auf bereits öffentlich verfügbare Fehlerbehebungen.
Linus Torvalds beschrieb die private Sicherheitsliste als „fast vollständig unverwaltbar“. Er argumentierte, dass KI-entdeckte Befunde grundsätzlich über öffentliche Projektkanäle laufen sollten, sofern Geheimhaltung nicht wirklich erforderlich ist.
Auch die Linux-Dokumentation erhöhte den erwarteten Standard für Einreichende. Forschende sollten prägnante Belege vorlegen, die zuständigen Maintainer kontaktieren und, wenn möglich, einen Patch beitragen.
Diese Richtlinie bewahrt menschliche Verantwortlichkeit. KI kann bei der Entdeckung helfen, aber eine Person muss den Bericht verstehen und für dessen Folgen verantwortlich bleiben.
Google, curl und Linux wählten unterschiedliche Maßnahmen, weil ihre Programme unterschiedlich strukturiert sind. Google pausierte eine Einreichungskategorie. Curl schaffte Belohnungen ab. Linux leitete viele Berichte um und betonte die öffentliche Bearbeitung.
Ihre gemeinsame Schlussfolgerung ist wichtiger als die einzelnen Richtliniendetails. Offene Einreichungen ohne nennenswerte Kosten für Meldende funktionieren nicht, wenn automatisierte Agenten nahezu unbegrenzt Behauptungen erzeugen können.
Kleinere Projekte tragen das größte Risiko. Google kann Engineers einsetzen und Infrastruktur neu gestalten, während ehrenamtliche Maintainer möglicherweise kein eigenes Triage-Team haben.
Open-Source-Software steckt häufig in kommerziellen Produkten, Cloud-Diensten, Entwicklungstools und kritischen Systemen. Dennoch kann die Verantwortung für die Prüfung von Sicherheitsberichten auf wenigen unbezahlten Mitwirkenden lasten.
KI verstärkt dieses Missverhältnis. Sie ermöglicht Außenstehenden, wichtigen Code kontinuierlich zu scannen, ohne die Arbeit bereitzustellen, die nötig ist, um jeden möglichen Befund zu validieren, zu patchen und zu koordinieren.
Das Ergebnis ähnelt einem Denial-of-Service-Problem, selbst wenn Meldende gute Absichten haben. Jeder Bericht verlangt von Maintainern Aufmerksamkeit, und das Gesamtvolumen kann echte Schwachstellen verdrängen.
Strengere Hürden können auch echte Schwachstellen verbergen
Programme müssen minderwertige Mengen reduzieren, ohne ein Sicherheitssystem zu schaffen, das nur etablierten Forschenden zugänglich ist.
Googles Pause schützt Prüfende kurzfristig, nimmt legitimen Entdeckungen aber auch einen Meldeweg. Für eine gültige Produktschwachstelle, die nach dem 1. Oktober gefunden wird, könnte ein anderes berechtigtes Programm oder ein anderer Offenlegungskanal nötig sein.
Diese Reibung ist relevant, weil Forschende die organisatorischen Grenzen eines Unternehmens nicht immer verstehen. Ein Fehler in einem Open-Source-Repository kann ein Cloud-Produkt, eine Abhängigkeit oder eine nachgelagerte Anwendung betreffen.
Komplizierte Routing-Regeln erhöhen das Risiko verspäteter oder fehlgeleiteter Offenlegungen. Sie können auch zur öffentlichen Veröffentlichung verleiten, wenn Forschende keinen akzeptierten privaten Kanal identifizieren können.
Reputationsbasierter Zugang schafft ein weiteres Risiko. Erfahrene Forschende sind leichter einzuschätzen, doch neue Teilnehmende haben in der Vergangenheit wichtige Entdeckungen zu Bounty-Programmen beigetragen.
Ein System, das etablierte Identitäten bevorzugt, kann bestehende Zugangslücken reproduzieren. Es kann unabhängige Forschende, Studierende und Menschen außerhalb großer Sicherheitscommunities benachteiligen.
Strenge Anforderungen an Proofs of Concept können ebenfalls riskant werden. Der Nachweis der Ausnutzbarkeit kann den Umgang mit echten Daten, das Umgehen von Schutzmaßnahmen oder Tests erfordern, die gegen Programmregeln verstoßen.
Programme benötigen daher starke, aber sichere Belegstandards. Ein minimaler Reproducer, ein kontrollierter Test oder ein detaillierter Codepfad kann Glaubwürdigkeit schaffen, ohne schädliche Ausnutzung zu verlangen.
Zudem gibt es keinen verlässlichen Detektor für KI-generierte Texte. Forschende nutzen Modelle häufig für Übersetzungen, Lektorat, Code-Erklärungen oder Formatierung, selbst wenn die zugrunde liegende Arbeit legitim ist.
Berichte anhand ihres Stils abzulehnen, würde sorgfältige Offenlegung bestrafen und Anreize schaffen, KI-Nutzung zu verbergen. Es würde nicht klären, ob die gemeldete Schwachstelle tatsächlich real ist.
Googles öffentliche Stellungnahme lässt mehrere Fragen offen. Das Unternehmen hat nicht offengelegt, welche Prüfmaßnahmen versagten, wie viele legitime Befunde von der Welle erfasst wurden oder welche Neugestaltung es erwägt.
Unklar ist auch, ob die Pause mit stärkerer Automatisierung, höheren Beleganforderungen, eingeschränktem Zugang oder einem anderen Belohnungsmodell enden wird.
Der Mangel an Zahlen begrenzt die externe Bewertung. „Die überwiegende Mehrheit“ vermittelt die Schwere, verrät jedoch nicht, ob die Validität nur leicht unter eine bestehende Schwelle sank oder nahezu vollständig einbrach.
Lesende sollten Googles Erfahrung zudem nicht als allgemein gültig betrachten. Mozilla erklärte zuvor, seine Ablehnungsquote für ungültige Berichte sei während eines früheren Zeitraums trotz branchenweiter Bedenken stabil geblieben.
Programmdesign, Projektsichtbarkeit, Belohnungsanreize und Einreichungsregeln beeinflussen sowohl Menge als auch Qualität der Berichte. Eine Richtlinie, die für ein Projekt funktioniert, kann bei einem anderen scheitern.
Auch KI-Systeme selbst verändern sich schnell. Bessere Modelle können überzeugendere Fehlalarme erzeugen, aber sie können auch stärkere Nachweise liefern und Halluzinationen reduzieren.
Diese doppelte Entwicklung macht starre Regeln fragil. Programme benötigen messbare Qualitätskontrollen, die Belege bewerten, statt zu erraten, welches Tool sie erzeugt hat.
Für Sicherheitsverantwortliche sollte die zentrale Kennzahl nicht das reine Berichtsvolumen sein. Nützliche Messgrößen sind die Quote bestätigter Schwachstellen, die Duplikatquote, die mediane Triagezeit, die Behebungszeit und die Arbeitslast der Prüfenden.
Ein Programm kann mehr Berichte erhalten und zugleich weniger effektiv werden. Umgekehrt können strengere Einreichungsregeln das Volumen senken und gleichzeitig den Anteil ernsthafter Befunde erhöhen, die Maintainer erreichen.
Die Pause des Google OSS VRP sollte daher daran gemessen werden, was sie ersetzt. Eine überlastete Warteschlange zu schließen ist nachvollziehbar, doch ein dauerhaftes Sicherheitsergebnis erfordert einen vertrauenswürdigen Weg für gültige Berichte.
Wie es mit dem Google Open Source Bug Bounty weitergeht
Drei Signale werden zeigen, ob Googles Pause zu einem besseren Offenlegungssystem oder zu einem dauerhaften Rückzug von offener Beteiligung wird.
Das erste Signal ist Googles zugesagtes Update im ersten Quartal 2027. Die wichtigsten Details werden Berechtigung, Belegstandards, automatisierte Prüfung und Einspruchsverfahren betreffen.
Eine Wiedereröffnung mit klaren Reproduktionsanforderungen würde dafür sprechen, dass Google die Pause zur Neugestaltung der Einreichungen genutzt hat. Eine unbefristete Verlängerung würde nahelegen, dass offene Einreichungen wirtschaftlich weiterhin schwierig bleiben.
Beobachten Sie, ob Google von Meldenden ausführbare Tests, betroffene Commits, Exploit-Traces oder vorgeschlagene Fehlerbehebungen verlangt. Solche Regeln würden Verantwortung stärker auf Forschende verlagern, ohne KI-Unterstützung zu verbieten.
Das zweite Signal ist die Quote bestätigter Berichte nach einer möglichen Wiedereröffnung. Google hat keine aktuelle Ausgangsbasis veröffentlicht; Transparenz über künftige Validitäts- und Duplikatquoten würde helfen, das neue System zu bewerten.
Eine höhere Bestätigungsquote bei stabilem Zugang zur Offenlegung würde strengere Filter stützen. Ein starker Rückgang der Beteiligung könnte darauf hindeuten, dass die Hürden neben Spam auch legitime Forschende ausschließen.
Auch die Triagezeit ist wichtig. Wenn Prüfende glaubwürdige Berichte schneller bewerten können, hätte Google Belege dafür, dass die Neugestaltung versteckte Arbeit reduziert hat, statt lediglich sichtbares Volumen zu senken.
Das dritte Signal ist die Reaktion anderer Projekte und Plattformen. Curl schaffte Belohnungen ab, Linux leitete automatisierte Befunde um, und Google pausierte eine Einreichungskategorie.
Wenn mehr Programme verifizierte Reproduktionen, Patch-Anforderungen oder Reputationsschwellen einführen, könnten diese Praktiken zum Standard für KI-gestützte Offenlegung werden.
Plattformen könnten auch gemeinsame Schutzmechanismen entwickeln. Duplikaterkennung über Programme hinweg, standardisierte maschinenlesbare Belege und verantwortliche Agentenidentitäten könnten wiederholte Arbeit verringern.
Das konstruktivste Ergebnis würde den Umfang der Entdeckung vom Umfang der Einreichung trennen. Forschende könnten Agenten breit einsetzen, doch nur validierte und deduplizierte Befunde würden in Warteschlangen menschlicher Prüfung gelangen.
Dieses Modell erfordert Verantwortung bei jeder Übergabe. Tool-Entwickler müssen für Verifizierung entwickeln, Forschende müssen Befunde testen, Plattformen müssen sorgfältig filtern, und Maintainer brauchen klare Eskalationswege.
Entwickler, die KI-Sicherheitstools einsetzen, sollten sich bereits so verhalten, als gäbe es diese Regeln. Sie sollten jede Behauptung reproduzieren, den betroffenen Code verstehen, die öffentliche Issue-Historie prüfen und realistische Auswirkungen dokumentieren.
Sie sollten auch nach der Einreichung erreichbar bleiben. Ein Meldender, der grundlegende technische Fragen nicht beantworten kann, überträgt die gesamten Untersuchungskosten auf das Projekt.
Für Unternehmen reicht die Lehre über Bug Bounties hinaus. Jedes öffentliche Eingangssystem kann überlastet werden, wenn KI die Inhaltserzeugung billig macht, während die Bewertung teuer bleibt.
Support-Warteschlangen, Bewerbungen, Förderprogramme, Pull Requests und Compliance-Berichte stehen vor demselben grundlegenden Ungleichgewicht. Die knappe Ressource ist nicht länger das Schreiben. Es ist vertrauenswürdige Prüfung.
Die Pause von Googles Open-Source-Bug-Bounty macht dieses Ungleichgewicht in einem hochsensiblen Umfeld sichtbar. Ein falscher Sicherheitsbericht verschwendet Zeit, während eine übersehene echte Schwachstelle Millionen nachgelagerter Nutzender gefährden kann.
Die Herausforderung besteht nicht darin, zwischen KI und menschlichen Forschenden zu wählen. Es geht darum, ein Offenlegungssystem zu gestalten, in dem Automatisierung verifizierte Sicherheitsarbeit erhöht, statt unbelegte Behauptungen zu vervielfachen.
Google hat nun bis zu seinem nächsten Update Zeit zu zeigen, wie dieses System aussieht. Wird das Unternehmen mit stärkeren Beleg-Hürden und sinnvoller Zugänglichkeit wieder öffnen, oder wird offene Beteiligung weiter eingeschränkt, während das Berichtsvolumen wächst?
