Aussetzung des Google OSS VRP offenbart die versteckten Kosten von KI-Fehlerberichten
Google nahm ab dem 1. Oktober keine neuen Meldungen zu Produktschwachstellen mehr über sein Open-Source-Bug-Bounty-Programm an, nachdem ungültige KI-Berichte den Prüfprozess überlastet hatten. Die Aussetzung des Google OSS VRP beendet nicht jeden Teil des Programms. Sie schließt jedoch einen wichtigen Meldeweg, bis Google eine Neugestaltung abgeschlossen hat.
Das unmittelbare Problem besteht nicht darin, dass künstliche Intelligenz keine Softwarefehler finden kann. KI-Systeme entdecken bereits valide Schwachstellen in großen, intensiv geprüften Codebasen. Das Problem ist, dass die Erstellung eines plausiblen Berichts inzwischen deutlich weniger kostet als der Nachweis seiner Sicherheitsauswirkungen.
Dieses Ungleichgewicht hat die Schwachstellentriage zur knappen Ressource gemacht. Google muss echte Funde von halluzinierten Angriffspfaden, nicht erreichbarem Code, Duplikaten und gewöhnlichen Programmierfehlern trennen. GitHub, Linux-Maintainer und kleinere Open-Source-Projekte stehen unter demselben Druck.
Google zufolge werden Berichte, die vor Ablauf der Frist eingereicht wurden, weiterhin geprüft. Berichte zu Lieferketten bleiben möglich, während bestimmte Schwachstellen in Google-Cloud-Repositories über das Cloud Vulnerability Reward Program gemeldet werden können. Das Unternehmen erwartet bis zum ersten Quartal 2027 ein weiteres Update.
Die Pause legt einen aufschlussreichen Konflikt offen. KI verspricht, defensive Sicherheitsforschung zu skalieren, doch ungeprüfte Automatisierung kann die menschliche Aufmerksamkeit verbrauchen, die für die Behebung echter Schwachstellen erforderlich ist. Die Zukunft der KI-gestützten Fehlersuche hängt nun weniger von der reinen Menge der Entdeckungen als von der Qualität der Belege ab.
Die Aussetzung des Google OSS VRP ist begrenzt, aber unmittelbar
Google hat eine Einreichungskategorie eingefroren, seine breitere Beziehung zu externen Sicherheitsforschern jedoch nicht aufgegeben.
Betroffen ist das Open Source Software Vulnerability Reward Program, allgemein OSS VRP genannt. Google führte es 2022 ein, um Forschende zu belohnen, die Schwachstellen in berechtigten Open-Source-Projekten verantwortungsvoll offenlegen.
Das Programm umfasst Software in öffentlichen Repositories von Google sowie ausgewählte Projekte, die andernorts gehostet werden. Sein Umfang schloss sowohl Produktschwachstellen als auch Kompromittierungen der Lieferkette ein. Diese Kategorien behandeln unterschiedliche Risiken und folgen nun unterschiedlichen Meldewegen.
Produktschwachstellen betreffen Fehler im Code, in der Logik oder im Design eines Projekts. Ein überzeugender Bericht muss zeigen, dass Angreifer den Fehler erreichen und daraus relevante Sicherheitsfolgen erzeugen können. Allein die Identifizierung einer unsicher wirkenden Funktion belegt keine Ausnutzbarkeit.
Berichte zur Lieferkette betreffen Bedrohungen dafür, wie Software erstellt, paketiert, signiert oder verteilt wird. Eine kompromittierte Release-Pipeline kann schädlichen Code verbreiten, selbst wenn der zugrunde liegende Quellcode legitim erscheint. Google hat diese Meldekategorie offen gehalten.
Die Aussetzung gilt für neue Berichte zu Produktschwachstellen, die am oder nach dem 1. Oktober 2026 eingereicht werden. Frühere Einreichungen bleiben nach dem bisherigen Verfahren prüfberechtigt. Google verwies Forschende zudem auf seine anderen Vulnerability-Reward-Programme, sofern diese anwendbar sind.
Einige Berichte zu Google-Cloud-Repositories können weiterhin über das Cloud VRP qualifiziert sein. Diese Ausnahme hängt davon ab, ob das Problem ein Google-Cloud-Produkt betrifft, und nicht allein davon, ob das Quell-Repository Google gehört.
Google kündigte die Änderung über seinen Bug-Hunters-Account auf X an. Laut dem ersten ausführlichen veröffentlichten Bericht begründete das Unternehmen seine Entscheidung mit einem Zustrom ungültiger KI-gesteuerter Einreichungen.
Der Pause gingen Monate schrittweiser Verschärfungen voraus, nicht etwa eine plötzliche Kehrtwende. In einem Regel-Update vom April beschrieb Google einen Anstieg minderwertiger und ungültiger Berichte im OSS VRP.
Google identifizierte zwei wiederkehrende Muster. Einige Einreichungen enthielten halluzinierte Erklärungen dazu, wie eine angebliche Schwachstelle ausgelöst werden könne. Andere fanden tatsächliche Codierungsfehler, konnten jedoch keinen erreichbaren Code oder relevante Sicherheitsauswirkungen nachweisen.
Diese Unterscheidung ist wichtig, da Softwarefehler und Sicherheitslücken nicht austauschbar sind. Ein Absturz in einem nicht erreichbaren Testwerkzeug hat andere Folgen als Remote Code Execution in einem Produktionsdienst.
Google hatte bereits aufgehört, Belohnungen oder Anerkennung für bestimmte Produktschwachstellen und andere Sicherheitsprobleme in Projekten niedrigerer Prioritätsstufen zu gewähren. Zudem betonte das Unternehmen umsetzbare Funde, verifizierte Reproduktionsschritte und Wirkungsnachweise.
Die Maßnahme vom Oktober erweitert daher bestehende Bemühungen zur Verringerung von Rauschen. Statt die Teilnahmebedingungen anzupassen, während weiterhin Berichte eingehen, hat Google den betroffenen Eingangskanal während einer umfassenderen Neugestaltung geschlossen.
Das Unternehmen hat weder die genaue Zahl abgelehnter Berichte noch die Größe seines Rückstaus oder seine Annahmequote veröffentlicht. Behauptungen über Tausende Einreichungen bleiben berichtete Zahlen und keine vollständigen Programmstatistiken.
Diese fehlenden Daten begrenzen externe Analysen. Doch die Abfolge aus Regeländerungen, öffentlichen Warnungen und dem endgültigen Einfrieren zeigt, dass schrittweise Filterung das Arbeitslastproblem nicht löste.
Warum ungültige KI-Fehlerberichte die Sicherheitstriasche beeinträchtigen
KI verändert die Ökonomie der Berichterstattung, weil sich Einreichungen automatisch skalieren lassen, während die Validierung weiterhin knappes menschliches Urteilsvermögen erfordert.
Traditionelle Schwachstellenforschung erfordert mehrere aufwendige Schritte. Forschende müssen das Ziel verstehen, eine Schwäche identifizieren, einen reproduzierbaren Angriff entwickeln, die Auswirkungen bewerten und das Ergebnis klar kommunizieren.
Große Sprachmodelle können Teile dieser Arbeit beschleunigen. Sie können Quellcode untersuchen, riskante Datenflüsse vorschlagen, Testfälle entwerfen und grobe Notizen in ausgefeilte Prosa verwandeln. Automatisierte Agenten können diese Schritte über viele Repositories hinweg wiederholen.
Dieselben Werkzeuge können auch überzeugende, aber falsche Erklärungen liefern. Ein Modell kann annehmen, dass Angreifer eine Eingabe kontrollieren, die in Wirklichkeit vertrauenswürdig bleibt. Es kann eine Berechtigungsprüfung übersehen, eine Bereitstellungskonfiguration missverstehen oder einen erreichbaren Ausführungspfad erfinden.
Nach der Einreichung werden diese Fehler kostspielig. Ein Sicherheitsingenieur kann einen glaubwürdig wirkenden Bericht nicht allein aufgrund seines Tons zurückweisen. Er muss den zitierten Code prüfen, die Bedingungen reproduzieren, den Datenfluss nachverfolgen und testen, ob die behauptete Auswirkung tatsächlich besteht.
Ein falscher Bericht kann daher Minuten zur Erstellung und Stunden zur Zurückweisung benötigen. Tausend ähnliche Berichte verwandeln dieses Ungleichgewicht in eine operative Denial-of-Service-Situation, selbst ohne böswillige Absicht.
Auch die Aufbereitung eines Berichts kann das Problem verschärfen. Sprachmodelle erzeugen mühelos lange Schwachstellenerzählungen, Schweregradkennzeichnungen, Angriffsdiagramme und Hinweise zur Behebung. Keine dieser Ergänzungen ersetzt eine funktionierende Reproduktion.
Ausformulierte Sprache kann die Triagekosten sogar erhöhen. Prüfer müssen die tatsächliche Behauptung in Seiten generierten Kontexts finden. Sie müssen außerdem bestimmen, welche Aussagen aus Tests stammen und welche aus Modellinferenz.
Googles frühere Regeln konzentrierten sich auf diesen Unterschied zwischen Erkennung und Validierung. Eine Warnung eines statischen Analysators kann verdächtigen Code identifizieren. Sie beweist nicht automatisch, dass der Code eine ausnutzbare Verletzung einer Sicherheitsgrenze verursacht.
Erreichbarkeit ist ein wesentlicher Test. Prüfer benötigen Belege dafür, dass nicht vertrauenswürdige Eingaben unter realistischen Bedingungen zur gefährlichen Operation gelangen können. Berichte müssen auch Bereinigung, Berechtigungen, Konfiguration und vorhandene Schutzmaßnahmen berücksichtigen.
Die Auswirkung ist ein weiterer Test. Ein Pufferüberlauf klingt schwerwiegend, doch sein Ort und die umgebenden Kontrollen bestimmen, was ein Angreifer erreichen kann. Manche Fehler beenden lediglich einen isolierten Prozess, ohne Daten oder Kontrolle preiszugeben.
Auch Neuheit spielt eine Rolle. Automatisierte Systeme können bekannte Probleme erneut entdecken, bereits zurückgewiesene Theorien wiederholen oder mehrere Beschreibungen derselben Ursache erzeugen. Jedes Duplikat verbraucht dennoch Kapazität bei Eingang und Prüfung.
Diese Arbeitslast liegt bei spezialisierten Personen. Erfahrene Maintainer und Sicherheitsingenieure verstehen architektonische Annahmen, die Modelle oft übersehen. Wenn sie in repetitive Validierung eingebunden werden, verzögern sich Patches, Audits, Designprüfungen und Incident Response.
Die Opportunitätskosten reichen über Google hinaus. Open-Source-Projekte verfügen oft über kleine Maintainer-Gruppen, selbst wenn ihr Code weit verbreitete Dienste unterstützt. Eine automatisierte Berichtskampagne kann ihre gesamte Sicherheitskapazität übersteigen.
Teams können Kontext bewahren, indem sie Entscheidungen, Reproduktionen und frühere Funde in einer durchsuchbaren Engineering-Wissensdatenbank festhalten. Diese Praxis reduziert wiederholte Untersuchungen, kann den Bedarf an fachkundiger Verifizierung jedoch nicht beseitigen.
Die Pause des Google-Bug-Bounty-Programms macht diese Arbeitsbeschränkung sichtbar. Sicherheitsprogramme waren auf Einreichungen ausgelegt, die nennenswerte Forschungsarbeit der Einreichenden enthalten. KI ermöglicht es den Einreichenden, einen großen Teil dieser Arbeit auf das empfangende Team zu übertragen.
KI-Fehlerberichte schaffen ein Qualitätsproblem, kein KI-Verbot
Der zentrale Konflikt besteht zwischen verifizierter Forschung und ungeprüfter Automatisierung, nicht zwischen menschlichen Forschenden und künstlicher Intelligenz.
Google hat nicht argumentiert, dass Forschende KI vollständig vermeiden sollten. Nach seiner erklärten Position müssen Menschen KI-Ausgaben bei der Forschung validieren. Diese Anforderung behandelt KI als Werkzeug und nicht als verantwortliche berichtende Instanz.
Eine nützliche KI-gestützte Einreichung kann weiterhin direkte Belege enthalten. Forschende können betroffene Versionen, exakte Befehle, minimierte Testfälle, Logs, Screenshots und beobachtete Ergebnisse bereitstellen. Sie können auch die verletzte Sicherheitsgrenze erläutern.
Die entscheidende Frage ist, ob eine Person die Behauptung bestätigt hat. Eine modellgenerierte Hypothese wird wertvoll, wenn Tests beweisen, dass der relevante Code erreichbar ist und das Ergebnis Vertraulichkeit, Integrität oder Verfügbarkeit beeinträchtigt.
Dieser Standard schützt legitime Automatisierung. Fuzzer erzeugen seit Jahren Sicherheitsfunde, indem sie unerwartete Eingaben senden und Fehler aufzeichnen. Ihr Wert beruht auf konkreten, reproduzierbaren Ergebnissen statt auf überzeugenden Beschreibungen.
KI-Agenten können dieses Modell erweitern. Sie können über Quellcode schlussfolgern, Harnesses erstellen, Abstürze untersuchen und Patches vorschlagen. Ihr breiterer Suchraum kann Fehler aufdecken, die herkömmliche Werkzeuge übersehen.
Dennoch führen Reasoning-Systeme einen weiteren Fehlermodus ein. Sie können fehlende Belege mit plausibler Sprache überbrücken. Ein herkömmlicher Scanner meldet normalerweise das erkannte Muster, während ein Sprachmodell eine vollständige Angriffserzählung erfinden kann.
Dieser Unterschied erklärt, warum Offenlegungsprogramme Berichte nicht einfach nach Sprachgewandtheit bewerten können. Prüfer benötigen Artefakte, die an beobachtbares Verhalten gebunden sind. Behauptungen über theoretische Folgen verdienen weniger Vertrauen als nachgewiesene Ergebnisse.
Der stärkste Einwand gegen eine pauschale Ablehnung von KI sind erfolgreiche KI-Sicherheitsarbeiten. KI-Systeme haben echte Schwachstellen in großen Open-Source-Projekten gefunden, einschließlich Fehlern, die menschliche Prüfer übersehen hatten.
Diese Ergebnisse zeigen, warum ein Verbot aller KI-gestützten Berichte kurzsichtig wäre. Defensive Teams wünschen sich breitere Abdeckung, insbesondere über große Abhängigkeitsgraphen und reife Codebasen hinweg. Sie wollen keine unbegrenzte, ungetestete Spekulation.
Google selbst setzt KI in defensiver Sicherheitsforschung ein. Zu seiner breiteren Sicherheitsarbeit gehören KI-gestützte Schwachstellenentdeckung und Open-Source-Fuzzing. Der Einwand des Unternehmens betrifft die Qualität der Validierung an der Grenze der Berichterstattung.
Diese Grenze wirft eine Frage der Verantwortlichkeit auf. Wenn ein autonomer Agent einen Bericht einreicht, wer beantwortet Rückfragen? Jemand muss Annahmen klären, die Reproduktion anpassen und beobachtetes von vorhergesagtem Verhalten unterscheiden.
Ein Bericht ohne verantwortlichen Forschenden verlagert diese Aufgaben auf den Maintainer. Der Empfänger wird dafür verantwortlich, die Untersuchung abzuschließen, die der Einreichende angestoßen hat.
Eine klare Offenlegung des KI-Einsatzes kann helfen, doch Offenlegung allein kann keine Qualität gewährleisten. Ein von Menschen verfasster Bericht kann ebenfalls falsch sein. Ein KI-generierter Bericht kann korrekt, präzise und gründlich getestet sein.
Programme benötigen daher evidenzbasierte Hürden statt Stil-Detektoren. KI-Textklassifikatoren können technische Texte falsch einordnen, insbesondere wenn Forschende Vorlagen verwenden oder in einer Zweitsprache schreiben.
Ein besseres Eingangssystem prüft den Gehalt des Berichts. Es kann eine minimale Reproduktion, Umgebungsdetails, betroffene Commits, einen Nachweis der Erreichbarkeit und eine direkte Erklärung der Fähigkeiten eines Angreifers verlangen.
Die Aussetzung des Google OSS VRP verschafft dem Unternehmen Zeit, solche Hürden zu gestalten. Das Risiko besteht darin, dass ein strengeres System auch qualifizierte Neulinge ohne Reputation, aber mit einem validen Fund ausschließt.
Dieser Zielkonflikt lässt sich nicht auflösen. Offene Programme ziehen unerwartete Entdeckungen an, weil sich jeder beteiligen kann. Zugangsbeschränkungen erhöhen die durchschnittliche Qualität, verringern jedoch die Chance, dass ein unbekannter Forschender das richtige Team erreicht.
GitHub und Open-Source-Maintainer verschärfen dieselbe Zugangshürde
Googles Entscheidung ist Teil eines branchenweiten Wandels von offenen Eingängen hin zu Reputation, Nachweisen und engeren Einreichungskanälen.
GitHub sah sich 2026 ebenfalls mit einem Rückstau an wenig aufwendigen und KI-generierten Berichten konfrontiert. Das Unternehmen reagierte mit einer Umstrukturierung seines Bounty-Programms und schuf separate Wege für öffentliche und eingeladene Forschende.
Das öffentliche Programm führte eine HackerOne-Signalanforderung ein, die die bisherige Plattformhistorie eines Forschenden als Maß für die Teilnahmeberechtigung nutzt. Das Programm für Eingeladene bietet einen eigenen Weg für Forschende mit etabliertem Vertrauen.
GitHub erklärte, sein Ziel sei es, das Volumen wenig aufwendiger Meldungen zu senken und gleichzeitig ernsthafte externe Forschung zu erhalten. Die Ankündigung der Umstrukturierung wandte die neue Struktur auf Berichte an, die ab dem 27. Juli 2026 eingereicht wurden.
Frühere Leitlinien erläuterten, welche Nachweise die Plattform als nützlich betrachtete. Ein starker Bericht benötigte eine prägnante Zusammenfassung, Reproduktionsschritte mit unterstützenden Artefakten und eine klare Aussage über die erreichbaren Auswirkungen für Angreifer.
GitHub warnte außerdem, dass theoretische Erzählungen und KI-generiertes Füllmaterial die Triage verlangsamten. Das Problem waren nicht nur ungenaue Inhalte. Übermäßige Erläuterungen können den eigentlichen Fund verschleiern und die Prüfung verzögern.
Google und GitHub wählten unterschiedliche unmittelbare Reaktionen. GitHub behielt einen öffentlichen Weg mit stärkeren Reputations- und Qualitätshürden bei. Google pausierte eine OSS-VRP-Kategorie, während andere Vulnerability-Programme verfügbar blieben.
Beide Ansätze schützen die Aufmerksamkeit der Prüfenden. Sie schaffen jedoch auch Hürden für neue Forschende, die noch keine Plattformreputation aufgebaut haben. Ein hervorragender erster Bericht kann von jemandem ohne lange Bounty-Historie stammen.
Open-Source-Maintainer stehen vor einer noch schärferen Variante dieses Problems. Viele Projekte verfügen weder über fest zugewiesenes Sicherheitspersonal noch über bezahlte Triage-Teams oder formelle Einreichungsinfrastruktur. Ein Maintainer prüft Berichte möglicherweise in seiner Freizeit.
Branchenleitlinien sehen die Verantwortung zunehmend auf beiden Seiten. Die Open Source Security Foundation rät Forschenden, Funde zu verifizieren, Projektrichtlinien zu verstehen und klar offenzulegen, wie KI zur Arbeit beigetragen hat.
Ihre Leitlinien für Maintainer erkennen ebenfalls an, dass KI legitime defensive Analysen unterstützen kann. Die empfohlene Reaktion konzentriert sich auf sichere Integration und menschliche Prüfung.
Das breitere Muster ähnelt der Spam-Bekämpfung. Wenn das Versenden nahezu kostenlos wird, müssen Empfänger Filter, Reputationssignale, Ratenlimits oder Kosten für Einreichungen einführen. Andernfalls überwältigt geringwertiges Volumen wertvolle Kommunikation.
Bug-Bounty-Programme können gewöhnliche Spamfilter nicht einfach exakt übernehmen. Sicherheitsberichte enthalten neuartige technische Details und treffen oft von unbekannten Forschenden ein. Ungewöhnliche Inhalte zu aggressiv abzulehnen, kann die wichtigste Entdeckung verbergen.
Programme werden wahrscheinlich mehrere Kontrollen kombinieren. Strukturierte Formulare können konkrete Antworten erzwingen. Automatisierte Prüfungen können testen, ob erforderliche Artefakte vorhanden sind. Reputation kann Einreichungslimits statt einer absoluten Teilnahmeberechtigung bestimmen.
Ratenlimits könnten für autonome Agenten besonders wichtig werden. Eine Person kann mehrere maschinell generierte Kandidaten prüfen und nur die stärksten einreichen. Ein unbeaufsichtigtes System kann ein Programm überfluten, bevor Maintainer Rückmeldung geben.
Einlagen oder erstattungsfähige Einreichungsbürgschaften würden stärkere Kosten schaffen, werfen jedoch Zugangsfragen auf. Forschende in Regionen mit niedrigeren Einkommen könnten unverhältnismäßige Hürden erleben. Auch die rechtliche und administrative Komplexität würde steigen.
Private oder rein einladungsbasierte Programme vermeiden öffentliches Volumen, verlieren aber breite Beteiligung. Sie konzentrieren Vertrauen auf bekannte Forschende und übersehen möglicherweise Außenstehende mit Spezialwissen über eine bestimmte Komponente.
Googles Neugestaltung hat daher Auswirkungen über ein einzelnes Unternehmen hinaus. Andere Programmbetreiber werden beobachten, ob sie das Signal wiederherstellt, ohne neuen Talenten die Tür zu verschließen.
Strengere Filter können auch echte Schwachstellen verbergen
KI-Rauschen zu reduzieren ist notwendig, doch jeder Filter schafft die Möglichkeit, dass ein valider, unbekannter Bericht nie den richtigen Engineer erreicht.
Google hat die Gründe für die Pause beschrieben, aber keine vollständigen Leistungsdaten veröffentlicht. Außenstehende können die False-Positive-Raten vor und nach der Einführung von KI nicht vergleichen oder die tatsächliche Schwere des Rückstaus messen.
Ohne diese Zahlen bleiben mehrere Interpretationen möglich. KI-generierte Einreichungen könnten die Warteschlange dominieren, oder eine kleinere Gruppe wiederholter Melder könnte den Großteil der Belastung verursachen. Unterschiedliche Ursachen erfordern unterschiedliche Kontrollen.
Auch die Qualität der zugrunde liegenden Modelle ist relevant. Eine Richtlinie, die auf aktuellen Halluzinationsraten basiert, kann schnell veralten. Bessere Agenten können stärkere Reproduktionen erstellen, aber auch größere Berichtsmengen generieren.
Die Programmgestaltung muss Zuversicht von Belegen unterscheiden. Ein Agent, der einer Ausnutzung eine hohe Wahrscheinlichkeit zuschreibt, hat die Ausnutzung nicht bewiesen. Umgekehrt kann ein unvollständiger Bericht trotzdem eine schwere Schwachstelle beschreiben, die Nachverfolgung verdient.
Neue Forschende reichen oft unvollkommene Berichte ein, weil ihnen Erfahrung mit Offenlegung fehlt. Ihre Texte können geringwertigen automatisierten Ausgaben ähneln, selbst wenn die zugrunde liegende Beobachtung echt ist.
Sprache und Barrierefreiheit schaffen ähnliche Risiken. Poliertes Englisch zu verlangen, kann Forschende mit tiefem technischen Wissen benachteiligen. Formulare sollten spezifische Belege verlangen, ohne Stil zu einem Ersatzmaß für Glaubwürdigkeit zu machen.
Reputationshürden verstärken zudem bisherigen Zugang. Etablierte Forschende erhalten mehr Möglichkeiten, Signale aufzubauen, während Neulinge Schwierigkeiten beim Einstieg haben. Ein geschlossener Kreislauf kann die Effizienz steigern, aber die Vielfalt schwächen.
Automatisierung auf der Empfängerseite bringt eine weitere Ungewissheit mit sich. Google könnte Modelle einsetzen, um Berichte zusammenzufassen, zu deduplizieren oder zu priorisieren. Diese Systeme müssen geprüft werden, weil ein False Negative andere Folgen hat als ein False Positive.
Ein False Positive verschwendet Zeit der Prüfenden. Ein False Negative kann eine Schwachstelle unentdeckt lassen. Eingangssysteme sollten daher Routing und Belegprüfungen eher automatisieren als endgültige Ablehnungen.
Einspruchsmöglichkeiten bieten einen Schutz. Ein abgelehnter Forschender sollte verstehen, welches Element fehlgeschlagen ist und ob zusätzliche Belege den Bericht wieder öffnen können. Allgemeine Ablehnungsnachrichten fördern wiederholte Einreichungen und öffentliche Frustration.
Transparente Beispiele können das Verhalten ebenfalls verbessern. Programme können anonymisierte Fälle veröffentlichen, die nicht erreichbaren Code, unbelegte Wirkungsbehauptungen, doppelte Ursachen und akzeptable Reproduktionen zeigen.
Google bietet bereits Meldeleitlinien für seine Vulnerability-Programme an. Sein Qualitätsrahmen betont Zielinformationen, Reproduzierbarkeit, Auswirkungen und Kommunikation.
Die Neugestaltung muss entscheiden, ob diese Standards zu maschinell durchgesetzten Voraussetzungen werden. Sie muss außerdem bestimmen, welche Berichte trotz eines fehlenden formalen Feldes menschliches Ermessen verdienen.
Es besteht noch eine weitere Gefahr darin, jede unerwünschte Einreichung als KI-Schrott zu bezeichnen. Das Etikett kann echte Meinungsverschiedenheiten über Bedrohungsmodelle verschleiern. Forschende und Anbieter bewerten die Ausnutzbarkeit oft unterschiedlich.
Ein Unternehmen kann ein Problem ablehnen, weil ein Angreifer Nutzerinteraktion benötigt. Ein Forschender kann argumentieren, dass diese Interaktion weiterhin realistisch bleibt. Solche Streitfälle gab es bereits vor generativer KI und sie lassen sich nicht durch Autorenerkennung lösen.
Dieselbe Vorsicht gilt für gewöhnliche Codefehler. Manche Bugs haben keine unmittelbaren Auswirkungen, werden aber nach einer weiteren Produktänderung gefährlich. Programme benötigen Grenzen, doch diese Grenzen sollten nicht mit universellen Urteilen über die Schwere verwechselt werden.
Die Aussetzung ist daher ein Triage-Eingriff und kein Beweis dafür, dass die betroffenen Repositories sicherer geworden sind. Schwachstellen bestehen weiter, während ein Meldeweg geschlossen bleibt.
Forschende müssen einen anderen geeigneten Kanal identifizieren oder das relevante Projekt direkt kontaktieren. Fragmentierte Offenlegungswege können Verzögerungen, versehentliche Veröffentlichung und doppelte Arbeit erhöhen.
Google kann dieses Risiko senken, indem es ausgeschlossene Berichte klar weiterleitet. Sein öffentliches Programmverzeichnis trennt bereits Google-, Cloud-, Chrome-, Android-, KI-, Missbrauchs- und Open-Source-Geltungsbereiche.
Die Neugestaltung gelingt nur, wenn valide Forschende das richtige Ziel vorhersehen können. Eine kleinere Warteschlange bedeutet wenig, wenn ernsthafte Berichte zwischen überlappenden Programmregeln verschwinden.
Worauf vor der Wiedereröffnung von Produktmeldungen bei Google zu achten ist
Der nächste Test besteht darin, ob Google eine offene Einreichungsbox durch ein System ersetzt, das Belege überprüft, ohne unbekannte Forschende zum Schweigen zu bringen.
Das erste Signal ist das versprochene Update bis zum ersten Quartal 2027. Google sollte klarstellen, ob Einreichungen zu Produktschwachstellen wieder geöffnet, an einen anderen Ort verlagert oder über ein Verfahren mit eingeschränktem Zugang zurückkehren.
Eine Wiedereröffnung mit strukturierten Nachweisanforderungen würde die Einschätzung stützen, dass die Aussetzung eine vorübergehende Triage-Maßnahme war. Eine unbefristete Schließung würde zeigen, dass Google das alte öffentliche Modell nicht länger für tragfähig hält.
Das zweite Signal ist die Gestaltung der Eingangshürde. Erforderliche Reproduktionen, betroffene Versionen, getestete Commits, Ausführungsspuren und prägnante Aussagen zu Auswirkungen würden die dokumentierten Fehlermuster direkt adressieren.
Reine Reputationsbeschränkungen wären eine andere Entscheidung. Sie könnten das Volumen schnell senken, würden aber der Historie der Forschenden mehr Gewicht geben als den Belegen in jedem einzelnen Bericht.
Googles Umgang mit autonomen Agenten wird besonders wichtig sein. Das Unternehmen könnte verlangen, dass eine namentlich genannte Person bestätigt, jede Einreichung reproduziert zu haben. Es könnte auch Ratenlimits für maschinell unterstützte Meldungen festlegen.
Eine sinnvolle Richtlinie sollte KI-Unterstützung von unbeaufsichtigter Masseneinreichung trennen. Forschende verwenden routinemäßig Automatisierung, Debugger, Fuzzer, Scanner und Sprachmodelle. Entscheidend ist, wer die Behauptung validiert und verantwortet.
Das dritte Signal ist, ob sich der Rückstau verbessert, ohne bestätigte Entdeckungen zu verringern. Google hat für diesen Vergleich nicht genügend Daten veröffentlicht, doch künftige Transparenz würde anderen Programmen helfen, aus der Neugestaltung zu lernen.
Nützliche Kennzahlen wären Einreichungsvolumen, Validierungszeit, Duplikatraten, akzeptierte Funde, Einsprüche von Meldenden und der Anteil der Berichte mit funktionierenden Reproduktionen. Aggregierte Zahlen könnten sensible Details schützen.
Forschende sollten auch Googles andere VRPs im Blick behalten. Wenn ungültige KI-Fehlerberichte in Cloud-, Chrome- oder allgemeine Google-Kanäle abwandern, hat die Aussetzung die Arbeitslast lediglich verlagert, statt sie zu lösen.
Das umfassendere Bug-Bounty-System des Unternehmens bleibt aktiv. Googles Programmverzeichnis leitet berechtigte Sicherheitsprobleme weiterhin an mehrere spezialisierte Programme weiter.
Verantwortliche außerhalb von Google sollten nicht auf die endgültige Richtlinie warten. Sie können akzeptierte Nachweise definieren, Bedrohungsmodelle veröffentlichen, automatisierte Einreichungen begrenzen und Vorlagen schaffen, die Beobachtungen von abgeleiteten Auswirkungen trennen.
Auch Forschende können sich anpassen. Vor einer Meldung sollten sie das Verhalten reproduzieren, den Testfall minimieren, die betroffene Revision bestätigen und erläutern, welchen Zugang ein Angreifer benötigt.
Sie sollten generierten Hintergrund entfernen, der den Befund nicht stützt. Ein kurzer Bericht mit direkten Belegen lässt sich leichter prüfen als ein ausgefeilter Essay, der auf einer unsicheren Annahme aufbaut.
KI-gestützte Sicherheitsforschung wird weiter zunehmen, weil ihre legitimen Vorteile erheblich sind. Modelle können mehr Code durchsuchen, zielgerichtete Tests erzeugen und Ermittlern helfen, unbekannte Komponenten miteinander zu verknüpfen.
Doch das Entdeckungsvolumen ist nicht länger der beste Maßstab für Fortschritt. Ein Bericht wird erst dann nützlich, wenn er Verantwortlichen genügend vertrauenswürdige Belege zum Handeln liefert.
Die Aussetzung des Google OSS VRP markiert den Zeitpunkt, an dem diese Unterscheidung nicht mehr zu ignorieren war. Das Design des nächsten Programms muss verifizierte Erkenntnisse belohnen, den Zugang bewahren und menschliche Aufmerksamkeit auf reale Risiken richten.
Bevor Sie einen weiteren KI-gestützten Fund einreichen, stellen Sie sich eine schwierigere Frage als die, ob das Modell verdächtigen Code gefunden hat: Kann ein anderer Ingenieur die Sicherheitsauswirkung anhand der vorgelegten Belege reproduzieren?
