Google nimmt seit dem 1. Oktober 2026 keine neuen Produkt-Schwachstellenmeldungen im Open Source Software Vulnerability Reward Program mehr an. Als Grund nennt das Unternehmen einen starken Anstieg automatisierter Einreichungen, von denen die große Mehrheit ungültig sei. Ein weiteres Update ist für das erste Quartal 2027 vorgesehen.
Das ist eine Pause einer Meldekategorie, keine Schließung aller Google-Prämienprogramme und kein Verbot KI-gestützter Forschung. Sichtbar wird ein konkreteres Versagen: Eine plausible Sicherheitsbehauptung lässt sich billig erzeugen, ihre Prüfung benötigt weiterhin knappe Fachkompetenz.
Was geschlossen wurde und was offenbleibt
Google startete OSS VRP 2022 für geeignete Open-Source-Sicherheitsprobleme. Produktmeldungen betreffen Fehler in Code, Logik oder Design. Die Oktoberpause gilt für neue Einreichungen dieser Kategorie; zuvor eingegangene Meldungen bleiben prüfungsberechtigt.
Lieferkettenmeldungen sind weiterhin möglich. Manche Probleme in Google-Cloud-Repositories können abhängig von betroffenem Produkt und Regeln über Cloud VRP eingereicht werden. Andere Programme für Chrome, Android, Geräte und KI-Sicherheit bestehen ebenfalls fort. Forschende müssen den tatsächlichen Geltungsbereich prüfen, statt für jedes Repository denselben Ersatzweg anzunehmen.
Die Aussetzung folgte früheren Änderungen. Googles Regeln von 2026 verlangten die Validierung KI-gestützter Funde und einen Nachweis realer Sicherheitsauswirkungen. Im April entfielen Geldprämien und öffentliche Anerkennung für bestimmte niedrigere Produktkategorien und andere Sicherheitsprobleme. Diese engeren Anreize und Evidenzregeln verhinderten die spätere Pause nicht.
Google hat weder genaue Einreichungszahlen noch Annahmequote oder Rückstand für den ausgesetzten Kanal veröffentlicht. Sekundärberichte sprechen von Tausenden schwachen Meldungen; diese Zahl steht nicht in Googles Hinweis. „Überwiegend ungültig“ beschreibt ein ernstes Problem, liefert aber keine vollständige statistische Ausgangslage.
Der Ersatz ist öffentlich noch unbestimmt. Getestete Reproduktionen, Mengenbegrenzungen, Identitätsregeln und automatische Vorprüfung sind mögliche Antworten, keine angekündigten Wiedereröffnungsbedingungen.
Ein überzeugender Bericht kann keine Schwachstelle enthalten
Ein Modell kann eine verdächtige Operation erkennen, einen Angriffsablauf formulieren und eine professionell wirkende Schwerebewertung hinzufügen. Die Operation erhält vielleicht nie Angreiferdaten, ist unerreichbar oder durch wirksame Validierung geschützt. Selbst ein echter Programmierfehler muss im Bedrohungsmodell des Projekts keine Sicherheitsfolge haben.
Prüfer müssen diese Voraussetzungen rekonstruieren. Sie untersuchen Revisionen, reproduzieren Verhalten, prüfen Schutzmechanismen und suchen Duplikate. Eine erfundene Funktion oder Auslösebedingung kann in einer ansonsten schlüssigen Darstellung verborgen bleiben. Gute Formatierung ersetzt keine Forschungsevidenz mehr.
Christopher Robinson von der Open Source Security Foundation schätzte in einer Märzreportage, dass Projekte mit früher zwei oder drei wöchentlichen Meldungen später Hunderte auf einmal erhielten. Einzelne Untersuchungen könnten zwei bis acht Stunden ungeplanter Maintainer-Arbeit beanspruchen. Das sind zugeschriebene projektübergreifende Beobachtungen, keine Messungen von Googles Warteschlange.
Finanzielle Anreize verstärken die Asymmetrie. Ein Einreicher kann viele spekulative Behauptungen erzeugen, während das Projekt die Prüfung bezahlt. Duplikate, übertriebene Schwere und missverstandenes dokumentiertes Verhalten konkurrieren mit echten Funden. Auch gut gemeinte Mengen können Reparaturen verdrängen.
Entscheidend ist nicht, ob ein Modell am Text beteiligt war. Übersetzung, Erklärung und Testerstellung können legitime Arbeit verbessern. Ein Mensch muss den erreichbaren Pfad verstehen, das Ergebnis reproduzieren und Rückfragen beantworten. Eine ungetestete KI-Behauptung in menschlichem Stil wird dadurch nicht validiert.
Validierte KI-Forschung spricht gegen pauschale Ablehnung
Google entwickelt weiter KI-gestützte Abwehr mit OSS-Fuzz, Big Sleep und CodeMender. Interne Teams können Ziele definieren, Ausführungsevidenz sammeln und Patches prüfen. Ein externes Programm erhält Meldungen aus vielen Werkzeugen und Umgebungen ohne dieselbe kontrollierte Kette.
Auch Googles Gesamtprämien bleiben erheblich. Laut Jahresrückblick zahlte das Unternehmen 2025 mehr als 17 Millionen Dollar an über 700 Forschende, mehr als 40 Prozent über 2024. Das sind Summen der breiteren Programme, nicht Budget oder Produktivität der pausierten OSS-Kategorie.
Die Berichterstattung enthält einen weiteren Gegenvergleich. Anthropic erklärte, Claude Opus 4.6 habe über 500 zuvor unbekannte Open-Source-Schwachstellen gefunden, jeweils vor Offenlegung durch Menschen oder externe Fachleute bestätigt. Mozilla erhielt innerhalb zweier Wochen 112 Berichte und veröffentlichte 22 Sicherheitshinweise, darunter 14 mit hoher Schwere. Viele andere Funde galten als nicht sicherheitsrelevante Fehler.
Diese Einheiten sind zu trennen: Meldungen, Hinweise und validierte Schwachstellen sind keine austauschbaren Zähler. Das Beispiel stützt maschinelle Entdeckung mit Expertenprüfung, nicht eine Garantie für jeden Modellbericht.
Automatische Triage könnte Duplikate bündeln und fehlende Evidenz anfordern. Auch sie irrt. Dass zwei Modelle übereinstimmen, ist schwächer als ein unabhängig reproduzierbarer Test. Für ungewöhnliche Funde und Konflikte bleibt menschliche Eskalation notwendig.
Curl, Linux und HackerOne änderten verschiedene Übergaben
Curl beendete Geldprämien am 31. Januar 2026 nach einem seit 2019 bestehenden Programm. Daniel Stenberg berichtete über 87 bestätigte Schwachstellen während dessen Laufzeit. Der bestätigte Anteil sank jedoch von früher über 15 Prozent auf weniger als fünf Prozent im Jahr 2025.
Seine Begründung verband KI-Rauschen, schwächere andere Berichte und übermäßigen Prämienfokus. Das Ende der Zahlungen beendete nicht verantwortliche Offenlegung: Private GitHub-Meldungen und E-Mail blieben möglich. Es zielte auf Anreize, mit dem Risiko, auch sorgfältige unabhängige Forschende weniger zu motivieren.
Linux erhielt wiederholt dieselben Funde von Personen mit ähnlichen KI-Werkzeugen. Private Behandlung verbarg vorhandene Diskussionen und Reparaturen vor anderen Einreichern; Maintainer prüften immer wieder dasselbe. Torvalds befürwortete deshalb öffentliche Projektkanäle für viele leicht wiederauffindbare Probleme, sofern echte Geheimhaltung nicht erforderlich ist.
Das fordert nicht zur Veröffentlichung jedes ungepatchten Exploits auf. Die Kernel-Regeln verlangen knappe Beschreibungen, betroffene Revisionen, Auslösebedingungen, getestete Reproduktionen und realistische Auswirkungen. Einreicher sollen Code verstehen, zuständige Maintainer einbeziehen und nach Möglichkeit einen Patch beitragen.
HackerOne meldete mehr als 100 Prozent Wachstum des branchenweiten Berichtsvolumens nach leistungsfähigeren KI-Werkzeugen im Februar 2026. Die Analyse enthält nützliche Funde ebenso wie Duplikate und unbelegbare Behauptungen. Die Plattform betont reproduzierbare Beweise, korrekte Schwere und vorhandene Abwehr; große ungeprüfte Mengen können Sanktionen auslösen. Das ist eine Plattformbeobachtung, nicht Googles Ungültigkeitsquote.
Die Eingriffe unterscheiden sich: Google pausierte eine Kategorie, curl entfernte Geldanreize und Linux passte Erwartungen und Routing an. Gemeinsam ist die begrenzte Expertenzeit, insbesondere bei freiwillig gepflegten kommerziellen Abhängigkeiten.
Eine Wiederöffnung braucht Evidenz und Zugang für Neue
Strenge Hürden schützen Prüfer, können aber echte Probleme verbergen. Reputation bevorzugt etablierte Forschende. Kautionen oder undurchsichtige Einladungen schließen Neulinge aus. Verpflichtende vollständige Exploits können zudem unsichere Tests fördern, obwohl eine minimale kontrollierte Reproduktion genügen würde.
Ein gutes Evidenzpaket benennt Commit, Umgebung, Angreifereinfluss, Eingabe und überschrittene Sicherheitsgrenze. Es dokumentiert tatsächlich Getestetes, trennt Schlussfolgerung und Beobachtung und schützt vertrauliche Details. Schädliche Ausnutzung oder die Weitergabe sensiblen Codes an einen unzulässigen gehosteten Dienst sollten nicht nötig sein.
Filter sollten fehlende Evidenz erkennen, nicht KI-artige Sprache als Ungültigkeitsbeweis behandeln. Es gibt keinen verlässlichen Stiltest für echte Schwachstellen. Beschwerdewege und Spezialisten sind wichtig, weil ungewöhnliche Angriffsketten nicht immer in Vorlagen passen.
Googles nächstes Update wird zeigen, ob klarere Evidenzregeln oder weniger Teilnehmer die Lösung sind. Sinnvolle Ergebnisse umfassen bestätigte und doppelte Meldungen, Prüf- und Reparaturzeit, Arbeitslast und Fehlablehnungen, nicht bloß weniger Einreichungen. Erfahrungen unterscheiden sich: Mozilla berichtete zuvor beispielsweise über eine stabile Ablehnungsquote ungültiger Berichte. Google definiert nicht das ganze Ökosystem.
Die konstruktive Grenze verläuft zwischen Entdeckungs- und Einreichungsskalierung. Agenten dürfen breit suchen; Menschen sollten validierte, deduplizierte Funde mit verantwortlichen Eigentümern erhalten. Googles Pause beweist nicht, dass KI keine Fehler findet. Sie zeigt, dass unbegrenzte Hypothesen erst durch Nachweise zu Sicherheitswert werden.
Quellen
Google-OSS-Regeln · Arbeitslast der Maintainer · Untersuchung falscher Berichte · Validierte Mozilla-Funde · Curl-Prämienentscheidung · Technische Wissensbasis · Bericht zur Google-Pause · Frühere Google-Regeländerungen · Google-Prämien 2025 · HackerOne-Volumenanalyse · Linux-Melderegeln · TechCrunch zur Google-Pause · Techmeme zur Google-Pause