„Künstliche Intelligenz“ zerstört quelloffene Software

Abseits der „KI wird uns alle töten“ Panikmache verursacht die Technik durchaus zunehmend reale Probleme. Und die sind so gar nicht intelligent: Open Source Projekte werden mit künstlich generierten Bugmeldungen geflutet. Das ist ein ernstes Problem, weil diese plausibel wirken – aber sich nach Überprüfung nahezu immer als Bullshit entlarven. Doch gerade durch diese geschickte Tarnung verschwenden sie menschlichen Entwicklern viel Zeit. Eine zusätzliche Belastung für Menschen, die oft neben ihrer Lohnarbeit in der Freizeit an quelloffener Software arbeiten. Deren Ressourcen waren bereits vor der „KI“ Welle oft spärlich bis unterbesetzt.

Ein bekanntes Beispiel dafür ist die Bibliothek Curl. Von 2023 – 2025 hat sich der „KI“ Müll unter den Meldungen von Sicherheitslücken massiv erhöht. Wird dagegen nichts unternommen, kann die Technologie die gesamte OS-Branche in den Abgrund stürzen. Dies wäre in vielerlei Hinsicht verheerend. Längst ist OSS das Rückgrat der modernen Welt. Es ist daher höchste Zeit, dieses Problem im folgenden Artikel genauer zu betrachten.

FOSS: Das Fundament unserer (digitalen) Welt

Freie und quelloffene Software (kurz FOSS) sind ein Grundpfeiler unserer gesamten digitalen Infrastruktur: Internet, Smartphone, Clouddienste, usw. Selbst in proprietärer Software haben beide Omnipräsenz. Eine aktuelle Studie stellte fest, dass quelloffene Software in 96% aller Codebasen enthalten ist.¹ Manche kommerzielle Software kombiniert lediglich OSS, um diese zu verkaufen.

Da OSS oft frei verfügbar ist, kann man ihren finanziellen Wert nur schwer messen. Die Studie versucht es mit zwei Kennzahlen:

Dem Angebotswert – was würde es kosten, alle verbreiteten OSS-Projekte neu zu entwickeln?
Nachfragewert – was würde es kosten, wenn alle Unternehmen mit OSS-Nutzung diese Software selbst auf eigene Rechnung entwickeln würde?

Der Angebotswert wurde auf 4,15 Milliarden US-Dollar beziffert. Wie zu erwarten, liegt der Nachfragewert mit 8,8 Milliarden US-Dollar weit darüber. Schließlich würde man beim Angebotswert weiterhin gängige Bibliotheken gemeinsam nutzen. Der Nachfragewert wiederum führt zu Silos, in denen jeder das Rad buchstäblich neu erfinden müsste. Es liegt auf der Hand, dass sämtliche Software ohne OSS massiv teurer wäre – und die Entwicklung deutlich länger dauern würde. Betroffen wären nahezu sämtliche Bereiche unseres Alltags. In nahezu jedem modernen Gerät steckt Software.

So funktioniert das wichtige FOSS Ökosystem

Freie & quelloffene Software sind nicht identisch, verfügen jedoch über viele Gemeinsamkeiten. Einer davon ist die gemeinschaftliche Entwicklung: Es bildet sich eine Community aus verschiedenen Personen, die ihren Beitrag zum jeweiligen Projekt leisten. Es herrscht Transparenz zur Förderung von Innovation & Unabhängigkeit.

Doch FOSS ist mehr als nur Programmcode. Neben Softwareentwicklern gibt es verschiedene Rollen, wie beispielsweise Tester oder Autoren der Anwenderdokumentation. Anders als bei kommerzieller Software stehen oft keine großen Teams mit festen Budgets hinter den Projekten. Viele arbeiten in ihrer Freizeit unentgeltlich an Wartung, Unterstützung und der Weiterentwicklung.

Ein wichtiger Bestandteil sind Rückmeldungen der Nutzer. Neben Wünschen zu Änderungen und neuen Funktionen melden sie auch Fehler (Bugs). Besonders kritisch wird es, wenn diese Fehler zu Sicherheitslücken führen. Dabei können Systeme sowie Nutzerdaten gefährdet sein – daher ist schnelles, strukturiertes Handeln erforderlich. Üblicherweise priorisieren Softwareprojekte gemeldete Sicherheitslücken höher. Teils werden sie auch an Wochenenden/Feiertagen abgearbeitet, um so schnell wie möglich reagieren zu können. Zumindest, wenn die Projekte sich das leisten können.

KI als Gegner statt Helfer

In den letzten Jahren haben automatisierte Tools und insbesondere KI‑gestützte Systeme verstärkt Einzug in die Software-Entwicklung gehalten. Auch im Bereich der Sicherheit: Sie sollen dort helfen, Schwachstellen zu finden. Was auf den ersten Blick nach einer großen Chance für freie und quelloffene Software aussieht, entwickelt sich jedoch zunehmend zu einem neuen Risiko.

Eine Analyse von über 2.000 automatisierten Meldungen in öffentlichen GitHub OS-Projekten ergab, dass in lediglich etwa 180 Fällen von insgesamt 2.116 echte Schwachstellen vorlag. Das entspricht einer Quote von 91% an Fehlalarmen.² Bei bestimmten Konstellationen (Python/Flask) von vermeintlichen Lücken ist die Quote mit 99,5% noch gravierender. Alleine hier kam es zu 1.166 Meldungen, von denen nur 6 tatsächliche Sicherheitsprobleme waren.

In einer andern Studie wurden über 100 bekannte & verbreitete PHP-Projekte mit über 1.000 Sternen auf GitHub untersucht. Zwei Analysewerkezuge fanden über 9.200 angebliche schwere Sicherheitsprobleme. Die Forscher prüften 30% (über 2.700) davon händisch und fanden lediglich 35 echte Schwachstellen in 14 Anwendungen. Alleine in dieser Teilmenge eine Erfolgsquote von 2% bzw. 98% Fehlalarme.³

Kurzum – in diesem Bereich erwies sich „KI“ ebenfalls als extrem unzuverlässig. Es werden lediglich stupide Prüfungen ohne Kontext durchgeführt. Das große Problem: Man weiß es vorher nicht. Entwickler müssen jede Meldung prüfen – und benötigten dafür in der ersten Studie durchschnittlich 10 Minuten pro Meldung. Alleine für die rund 1.200 vermeintlichen Python-Funde hätte man fast 200 Stunden investieren müssen. Nur, für die 6 Nadeln im riesigen Heuhaufen.

„KI Bullshit“ hat es auf eines der wichtigsten Projekte abgesehen

Auf das Problem aufmerksam wurde ich über das Programm curl. Es handelt sich um eine Software & Bibliothek zur Datenübertragung mit verschiedenen gängigen Protokollen – meist HTTP oder FTP. Dort beobachte ich die Zunahme von „KI Müll“ bereits seit 2024. Erste Hinweise darauf finden sich bereits 2023 auf ihrer Plattform für Sicherheitslücken. Die Meldung 2199174 ist ein Paradebeispiel.⁴ Ein Speicherüberlauf der Timeout-Variable soll angeblich zur Codeausführung aus der Ferne führen. Das wäre ein Totalschaden.

Doch bei der Prüfung stellte das Curl-Team fest: Die Meldung scheint aus einer 3 Jahre alten Lücke recycelt und weist viele falsche oder erfundene Informationen auf. Ein Beispielcode soll die angebliche Lücke demonstrieren, dieser lässt sich nicht einmal kompilieren. Die Antwort des „Finders“ nimmt keinerlei Bezug darauf, sondern enthält nur generische Floskeln.

Auf ähnlichem Niveau bewegt sich GitHub-Ticket #12983.⁵ Dort wird eine angebliche Sicherheitslücke öffentlich gemeldet – ein völliges NoGo. Schließlich kann jeder die Lücke ausnutzen, während noch nicht mal ein Update in Arbeit ist. Seit Jahrzehnten lautet die gelebte Praxis, so etwas auf vertraulichen Kanälen zu melden. Die hat curl mit HackerOne ja. Doch das interessiert die „KI“ Generatoren nicht, denen ohnehin jegliches Verständnis fehlt. Wenigstens gibt dieses Konto auf Nachfrage zu: Der Fund stammt von ihrem „neuen KI-Basierten Schwachstellenscanner“. Da dieser nicht mal eine konkrete Schwachstelle gefunden hat, sondern lediglich ein möglicherweise unsicheres Verhalten, ist auch diese Meldung wertlos.

Man könnte diese Liste noch ewig weiter führen – 34 ausgewählte Beispiele hat Daniel Stenberg in einer Liste gesammelt.⁶ Ende 2024 wird etwa eine weitere vermeintliche Remote Code Execution Lücke gemeldet.⁷ Sie macht ein häufiges Muster deutlich: Selbst auf Nachfrage werden keine konkreten Informationen geliefert, wo eine Schwachstelle sein soll. Sondern lediglich längere, allgemeine, nichts aussagende Texte. Offensichtlich verwenden diese Personen selbst für die Antworten „KI“ – und geben sich keinerlei Mühe, die generierten Texte auf Sinnhaftigkeit zu prüfen. Jeder Schwachsinn wird hineingekippt.

„KI“ Textgeneratoren schleimen gerne

Ebenfalls auffällig ist die übertriebene Höflichkeit und Förmlichkeit. So etwas sieht man etwa in HackerOne-Meldung #2887487.⁸ Die Antworten beginnen mit Phrasen wie „Thank you for your feedback“ oder enden mit „Thank you for pointing this out, and I appreciate the opportunity to review the tests with better consideration“. Nach solchen generierten Texten schreibt der Ersteller eine anscheinend selbst verfasste Antwort über seine Enttäuschung. Der Projektleiter von curl macht sich die Mühe, seine Ablehnung zu begründen. Und weist auf die große Menge an „KI“ Müll hin, die er bekommt.

Typische Muster für KI-Müll

Bereits diese Beispiele zeigen verschiedene Aspekte, die künstlich generierte „KI“ Meldungen enthalten:

Eine allgemeine Beschreibung, statt spezifischer Lücken/Angriffsszenarien
Sehr ausführliche Texte, die wenig konkretes Aussagen
Hinweise aus „potenzielle“ Probleme
Fehlerhafte Befehle oder kaputter Code als Beispiel
Ein selbst gewählter, sehr formeller Aufbau mit Textbausteinen
Übertrieben höfliches, bestätigendes auftreten

Schlussendlich sind das nur Indikatoren. Theoretisch kann auch ein echter Mensch besonders höflich und ausführlich antworten. Je nach verwendetem Textgenerator sind manche Aspekte mehr oder weniger vertreten. Zumal sich dies per Promt beeinflussen lässt. Kommen allerdings mehrere Faktoren zusammen, steigt die Wahrscheinlichkeit für einen von „KI“ generierten Report.

Das beste Erkennungszeichen sind in meinen Augen die potenziellen Probleme, bei denen keine konkrete Gefahr genannt werden kann. Kein echter Mensch würde melden, dass im Code irgendwo z.B. strcpy() verwendet wird, was gefährlich sein könnte. Und erst recht nicht antworten, die Codestelle findet sich da, wo strcp() aufgerufen wird.

Auch andere Projekte sind betroffen

Als verbreitete Software steht curl besonders im Fokus von KI-Bullshit. Grundsätzlich sind sie nicht alleine davon betroffen. In anderen OS-Projekten finden sich ebenfalls Tickets, die allem Anschein nach ohne Überprüfung von einem „KI“ Scanner stammen, ggf. mit einem LLM zur Textgenerierung. Ein solches Beispiel ist Ticket #25 von wget.⁹ Dies stammt vom gleichen Konto, wie das obige Beispiel im curl-Repository. Auch der Aufbau ist identisch.

Die Community hat eine klare Haltung dazu und zeigt sich zunehmend genervt:

Der in der Python-Stiftung für Sicherheit verantwortliche Seth Larson hat ebenfalls in mehreren OS-Projekte schlampige, von LLMs halluzinierte Sicherheitsberichte entdeckt.¹⁰ Er sieht einen „sehr besorgniserregenden Trend“. „KI“ Meldungen grenzen sich von manuellem Unsinn dadurch ab, dass sie auf den ersten Blick legitim erscheinen. LLMs sind gut darin, plausiblen Unsinn zu erfinden. Für die Entwickler erhöht das den Aufwand, sie zu entlarven. Schließlich müssen gemeldete Sicherheitslücken – ähnlich wie ein Notruf – grundsätzlich erst einmal ernst genommen werden.

Eine Lösung hat auch er nicht parat. Sein Blogeintrag enthält daher Handlungsempfehlungen, um die zermürbende Zeitverschwendung auf ein Minimum zu reduzieren. Außerdem weist er darauf hin: Die meisten Menschen handeln aus guten Motiven. Betroffene sollen sich Unterstützung holen. Nicht zuletzt deswegen, weil er durch den „KI“ Müll eine höhere Burnout-Gefahr für Entwickler sieht.

FOSS kann sich das nicht leisten

Dabei handelt es sich um keinen Einzelfall. Bereits 2023 (also zu Beginn des KI Hypes) gaben 61% der befragten Unternehmen an, dass Automatisierung (oft mit KI) ihre Fehlalarme erhöht hat.¹¹ Während Firmen oft die Ressourcen dafür hätten, die BWL-Abteilung auf Risiko fährt und sparen will, sieht es bei freier & quelloffener Software ganz anders aus.

Viele zentrale Projekte werden von wenigen Personen betreut – im schlimmsten Falle neben einer Lohnarbeit. Dies zeigte bereits OpenSSL schmerzlich: 2014 kam es zu einer schweren Sicherheitslücke. Ein Student gab an, sie unwissentlich eingebaut zu haben.¹² Die Tragweite war riesig, geschätzte 2/3 der Internetseiten sind betroffen gewesen. Allerdings hatte ein Entwickler des Projektes den Code angenommen. Aufgrund von Ressourcenmangel bemerkte er den Fehler ebenfalls nicht. OpenSSL hatte damals nur einen Vollzeit-Entwickler, gebraucht wurden mindestens 6.¹³ Ein strukturelles Problem: Nur wenn viele Augen auch in Ruhe prüfen dürfen, kann OSS sicherer sein.

Nach diesem Paukenschlag besserte sich die Situation. Zumindest Technik-Konzerne sahen ein, dass sie mehr zum OSS-Ökosystem beitragen müssen.¹⁴ Wie so oft in der Geschichte ist der Aktionismus nach einer Katastrophe gut. Mit der Zeit schwächt er sich wieder ab. 2025 haben lediglich 22% der befragten europäischen Unternehmen & Organisationen eine Abteilung, die sich mit FOSS beschäftigt.¹⁵ Dabei ist sich längst die große Mehrheit über die Vorteile einig. Doch die Meisten wollen offensichtlich nur nehmen, ohne etwas beizutragen.

Eine Schande für die Automobilbranche: Nahezu jeder nutzt curl, aber niemand unterstützt die Zukunft des Projekts¹⁶

Die Eskalation schreitet voran: Wie damit umgehen?

Daniel Stenberg, der Hauptentwickler von curl, hat sich bis Anfang 2024 mit seinem Frust über „KI“ weitgehend zurückgehalten. Dann widmet er dem Problem einen eigenen Blogbeitrag. Der „KI Müll“ wird zunehmend schwieriger zu erkennen. LLMs sind gut darin, plausibel aussehende Texte zu generieren. Das erhöht die Kosten auf der anderen Seite, sie zu prüfen.¹⁷

Ende 2024 weist er darauf hin, von „KI“ generierte Meldungen zukünftig als Spam zu markieren.¹⁸ Dadurch sind sie nicht mehr öffentlich verfügbar. 2025 hat er endgültig genug und kündigt an, sich gegen diesen „Wahnsinn“ zur Wehr zu setzen. Jede Sicherheitsmeldung muss die Frage beantworten, ob sie mit oder durch „KI“ generiert wurde. Wer das Bejaht, müsse mit einer Flut an Fragen rechnen, welche seine menschliche Intelligenz auf die Probe stellen. Wird „KI Müll“ heimlich übermittelt, folgt eine Sperre.¹⁹ Auslöser war eine angebliche Sicherheitslücke in einer Funktion, welche es in curl gar nicht gibt. Offensichtlich wurde sie per „KI“ halluziniert.²⁰

Seine Erkenntnis nach bald 3 Jahren „KI“ Hype:

Wir haben noch keine einzige echte Sicherheitsmeldung gesehen, die mit Hilfe von KI erstellt wurde.

Mitte 2025 nennt er relative Zahlen: Rund 20% aller Einsendungen seien „KI“ generierter Schrott. Nur 5% weisen auf echte Sicherheitslücken hin. Dieses Niveau habe sich in den letzten Jahren immer weiter verschoben. In seinem FrOSCon-Vortrag vom August 2025 hatte es sich auf 20 – 40% erhöht.²¹ Sie stellen eine enorme zusätzliche Belastung dar. Er und sein Team verbringen jede Woche unzählige Stunden damit, „sich mit diesen hirnverbrannten Dummheiten auseinanderzusetzen“. Da sich bislang keine Besserung oder gar Lösung abzeichnet, werden zunehmend radikale Wege diskutiert: So sollen möglicherweise Bug-Bounty-Prämien entfallen. Damit sei der Anreiz, ungeprüften „KI Müll“ einzureichen, geringer. Derzeit steht noch keine Entscheidung. Man wolle 2025 abwarten und bis dahin weiter Daten auswerten.²²

Wie lösen wir das Problem?

Natürlich ist in diesem Falle nicht „KI“ als Technologie Schuld. Die Verantwortung liegt bei zwei Parteien, welche sie unverantwortlich einsetzen: Den Scannern, die massenhaft unausgereifte Fehlalarme produzieren. Und den Nutzern, welche wiederum die Ausgabe solcher Scanner oder LLMs ungeprüft weiterreichen. In die Köpfe muss hinein: „KI“ ist kein vertrauenswürdiges Werkzeug und muss daher grundsätzlich geprüft werden.

Während Medienkompetenz die Problematik hoffentlich abfedert, liegt das a) in weiter Ferne und wird b) nicht alles lösen. Daher müssen wir uns darauf einstellen: Quelloffene Software benötigt mehr Ressourcen. Da viele Projekte bereits vor der Welle an künstlich generiertem Müll schlecht ausgestattet waren, wird dies um so dringender. OSS darf nicht pauschal als kostenfrei angesehen werden.

Es ist ein Gemeinschaftsprojekt, bei dem jeder das zurück geben sollte, was in seinem Handlungsspielraum steht. Private Nutzer spenden vielleicht 5€ und/oder helfen bei Code, Tickets, Werbung usw. Größere Unternehmen können und sollten mehr beitragen – insbesondere, wenn sie damit Geld verdienen. Leider sieht Stenbergs Erfahrung ganz anders aus. In einem aktuellen Interview sagte er auf die Frage, wie große Unternehmen zum Projekt beitragen und ob das ausreicht:²³

Normalerweise tragen sie überhaupt nicht bei, in keiner Weise. Üblicherweise sagen sie uns nicht einmal, dass sie es benutzen. Die Nutzer schnappen sich unseren Code, kompilieren und verteilen ihn und verkaufen Produkte, die ihn verwenden, und wir erfahren nie davon. Das ist der normale Ablauf. Sie geben nie etwas zurück: kein Code, kein Geld, keine Patches und keine Fehlerberichte. […]

Fazit

Künstliche Intelligenz wird zunehmend eingesetzt, um quelloffene Software mit ungeprüften Sicherheitsmeldungen zu bombardieren. Dieser „KI Müll“ klingt plausibel, ist aber nahezu immer schwachsinn. Das prüfen kostet viele Ressourcen – die schon vor der „KI“ Flut knapp waren. Sie fehlen woanders. Echte Sicherheitsmeldungen drohen unterzugehen. Auf Dauer kann das OSS stark schwächen. Vor allem unter den ehrenamtlichen Helfern. Neben dem Ressourcenmangel ist es frustrierend, seine Zeit damit zu verschwenden.

Mit solchen Schattenseiten der Technologie werden wir leben lernen müssen. Etwa mit noch mehr Sensibilisierung dafür, dass „KI“ generierten Inhalten keinesfalls ungeprüft getraut werden darf. Entwickler können Leitfäden nutzen, um die Zeitverschwendung einzugrenzen. Ob das ausreicht? Vielleicht, wenn wir unseren kollektiven Kurs ändern. Derzeit wird „KI“ durch den Hype weiterhin kopflos für nahezu alles eingesetzt. Ein gewisser Anteil schwimmt dort mit – und glaubt mangels Medienkompetenz sogar, mit dem „KI Müll“ etwas gutes zu tun. In einer naiven Sicht ist das plausibel.

Hier muss angesetzt werden. Nur so können wir von den Vorteilen, welche die Technik in manchen Bereichen bietet, profitieren. Anstatt primär Schäden zu verursachen. Ansonsten wird OSS eines der Felder sein, die von völlig falschem „KI“ Einsatz zerstört werden. Das kann keiner wollen – immerhin ist das die Grundlage für so ziemlich alles aus der heutigen IT. Und die wiederum ist nahezu überall. Schon deswegen sollte quelloffene Software grundsätzlich mehr Beachtung sowie Unterstützung erhalten, als das aktuell der Fall ist. Die Well der Bestürzung nach Heartbleed 2014 scheint längst wieder vergessen zu sein.