Die Aussetzung des Google OSS VRP zeigt: KI-Fehlerberichte haben ein Verifizierungsproblem

Google hat am 1. Oktober eine Kategorie seines Open-Source-Schwachstellenprogramms ausgesetzt, nachdem ungültige KI-Berichte den Prüfprozess Berichten zufolge überlastet hatten.

Die Aussetzung des Google OSS VRP stoppt neue Einreichungen zu „Product Vulnerability“, während das Unternehmen diesen Teil des Programms neu gestaltet. Google erwartet ein Update im ersten Quartal 2027.

Die Entscheidung schließt nicht alle Schwachstellenprogramme von Google. Sie verbietet Forschenden auch nicht, künstliche Intelligenz zur Untersuchung von Code einzusetzen.

Stattdessen legt sie einen wachsenden Konflikt zwischen automatisierter Entdeckung und menschlicher Verifizierung offen. KI kann mögliche Befunde deutlich schneller erzeugen, als Maintainer sie reproduzieren, bewerten und beheben können.

Googles Schritt folgt auf Monate zunehmenden Drucks in der Open-Source-Sicherheit. Linux-Maintainer und andere Projekte sahen sich ähnlichen Wellen doppelter, spekulativer oder unzureichend getesteter Berichte gegenüber.

Dieses breitere Muster ist wichtiger als ein einzelnes pausiertes Einreichungsformular. Sicherheitsprogramme belohnen traditionell Forschende dafür, Probleme zu finden, die interne Teams übersehen haben. KI verändert dieses Modell, indem sie die Erzeugung potenzieller Kandidaten ungewöhnlich günstig macht.

Die knappe Ressource ist nicht länger der erste Verdacht. Es ist die fachkundige Aufmerksamkeit, die erforderlich ist, um nachzuweisen, dass ein Fehler erreichbar, ausnutzbar und für ein reales Bedrohungsmodell relevant ist.

Was die Aussetzung des Google OSS VRP tatsächlich verändert

Google hat eine Berichtskategorie pausiert, nicht die Open-Source-Schwachstellenforschung aufgegeben oder seinen gesamten Bounty-Betrieb geschlossen.

Das Open Source Software Vulnerability Reward Program, bekannt als OSS VRP, deckt qualifizierte Sicherheitsprobleme in Google-eigenen Open-Source-Repositories ab. Google führte das Programm 2022 ein.

Berichte zu Produktschwachstellen identifizieren Fehler im Code, in der Logik oder im Design eines Projekts. Ein gültiger Bericht muss mehr leisten, als auf verdächtigen Code hinzuweisen.

Forschende müssen in der Regel eine betroffene Version, einen erreichbaren Ausführungspfad, Reproduktionsschritte und eine relevante Sicherheitsfolge zeigen. Diese Anforderungen trennen ausnutzbare Schwachstellen von gewöhnlichen Programmierfehlern.

Laut den Details zur Aussetzung trat die Pause mit Googles Ankündigung am 1. Oktober in Kraft. Zuvor eingereichte Berichte zu Produktschwachstellen bleiben prüfberechtigt.

Berichte zur Lieferkette bleiben ebenfalls möglich. Sie betreffen Kompromittierungen, die beeinflussen, wie Softwareabhängigkeiten, Quellcode, Builds oder Releases Nutzende erreichen.

Einige Schwachstellen in Google-Cloud-Produkten können weiterhin über das separate Cloud VRP qualifiziert sein. Die Berechtigung hängt vom Repository und dessen Verbindung zu einem abgedeckten Cloud-Produkt ab.

Forschende können außerdem an Googles anderen Prämienprogrammen teilnehmen. Dazu gehören Programme für Chrome, Android, Google-Geräte, Cloud-Dienste und spezielle KI-Sicherheitsprobleme.

Diese Abgrenzung des Geltungsbereichs ist wichtig. Den Schritt als vollständige Schließung zu bezeichnen, würde das Ereignis überzeichnen und Googles gezieltere Reaktion verschleiern.

Das Unternehmen schließt faktisch einen Eingangskanal mit hohem Volumen, während engere Kanäle verfügbar bleiben. Es plant, diesen Kanal neu zu gestalten, bevor es über dessen Zukunft spricht.

Der genaue Ersatz bleibt unbekannt. Google hat nicht öffentlich erläutert, ob es strengere Anforderungen an Identität, Reproduktion, Rate Limits oder Belege einführen wird.

Google hatte das Programm bereits vor der Aussetzung verschärft. Seine OSS VRP-Regeln verlangten von Forschenden, KI-gestützte Befunde zu validieren und tatsächliche Sicherheitsauswirkungen nachzuweisen.

Die Regeln beschrieben mehrere wiederkehrende Probleme. Einige KI-generierte Berichte enthielten falsche Auslösebedingungen oder erfundene technische Details.

Andere Berichte identifizierten reale Codierungsfehler, konnten aber keine Sicherheitsfolgen belegen. Ein Buffer Overflow könnte beispielsweise nur in nicht erreichbarem Code oder hinter einer wirksamen Sicherheitsgrenze existieren.

Google beendete außerdem finanzielle Belohnungen und öffentliche Anerkennung für bestimmte Produktschwachstellen niedrigerer Priorität und andere Sicherheitsprobleme. Diese Änderung vom April 2026 sollte Anreize für Einreichungen mit geringer Auswirkung beseitigen.

Die spätere Aussetzung deutet darauf hin, dass diese engeren Maßnahmen die Prüfbelastung nicht ausreichend senkten. Google wechselte davon, schwache Berichte zu entmutigen, dazu, die Kategorie vorübergehend nicht mehr anzunehmen.

Die Aussetzung des Google OSS VRP ist daher eine operative Entscheidung. Die Prüfenden des Programms konnten nicht länger jede eingereichte Möglichkeit als erschwinglichen Ausgangspunkt behandeln.

KI-Fehlerberichte haben die Kosten einer Behauptung verändert

KI senkt die Kosten, eine Schwachstelle zu behaupten, ohne die Kosten ihres Nachweises zu senken.

Traditionelle Schwachstellenforschung erforderte erheblichen manuellen Aufwand, bevor Forschende einen plausiblen Bericht erstellen konnten. Sie mussten Code prüfen, Ausführungspfade verstehen und einen Test konstruieren.

Moderne Sprachmodelle und autonome Code-Agenten können Repositories deutlich schneller durchsuchen und Hypothesen erzeugen. Sie können zudem ausgefeilte Berichte erstellen, die sorgfältiger menschlicher Analyse ähneln.

Dieser Eindruck schafft eine gefährliche Asymmetrie. Ein überzeugendes Dokument lässt sich in Sekunden erzeugen, während die Widerlegung seiner Behauptungen Stunden spezialisierter Aufmerksamkeit beanspruchen kann.

Ein Bericht könnte eine verdächtige Speicheroperation identifizieren und Remote Code Execution vorhersagen. Das Modell kann anschließend eine detaillierte Angriffserzählung um diese Vorhersage herum erstellen.

Die betroffene Funktion verarbeitet jedoch möglicherweise nie von Angreifenden kontrollierte Eingaben. Der Compiler könnte den Pfad entfernen, oder vorhandene Validierung könnte den vorgeschlagenen Auslöser blockieren.

Auch das Bedrohungsmodell des Projekts könnte die angenommenen Angreiferrechte ausschließen. In jedem Fall klingt der Bericht ernst, ohne eine Schwachstelle nachzuweisen.

Maintainer können nicht jeden automatisierten Bericht auf den ersten Blick sicher ablehnen. Eine schlecht geschriebene Einreichung kann dennoch einen echten Fehler enthalten, während eine ausgefeilte Einreichung vollständig spekulativ sein kann.

Prüfende müssen den Code untersuchen, die Umgebung nachstellen, die behauptete Eingabe testen und vorhandene Schutzmechanismen bewerten. Möglicherweise müssen sie auch die meldende Person wegen fehlender Belege kontaktieren.

Dieser Aufwand wächst mit jedem Bericht, auch mit ungültigen. Automatisierte Einreichungen verlagern daher die Validierungskosten von den Meldenden auf die Maintainer.

Der Effekt ähnelt eher E-Mail-Spam als traditioneller Sicherheitsforschung. Das Versenden einer weiteren Nachricht kostet fast nichts, doch empfangende Organisationen müssen jeden potenziell wichtigen Hinweis weiterhin filtern.

Finanzielle Belohnungen können dieses Ungleichgewicht verstärken. Wenn ein akzeptiertes Ergebnis die Kosten für die Generierung Tausender Einreichungen deckt, wird Volumen für schwächere Teilnehmende zu einer rationalen Strategie.

Dieses Verhalten schadet Forschenden, die sorgfältige Arbeit leisten. Ihre Befunde landen in derselben Warteschlange und konkurrieren um dieselben Prüfenden.

Es schadet auch Nutzenden, wenn Maintainer weniger Zeit für die Behebung bestätigter Schwachstellen aufwenden. Die Triage wird zum Engpass, bevor die Behebung überhaupt beginnen kann.

Das Problem besteht nicht nur darin, dass Modelle halluzinieren. Auch menschliche Forschende machen Fehler, übertreiben Auswirkungen und reichen Duplikate ein.

KI verändert das Ausmaß, die Geschwindigkeit und die Präsentation dieser Fehler. Sie ermöglicht es einer Person, mehr plausible Behauptungen zu erzeugen, als sie persönlich validieren kann.

Diese Unterscheidung erklärt, warum ein Verbot KI-generierter Prosa wenig lösen würde. Forschende könnten ein nicht verifiziertes Modellergebnis umformulieren und dieselbe unbelegte Behauptung einreichen.

Programme brauchen stattdessen evidenzbasierte Hürden. Die relevante Frage ist, ob die meldende Person das Ergebnis getestet hat, nicht ob ein Modell zu seiner Entdeckung beigetragen hat.

Googles Pause signalisiert, dass seine bestehenden Regeln diese Unterscheidung nicht effizient durchsetzen konnten. Schriftliche Anforderungen waren einfacher zu veröffentlichen als gegen industrialisierte Berichtsmengen anzuwenden.

Googles KI-Sicherheitsstrategie steht nun vor ihrem eigenen Zielkonflikt

Google fördert KI-gestützte Sicherheitsentdeckung, doch sein Prämienprogramm kann nicht jeden Befund aus derselben Automatisierungswelle aufnehmen.

Die Aussetzung des Google OSS VRP bedeutet nicht, dass das Unternehmen KI für die Sicherheit als nutzlos betrachtet. Google investiert weiterhin in automatisierte Schwachstellenerkennung und -behebung.

Seine Sicherheitsteams nutzen Tools wie OSS-Fuzz, Big Sleep und CodeMender. Diese Systeme kombinieren automatisierte Analyse mit kontrollierten Tests und fachkundiger Prüfung.

Google hat außerdem seine Android- und Chrome-Prämienprogramme für das, was es das KI-Zeitalter nennt, überarbeitet. Das Unternehmen erwartet, dass Automatisierung Schwachstellen aufdeckt, die herkömmliche Forschung übersieht.

Das macht die Aussetzung zu einer bedeutenden Kehrtwende. Google zieht sich nicht aus der KI-Sicherheitsforschung zurück, begrenzt jedoch einen externen Kanal, der von den niedrigeren Einreichungskosten durch KI betroffen ist.

Die zentrale Trennlinie verläuft nicht zwischen menschlicher und maschineller Forschung. Sie liegt zwischen intern validierter Automatisierung und extern eingereichten Behauptungen mit uneinheitlicher Validierung.

Google kontrolliert die Umgebung seiner eigenen Systeme. Ingenieurinnen und Ingenieure können Ziele definieren, Tests ausführen, Abstürze erfassen und messen, ob generierte Patches das Verhalten erhalten.

Ein offenes Prämienprogramm verfügt nicht über diese Kontrolle. Teilnehmende nutzen unterschiedliche Tools, Prompts, Modelle, Codeversionen und Definitionen von Sicherheitsauswirkungen.

Prüfende erhalten die abschließende Behauptung, ohne jeden Schritt zu sehen, der sie hervorgebracht hat. Sie müssen fehlende Annahmen rekonstruieren, bevor sie entscheiden können, ob der Befund relevant ist.

Dieser Unterschied macht Herkunft zu einem praktischen Sicherheitsproblem. Teams müssen wissen, welche Revision getestet wurde, welche Eingabe das Ergebnis auslöste und ob ein Mensch es reproduziert hat.

Googles umfassenderes Prämiensystem bleibt bedeutend. Das Unternehmen erklärte, seine Programme hätten 2025 mehr als 17 Millionen US-Dollar an über 700 Forschende ausgezahlt.

Sein jährlicher VRP-Rückblick bezeichnete diese Summe als Rekordwert. Der Betrag stieg gegenüber 2024 um mehr als 40 Prozent.

Diese Zahlen zeigen, dass Google externe Forschung weiterhin schätzt. Sie verdeutlichen auch, warum glaubwürdige Einreichungskanäle wichtig sind.

Ein Bounty-Programm hängt von gegenseitigem Vertrauen ab. Forschende müssen darauf vertrauen, dass gültige Befunde faire Aufmerksamkeit erhalten, während Unternehmen darauf vertrauen müssen, dass Meldende ihre Behauptungen testen.

Ungefilterte Automatisierung schwächt beide Seiten. Verzögerungen bei der Prüfung frustrieren kompetente Forschende, und wiederkehrende ungültige Berichte machen Prüfende gegenüber unbekannten Beitragenden skeptischer.

Googles Reaktion schützt die Triage-Kapazität, schränkt aber auch den Zugang ein. Unabhängige Forschende können derzeit über die ausgesetzte OSS-VRP-Kategorie keine gewöhnlichen Produktschwachstellen einreichen.

Diese Einschränkung könnte neben dem Rauschen auch wertvolle Befunde unterdrücken. Einer neuen forschenden Person mit einem gültigen Problem fehlt möglicherweise ein offensichtliches alternatives Programm.

Die Herausforderung ist daher ein Zielkonflikt zwischen Offenheit und Verifizierung. Breiter Zugang erhöht die Entdeckungsmöglichkeiten, während strenge Hürden die begrenzte Zeit der Prüfenden schützen.

Jedes neu gestaltete Programm muss beide Ziele bewahren. Werden die Eintrittsanforderungen zu belastend, riskiert Google, die Teilnahme auf etablierte Forschende und spezialisierte Firmen zu konzentrieren.

Bleiben die Anforderungen zu locker, kann die Einreichungswarteschlange in dieselbe Überlastung zurückkehren. Das Update im ersten Quartal 2027 wird zeigen, wo Google diese Grenze zieht.

Die Flut an KI-Berichten ist ein Branchenproblem

Googles Entscheidung ist Teil eines breiteren Wandels, in dem Sicherheitsgemeinschaften ihre Offenlegungsregeln rund um automatisierte Entdeckung neu schreiben.

HackerOne meldete nach dem Auftreten leistungsfähigerer KI-Tools im Februar 2026 einen Anstieg des Branchen-Meldevolumens um mehr als 100 Prozent.

Die Analyse des Meldevolumens ergab, dass einige Einreichungen nützliche Entdeckungen enthielten. Andere waren Duplikate, nicht überprüfbare Behauptungen oder Meldungen ohne verwertbare Tiefe.

Die Plattform reagierte nicht mit einem Verbot verantwortungsvoller KI-Unterstützung. Stattdessen bekräftigte sie die Pflicht der Forschenden, Befunde zu validieren und reale Auswirkungen nachzuweisen.

Die Regeln von HackerOne verlangen einen reproduzierbaren Proof of Concept, eine präzise Schweregradeinstufung und die Berücksichtigung bestehender Schutzmechanismen. Große Mengen nicht verifizierter Meldungen können Durchsetzungsmaßnahmen auslösen.

Dieser Ansatz verortet die Verantwortung beim Anwender statt beim Werkzeug. Ein Forscher bleibt für jeden generierten Endpunkt, jeden Angriffsschritt und jede behauptete Auswirkung verantwortlich.

Die Linux-Kernel-Community verfolgt einen ähnlich evidenzbasierten Ansatz. Ihre Regeln für Sicherheitsmeldungen behandeln inzwischen direkt KI-gestützte Code-Reviews.

Die Dokumentation besagt, dass KI-Meldungen häufig übermäßig lang werden und kritische Fakten verschleiern. Sie fordert Meldende auf, prägnante Beschreibungen, betroffene Revisionen, auslösende Bedingungen und getestete Reproduktionsfälle bereitzustellen.

Linux warnt außerdem, dass Tools theoretische Auswirkungen erfinden können, ohne das Bedrohungsmodell des Kernels zu verstehen. Meldende sollen stattdessen überprüfbare Folgen angeben.

Das Projekt behandelt breit reproduzierbare automatisierte Befunde anders als traditionell private Entdeckungen. Mehrere Forschende finden häufig dasselbe Problem, weil sie ähnliche Tools einsetzen.

Dadurch entsteht doppelte Arbeit in Offenlegungskanälen, die für seltene, unabhängig entdeckte Schwachstellen konzipiert wurden. Automatisierung verändert die Annahmen hinter diesen Kanälen.

Curl-Maintainer Daniel Stenberg beschrieb 2025 eine weitere Variante des Problems. Sein Argument vom „Tod durch tausend Schrottmeldungen“ konzentrierte sich auf die kumulierten Kosten der Prüfung schwacher Einreichungen.

Eine einzelne schlechte Meldung mag beherrschbar erscheinen. Wiederholen sich diese Kosten über Hunderte generierter Behauptungen hinweg, kann ein von Freiwilligen gepflegtes Projekt überlastet werden.

Diese Fälle teilen einen Mechanismus. KI erweitert das Angebot an Schwachstellenhypothesen schneller als das Angebot qualifizierter Triage-Arbeit.

Die Auswirkungen unterscheiden sich je nach Organisation. Google kann bezahlte Sicherheitsingenieure einsetzen, während kleinere Projekte oft von Freiwilligen mit begrenzter Zeit abhängen.

Open-Source-Maintainer stehen vor einer besonders schwierigen Anreizstruktur. Öffentlicher Code lässt sich leicht von automatisierten Scannern erfassen, doch die Maintainer erhalten keine entsprechenden Ressourcen.

Prämien können ein weiteres Ungleichgewicht schaffen. Ein Unternehmen kann akzeptierte Befunde belohnen, während Community-Maintainer erste Diskussionen oder Upstream-Behebungen ohne Vergütung übernehmen.

Das macht automatisierte Forschung nicht grundsätzlich schädlich. KI kann schwer zugängliche Komponenten untersuchen, unbekannten Code übersetzen und Forschenden beim Erstellen von Tests helfen.

Sie kann die Qualität von Meldungen auch verbessern, wenn sie nach der Verifizierung eingesetzt wird. Ein Modell kann Reproduktionsschritte strukturieren oder komplexe Kontrollflüsse klarer erklären.

Dieselben Fähigkeiten werden destruktiv, wenn sie die Verifizierung ersetzen. Eine plausible Erzählung zu erzeugen, ist nicht gleichbedeutend mit dem Nachweis einer ausnutzbaren Bedingung.

Der sich abzeichnende Branchenkonsens lautet daher bedingte Akzeptanz. KI-Unterstützung bleibt willkommen, wenn ein menschlicher Anwender jede wesentliche Behauptung reproduzieren und verteidigen kann.

Googles vorübergehende Schließung ist restriktiver als dieses Prinzip. Sie spiegelt jedoch dieselbe Einschätzung darüber wider, wo die Verantwortung liegen muss.

Die Person, die eine Meldung einreicht, muss genügend Validierungskosten selbst tragen, um den Empfänger zu schützen. Andernfalls wird das Programm zu einer ausgelagerten Testwarteschlange für spekulative maschinelle Ergebnisse.

Strengere Hürden können helfen, schaffen aber neue Risiken

Ein neu gestaltetes Programm muss die Verifizierung in jede Einreichung einpreisen, ohne legitime unabhängige Forschende auszuschließen.

Google hat den endgültigen Ersatz für Einreichungen zu Produktschwachstellen nicht offengelegt. Mehrere Kontrollen würden zu den Problemen passen, die in seinen früheren Regeln identifiziert wurden.

Die erste ist ein verpflichtender getesteter Reproduktionsfall. Ein Reproduktionsfall stellt ein kleines Programm, eine Eingabe oder ein Verfahren bereit, das das behauptete Verhalten zuverlässig auslöst.

Google könnte Meldende verpflichten, die genaue Repository-Revision und Umgebung anzugeben. Diese Informationen würden den Zeitaufwand für Tests veralteten oder inkompatiblen Codes reduzieren.

Meldungen könnten außerdem eine explizite Begründung der Erreichbarkeit erfordern. Der Meldende müsste zeigen, wie von Angreifern kontrollierte Daten die anfällige Operation erreichen.

Ein strukturiertes Feld zum Bedrohungsmodell könnte Forschende dazu zwingen, erforderliche Berechtigungen, Vertrauensgrenzen und bestehende Gegenmaßnahmen zu benennen. Unbelegte Behauptungen zum Schweregrad ließen sich leichter erkennen.

Ratenbegrenzungen bieten eine weitere Option. Google könnte beschränken, wie viele ungelöste Meldungen ein Konto innerhalb eines festen Zeitraums einreichen darf.

Das würde Schrotflinten-Einreichungen entmutigen und zugleich sorgfältigen Forschenden den Zugang erhalten. Höhere Grenzen könnten an eine Historie akzeptierter Arbeit geknüpft sein.

Hinterlegungen oder Reputationsanforderungen könnten eine stärkere Filterung ermöglichen, bergen jedoch größere Fairnessrisiken. Neue Forschende könnten Schwierigkeiten haben, in das Programm einzusteigen.

Automatisierte Vorabprüfungen sind eine weitere wahrscheinliche Komponente. Google könnte statische Analyse, Sandbox-Ausführung oder modellbasierte Überprüfung nutzen, um Duplikate und fehlende Belege zu markieren.

Automatisierte Prüfung darf jedoch nicht zur endgültigen Instanz werden. Sie kann ungewöhnliche, aber gültige Forschung zurückweisen oder vertraute Schwachstellenmuster bevorzugen.

Ein Modell, das den Bericht eines anderen Modells prüft, kann zudem dieselben fehlerhaften Annahmen reproduzieren. Unabhängige Ausführungsbelege bleiben wertvoller als textuelle Übereinstimmung.

Datenschutz und Vertraulichkeit schaffen zusätzliche Komplikationen. Forschende können ungepatchte Details gegenüber KI-Diensten Dritter offenlegen, wenn sie Modelle um Analysen bitten.

Ein überarbeitetes Programm könnte verlangen, externe Modellnutzung im Zusammenhang mit vertraulichen Befunden offenzulegen. Es könnte außerdem beschränken, welche sensiblen Materialien in gehostete Systeme gelangen.

Google muss auch klären, wie Open-Source-Maintainer an der Triage beteiligt werden. Eine Meldung kann ein Google-Repository betreffen und gleichzeitig Arbeit für eine breitere Beitragenden-Community verursachen.

Das Unternehmen sollte sein Warteschlangenproblem nicht dadurch lösen, dass es Verifizierungspflichten nach Upstream verlagert. Das würde die Last nur verschieben, statt sie zu verringern.

Transparenz wird während der Pause wichtig sein. Google hat öffentlich keine detaillierte Aufschlüsselung akzeptierter, doppelter, ungültiger und KI-gestützter Meldungen bereitgestellt.

Tom’s Hardware beschrieb Ingenieure und Maintainer, die mit Tausenden minderwertiger Einreichungen konfrontiert sind. Googles veröffentlichte Mitteilung nannte jedoch kein präzises Volumen und keine Akzeptanzrate.

Diese Unterscheidung begrenzt, welche Schlussfolgerungen Außenstehende ziehen können. Die verfügbaren Belege stützen die Annahme eines ernsten Qualitätsproblems, aber kein vollständiges quantitatives Bild.

Google sollte genügend aggregierte Daten veröffentlichen, um die neu gestalteten Schwellenwerte zu erläutern. Nützliche Kennzahlen umfassen die mittlere Prüfzeit und den Anteil von Meldungen ohne funktionierende Reproduktionsfälle.

Auch Raten falscher Zurückweisungen sind wichtig. Eine schnellere Warteschlange ist kein Erfolg, wenn starke Befunde verschwinden, weil automatisierte Filter sie falsch klassifizieren.

Das Programm sollte zwischen Unterstützung bei der Entdeckung und autonomer Einreichung unterscheiden. Ein von Menschen geprüfter KI-Befund kann wertvoll sein, während eine unbeaufsichtigte Meldepipeline ein unkontrolliertes Risiko schafft.

Googles stärkstes Design würde den Nachweis günstiger bewertbar machen als Prosa. Maschinenlesbare Tests, begrenzte Vorlagen und reproduzierbare Umgebungen könnten dieses Ziel unterstützen.

Das Unternehmen sollte zudem einen Eskalationsweg für unkonventionelle Befunde bewahren. Manche wichtigen Schwachstellen widersetzen sich einfachen Testfällen oder umfassen komplexe Ketten.

Keine einzelne Hürde wird diese Anforderungen ausbalancieren. Die wahrscheinliche Antwort ist ein gestaffelter Zugang auf Grundlage der Qualität der Belege, der Historie der Forschenden und der nachgewiesenen Sicherheitsauswirkung.

Worauf vor Googles Q1-2027-Update zu achten ist

Die nächste Phase wird zeigen, ob Google Einreichungen mit besseren Belegstandards wieder öffnen kann, anstatt einfach weniger Forschende zu akzeptieren.

Das erste Signal ist der Umfang des Ersatzprogramms. Google muss erklären, ob Einreichungen zu Produktschwachstellen vollständig wieder geöffnet werden oder über einen engeren Kanal zurückkehren.

Eine vollständige Wiedereröffnung würde darauf hindeuten, dass neue Filter das Vertrauen in den Prüfprozess wiederhergestellt haben. Ein begrenztes Einladungssystem würde anzeigen, dass die Triage-Kapazität weiterhin eingeschränkt ist.

Das zweite Signal sind die von Meldenden verlangten Belege. Getestete Reproduktionsfälle, betroffene Commits und konkrete Angriffspfade würden die von Google bereits identifizierten Schwächen angehen.

Diese Anforderungen würden das Programm stärken, wenn sie zugänglich bleiben. Sie würden es schwächen, wenn nur etablierte Forschende undurchsichtige Prüfstandards erfüllen können.

Das dritte Signal ist, wie andere Sicherheitsprogramme reagieren. HackerOne, Linux und große Anbieter experimentieren alle mit KI-bewussten Regeln für Einreichungen.

Wenn sie bei Reproduzierbarkeit und menschlicher Verantwortung zusammenfinden, könnte die Branche einen gemeinsamen Mindeststandard entwickeln. Das könnte Verwirrung für Forschende verringern, die programmübergreifend arbeiten.

Wenn Programme stattdessen inkompatible Beschränkungen einführen, wird Offenlegung schwieriger. Forschende könnten für jedes Ziel unterschiedliche Belegpakete, KI-Richtlinien und Vertraulichkeitspraktiken benötigen.

Entwickler sollten auch die Tools selbst beobachten. Bessere Agenten können funktionierende Tests erstellen, aber sie können ungültige Belege mit größerer Überzeugung erzeugen.

Der entscheidende Maßstab ist nicht, wie viele Warnungen ein Agent findet. Entscheidend ist, wie viele unabhängig reproduzierbare, sicherheitsrelevante Befunde die Expertenprüfung überstehen.

Maintainer sollten die pro akzeptierter Schwachstelle aufgewendete Zeit verfolgen, nicht die bloße Zahl der Einreichungen. Diese Kennzahl erfasst, ob Automatisierung die Sicherheit verbessert oder lediglich die Warteschlange vergrößert.

Forschungsteams können sich vorbereiten, indem sie jede Phase KI-gestützter Arbeit dokumentieren. Bewahren Sie den getesteten Commit, die Konfiguration, Protokolle, Eingaben und fehlgeschlagene Reproduktionsversuche auf.

Teams benötigen außerdem ein durchsuchbares Verzeichnis früherer Befunde. Eine strukturierte Engineering-Wissensdatenbank kann helfen, Duplikate zu erkennen, bevor sie Maintainer erreichen.

Forschende sollten in der Lage sein, den Fehler ohne Abhängigkeit von generierter Prosa zu erklären. Sie sollten wissen, warum der Codepfad erreichbar ist und welche bestehende Kontrolle versagt.

Fehlt diese Erklärung, ist der Befund weiterhin eine Hypothese. Er ist nicht bereit für ein Programm zur Belohnung von Schwachstellenmeldungen.

Die Aussetzung des Google OSS VRP ist daher eine Warnung über Workflow-Design, kein Urteil gegen KI-Sicherheitsforschung. Die Entdeckung hat sich beschleunigt, doch die Verifizierung ist nicht verschwunden.

Googles Update für Q1 2027 wird prüfen, ob ein großer Anbieter ein offenes Programm um diese Realität herum neu aufbauen kann. Das beste Ergebnis würde nicht die Zahl der Einreichungen maximieren.

Es würde den verifizierten Sicherheitswert pro Stunde der Aufmerksamkeit von Prüfern maximieren. Dieser Standard gibt ernsthaften Forschenden ein klares Ziel und schützt Maintainer vor spekulativem Volumen.

Stellen Sie vor der Einreichung eines KI-gestützten Befunds irgendwo drei Fragen. Kann eine andere Person ihn reproduzieren, überschreitet er eine reale Sicherheitsgrenze, und haben Sie jede wesentliche Behauptung getestet?

Wenn eine Antwort nein lautet, untersuchen Sie weiter. Die günstigste Meldung in der Erstellung kann für einen Maintainer zur teuersten werden, die widerlegt werden muss.