Google stoppt Open-Source-Bug-Bounty-Programm: Was KI-Spam über die Zukunft der Schwachstellenmeldung verrät

Einleitung: Ein Warnsignal für die gesamte IT-Sicherheitsbranche

Google hat sein Open Source Software Vulnerability Rewards Program (OSS VRP) vorübergehend eingestellt – und der Grund ist so bezeichnend wie beunruhigend: Das Programm wurde von einer Flut KI-generierter Schwachstellenberichte regelrecht überschwemmt. Sicherheitsforscher fluteten die Einreichungsplattform mit automatisch erstellten, oft substanzlosen Meldungen, die zwar auf den ersten Blick professionell wirkten, bei näherer Prüfung jedoch kaum verwertbare Informationen enthielten.

Was wie eine Randnotiz aus dem Silicon Valley klingt, hat direkte Relevanz für deutsche IT-Verantwortliche und Geschäftsführer: Vulnerability-Disclosure-Prozesse, Schwachstellenmanagement und die Qualität von Sicherheitsmeldungen stehen auch hierzulande im Mittelpunkt regulatorischer Anforderungen – insbesondere unter der NIS2-Richtlinie und dem deutschen BSI-Gesetz (BSIG). Wenn selbst ein Tech-Gigant wie Google seine Meldewege schließen muss, weil KI-Spam die Kapazitäten erschöpft, sollten mittelständische Unternehmen und KRITIS-Betreiber in Deutschland aufhorchen.

Technischer Hintergrund: Was ist passiert – und warum jetzt?

Bug-Bounty-Programme und ihre Bedeutung

Bug-Bounty-Programme sind organisierte Mechanismen, über die Unternehmen externe Sicherheitsforscher dazu einladen, Schwachstellen in ihrer Software zu melden – gegen Belohnung (englisch: bounty). Googles OSS VRP richtete sich speziell auf Open-Source-Projekte aus dem Google-Ökosystem, darunter kritische Infrastrukturkomponenten wie Bazel, Angular, Golang oder Fuchsia.

Der Ansatz ist bewährt: Unabhängige Forscher finden Lücken, melden sie verantwortungsvoll (responsible disclosure), und das Unternehmen kann sie schließen, bevor Angreifer sie ausnutzen.

Das KI-Spam-Problem

Mit dem breiten Einsatz großer Sprachmodelle (Large Language Models, LLMs) wie GPT-4 oder Claude hat sich die Qualität automatisch generierter Texte dramatisch verbessert. Das nutzen manche Teilnehmer gezielt aus: Sie generieren mit KI-Tools täuschend echt wirkende Schwachstellenberichte – vollständig formuliert, mit technischer Sprache, aber ohne echten Fund dahinter.

Das Ergebnis ist ein klassisches Signal-Rausch-Problem:

• Sicherheitsteams müssen jede Einreichung prüfen
• KI-generierte Berichte sind schwerer als irrelevant zu identifizieren als früher
• Die manuelle Reviewkapazität wird durch Masseneinreichungen ausgeschöpft
• Echte Sicherheitsforscher verlieren die Motivation, wenn ihre Meldungen in der Masse untergehen

Google hat laut Berichten keine genauen Zahlen veröffentlicht, aber der Schritt zur Aussetzung des Programms zeigt, dass das Problem ein operativ nicht mehr tragbares Ausmaß erreicht hatte.

Warum ist das strukturell gefährlich?

Das eigentliche Problem ist nicht Google – es ist das Prinzip. Open-Source-Software bildet die Grundlage eines Großteils der modernen digitalen Infrastruktur. Viele der Projekte, die über das OSS VRP abgesichert wurden, finden sich in deutschen Unternehmensanwendungen, Behördenportalen und kritischen Infrastrukturen wieder. Wenn die Qualitätssicherung im Schwachstellenmanagement durch KI-Spam kollabiert, entstehen blinde Flecken – mit realen Sicherheitskonsequenzen.

NIS2-Relevanz: Was bedeutet das für deutsche Unternehmen?

NIS2 und Schwachstellenmanagement

Die NIS2-Richtlinie (EU 2022/2555), umgesetzt in deutsches Recht über das novellierte BSIG (BSI-Gesetz), verpflichtet betroffene Unternehmen – sogenannte wesentliche und wichtige Einrichtungen – zu einem systematischen Risiko- und Schwachstellenmanagement. Konkret fordert Artikel 21 NIS2 unter anderem:

• Maßnahmen zur Behandlung von Sicherheitsvorfällen (Incident Handling)
• Sicherheit in der Lieferkette, einschließlich Open-Source-Abhängigkeiten
• Verfahren zur Bewertung der Wirksamkeit von Sicherheitsmaßnahmen

Das bedeutet: Wenn Sie Open-Source-Komponenten einsetzen – und das tun praktisch alle Unternehmen – sind Sie verpflichtet, deren Sicherheitsstatus aktiv zu überwachen. Ein Bug-Bounty-Programm, das durch KI-Spam lahmgelegt wird, ist ein Überwachungsausfall in der Lieferkette.

BSI-Meldepflichten und Schwachstellenkoordination

Das BSI betreibt mit dem CERT-Bund und der Koordinierungsstelle für IT-Sicherheit eigene Prozesse zur Schwachstellenkoordination. Betreiber kritischer Infrastrukturen (KRITIS) sind verpflichtet, erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden (Erstmeldung) und 72 Stunden (vollständige Meldung) beim BSI zu melden – analog zu den NIS2-Fristen.

Die Qualität dieser Meldeprozesse hängt direkt davon ab, dass Schwachstelleninformationen zuverlässig und vollständig vorliegen. Wenn externe Quellen wie Bug-Bounty-Programme ausfallen oder degradieren, müssen Unternehmen eigene Alternativprozesse vorhalten.

Betroffene Sektoren in Deutschland

Unter NIS2 fallen in Deutschland unter anderem:

All diese Sektoren setzen umfangreiche Open-Source-Software ein und sind auf funktionierende externe Sicherheitsprozesse angewiesen.

5 konkrete Schutzmaßnahmen für IT-Verantwortliche

1. Software-Composition-Analysis (SCA) einführen

Setzen Sie auf spezialisierte SCA-Tools wie OWASP Dependency-Check, Snyk oder Black Duck, um Open-Source-Abhängigkeiten in Ihrem Software-Stack automatisch zu inventarisieren und auf bekannte Schwachstellen zu prüfen. Eine aktuelle SBOM (Software Bill of Materials) ist dabei nicht nur Best Practice, sondern wird zunehmend regulatorisch gefordert.

Praxistipp: Integrieren Sie SCA fest in Ihre CI/CD-Pipeline, sodass jeder Build-Prozess automatisch gegen die National Vulnerability Database (NVD) und den OSV-Scanner von Google geprüft wird.

2. Eigene Vulnerability-Disclosure-Policy (VDP) etablieren

Richten Sie einen strukturierten internen Prozess ein, über den Mitarbeiter, Partner oder externe Forscher Schwachstellen melden können – unabhängig von externen Bug-Bounty-Programmen. Das BSI bietet hierzu Leitfäden und empfiehlt eine klare Responsible-Disclosure-Policy, die auch auf Ihrer Website veröffentlicht werden sollte.

Praxistipp: Nutzen Sie standardisierte Formate wie security.txt (RFC 9116) auf Ihren Webpräsenzen, um Sicherheitsforschern einen offiziellen Meldeweg anzuzeigen.

3. NIS2-konforme Patch-Management-Prozesse implementieren

Definieren Sie verbindliche SLAs für das Einspielen von Sicherheits-Patches – abhängig vom CVSS-Score der Schwachstelle:

Dokumentieren Sie alle Entscheidungen – insbesondere wenn Patches aus Betriebsgründen verzögert werden – lückenlos für mögliche BSI-Prüfungen.

4. KI-gestützte Angriffsvektoren in der Risikoanalyse berücksichtigen

Die Google-Episode zeigt: KI verändert nicht nur die Verteidigung, sondern auch die Angriffs- und Missbrauchsseite. Aktualisieren Sie Ihre Risikoanalyse gemäß NIS2 Artikel 21 und nehmen Sie explizit folgende neue Szenarien auf:

• KI-generierte Phishing-Kampagnen mit täuschend echter Sprache
• Automatisiertes Fuzzing und Schwachstellenscanning durch Angreifer
• Missbrauch von KI zur Überlastung von Sicherheitsprozessen (wie im Google-Fall)

5. Lieferkettenrisiken aktiv managen

Prüfen Sie, von welchen Open-Source-Projekten Ihre kritischen Systeme abhängen, und beobachten Sie deren Sicherheitsstatus aktiv. Nutzen Sie dazu:

• Den OSV-Datensatz (osv.dev) für Open-Source-Schwachstellen
• Die ENISA-Threat-Landscape-Berichte für sektorspezifische Bedrohungsanalysen
• Den BSI-Leitfaden zur Cyber-Sicherheit in der Lieferkette

Führen Sie außerdem regelmäßige Drittanbieter-Assessments durch und fordern Sie von Software-Lieferanten eine aktuelle SBOM an.

Fazit: KI verändert die Spielregeln – auch im Schwachstellenmanagement

Googles Entscheidung, das OSS VRP zu pausieren, ist mehr als eine operative Reaktion auf lästigen Spam. Sie ist ein Symptom einer tiefergehenden Verschiebung: Künstliche Intelligenz demokratisiert nicht nur Sicherheitswerkzeuge für Verteidiger, sondern auch für Angreifer und Missbraucher. Das erhöht den Druck auf strukturierte, automatisierte und regulatorisch abgesicherte Sicherheitsprozesse – und damit genau auf das, was NIS2 von deutschen Unternehmen einfordert.

IT-Verantwortliche sollten diesen Vorfall als Anlass nehmen, ihre eigenen Schwachstellenmanagement-Prozesse kritisch zu hinterfragen: Sind sie resilient genug, wenn externe Informationsquellen wegfallen? Sind Meldewege klar definiert und dokumentiert? Erfüllen Patch-Prozesse die NIS2-Anforderungen?

Hinweis für die Praxis: Die Dokumentation und Nachverfolgung von Schwachstellen, Meldepflichten und Risikobewertungen gemäß NIS2 ist manuell kaum mehr zuverlässig zu bewältigen. Spezialisierte NIS2-Compliance-Management-Plattformen helfen dabei, Pflichten zu strukturieren, Fristen zu überwachen und Nachweise revisionssicher zu dokumentieren – eine sinnvolle Investition, bevor der nächste BSI-Prüfbesuch ansteht.