Da OSS oft frei verf\u00fcgbar ist, kann man ihren finanziellen Wert nur schwer messen. Die Studie versucht es mit zwei Kennzahlen:<\/p>\n
- \n
- Dem Angebotswert – was w\u00fcrde es kosten, alle verbreiteten OSS-Projekte neu zu entwickeln?<\/li>\n
- Nachfragewert – was w\u00fcrde es kosten, wenn alle Unternehmen mit OSS-Nutzung diese Software selbst auf eigene Rechnung entwickeln w\u00fcrde?<\/li>\n<\/ol>\n
Der Angebotswert wurde auf 4,15 Milliarden US-Dollar beziffert. Wie zu erwarten, liegt der Nachfragewert mit 8,8 Milliarden US-Dollar weit dar\u00fcber. Schlie\u00dflich w\u00fcrde man beim Angebotswert weiterhin g\u00e4ngige Bibliotheken gemeinsam nutzen. Der Nachfragewert wiederum f\u00fchrt zu Silos, in denen jeder das Rad buchst\u00e4blich neu erfinden m\u00fcsste. Es liegt auf der Hand, dass s\u00e4mtliche Software ohne OSS massiv teurer w\u00e4re – und die Entwicklung deutlich l\u00e4nger dauern w\u00fcrde. Betroffen w\u00e4ren nahezu s\u00e4mtliche Bereiche unseres Alltags. In nahezu jedem modernen Ger\u00e4t steckt Software.<\/p>\n
So funktioniert das wichtige FOSS \u00d6kosystem<\/h2>\n
Freie & quelloffene Software sind nicht identisch, verf\u00fcgen jedoch \u00fcber 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\u00f6rderung von Innovation & Unabh\u00e4ngigkeit.<\/p>\n
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\u00dfen Teams mit festen Budgets hinter den Projekten. Viele arbeiten in ihrer Freizeit unentgeltlich an Wartung, Unterst\u00fctzung und der Weiterentwicklung.<\/p>\n
Ein wichtiger Bestandteil sind R\u00fcckmeldungen der Nutzer. Neben W\u00fcnschen zu \u00c4nderungen und neuen Funktionen melden sie auch Fehler (Bugs). Besonders kritisch wird es, wenn diese Fehler zu Sicherheitsl\u00fccken f\u00fchren. Dabei k\u00f6nnen Systeme sowie Nutzerdaten gef\u00e4hrdet sein – daher ist schnelles, strukturiertes Handeln erforderlich. \u00dcblicherweise priorisieren Softwareprojekte gemeldete Sicherheitsl\u00fccken h\u00f6her. Teils werden sie auch an Wochenenden\/Feiertagen abgearbeitet, um so schnell wie m\u00f6glich reagieren zu k\u00f6nnen. Zumindest, wenn die Projekte sich das leisten k\u00f6nnen.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2025\/10\/5c6bd780-49c5-4137-b7e0-9f50311ff959-1024x683.jpg\")
<\/a><\/figure>\n<\/div>\nKI<\/em> als Gegner statt Helfer<\/h2>\n
In den letzten Jahren haben automatisierte Tools und insbesondere KI\u2011gest\u00fctzte Systeme verst\u00e4rkt 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\u00dfen Chance f\u00fcr freie und quelloffene Software aussieht, entwickelt sich jedoch zunehmend zu einem neuen Risiko. <\/p>\n
Eine Analyse von \u00fcber 2.000 automatisierten Meldungen in \u00f6ffentlichen GitHub OS-Projekten ergab, dass in lediglich etwa 180 F\u00e4llen von insgesamt 2.116 echte Schwachstellen vorlag. Das entspricht einer Quote von 91% an Fehlalarmen.2<\/a><\/sup> Bei bestimmten Konstellationen (Python\/Flask) von vermeintlichen L\u00fccken ist die Quote mit 99,5% noch gravierender. Alleine hier kam es zu 1.166 Meldungen, von denen nur 6 tats\u00e4chliche Sicherheitsprobleme waren.<\/p>\n
In einer andern Studie wurden \u00fcber 100 bekannte & verbreitete PHP-Projekte mit \u00fcber 1.000 Sternen auf GitHub untersucht. Zwei Analysewerkezuge fanden \u00fcber 9.200 angebliche schwere Sicherheitsprobleme. Die Forscher pr\u00fcften 30% (\u00fcber 2.700) davon h\u00e4ndisch und fanden lediglich 35 echte Schwachstellen in 14 Anwendungen. Alleine in dieser Teilmenge eine Erfolgsquote von 2% bzw. 98% Fehlalarme<\/strong>.3<\/a><\/sup><\/p>\n
Kurzum – in diesem Bereich erwies sich „KI“ ebenfalls als extrem unzuverl\u00e4ssig. Es werden lediglich stupide Pr\u00fcfungen ohne Kontext durchgef\u00fchrt. Das gro\u00dfe Problem: Man wei\u00df es vorher nicht. Entwickler m\u00fcssen jede Meldung pr\u00fcfen – und ben\u00f6tigten daf\u00fcr in der ersten Studie durchschnittlich 10 Minuten pro Meldung. Alleine f\u00fcr die rund 1.200 vermeintlichen Python-Funde h\u00e4tte man fast 200 Stunden investieren m\u00fcssen. Nur, f\u00fcr die 6 Nadeln im riesigen Heuhaufen.<\/p>\n
„KI Bullshit“ hat es auf eines der wichtigsten Projekte abgesehen<\/h2>\n
Auf das Problem aufmerksam wurde ich \u00fcber das Programm curl. Es handelt sich um eine Software & Bibliothek zur Daten\u00fcbertragung mit verschiedenen g\u00e4ngigen Protokollen – meist HTTP oder FTP. Dort beobachte ich die Zunahme von „KI M\u00fcll“ bereits seit 2024. Erste Hinweise darauf finden sich bereits 2023 auf ihrer Plattform f\u00fcr Sicherheitsl\u00fccken. Die Meldung 2199174 ist ein Paradebeispiel.4<\/a><\/sup> Ein Speicher\u00fcberlauf der Timeout-Variable soll angeblich zur Codeausf\u00fchrung aus der Ferne f\u00fchren. Das w\u00e4re ein Totalschaden.<\/p>\n
Doch bei der Pr\u00fcfung stellte das Curl-Team fest: Die Meldung scheint aus einer 3 Jahre alten L\u00fccke recycelt<\/em> und weist viele falsche oder erfundene Informationen auf. Ein Beispielcode soll die angebliche L\u00fccke demonstrieren, dieser l\u00e4sst sich nicht einmal kompilieren. Die Antwort des „Finders“ nimmt keinerlei Bezug darauf, sondern enth\u00e4lt nur generische Floskeln.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2025\/10\/2025-10-19_21-08-1024x405.jpg\")
<\/a><\/figure>\n<\/div>\nAuf \u00e4hnlichem Niveau bewegt sich GitHub-Ticket #12983.5<\/a><\/sup> Dort wird eine angebliche Sicherheitsl\u00fccke \u00f6ffentlich gemeldet – ein v\u00f6lliges NoGo. Schlie\u00dflich kann jeder die L\u00fccke ausnutzen, w\u00e4hrend noch nicht mal ein Update in Arbeit ist. Seit Jahrzehnten lautet die gelebte Praxis, so etwas auf vertraulichen Kan\u00e4len zu melden. Die hat curl mit HackerOne ja. Doch das interessiert die „KI“ Generatoren nicht, denen ohnehin jegliches Verst\u00e4ndnis 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\u00f6glicherweise unsicheres Verhalten, ist auch diese Meldung wertlos.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2025\/10\/2025-10-19_21-15.avif\")
<\/a><\/figure>\n<\/div>\nMan k\u00f6nnte diese Liste noch ewig weiter f\u00fchren – 34 ausgew\u00e4hlte Beispiele hat Daniel Stenberg in einer Liste gesammelt.6<\/a><\/sup> Ende 2024 wird etwa eine weitere vermeintliche Remote Code Execution L\u00fccke gemeldet.7<\/a><\/sup> Sie macht ein h\u00e4ufiges Muster deutlich: Selbst auf Nachfrage werden keine konkreten Informationen geliefert, wo eine Schwachstelle sein soll. Sondern lediglich l\u00e4ngere, allgemeine, nichts aussagende Texte. Offensichtlich verwenden diese Personen selbst f\u00fcr die Antworten „KI“ – und geben sich keinerlei M\u00fche, die generierten Texte auf Sinnhaftigkeit zu pr\u00fcfen. Jeder Schwachsinn wird hineingekippt.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2025\/10\/2025-10-19_21-24-1024x344.jpg\")
<\/a><\/figure>\n<\/div>\n„KI“ Textgeneratoren schleimen gerne<\/h2>\n
Ebenfalls auff\u00e4llig ist die \u00fcbertriebene H\u00f6flichkeit und F\u00f6rmlichkeit. So etwas sieht man etwa in HackerOne-Meldung #2887487.8<\/a><\/sup> 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 \u00fcber seine Entt\u00e4uschung. Der Projektleiter von curl macht sich die M\u00fche, seine Ablehnung zu begr\u00fcnden. Und weist auf die gro\u00dfe Menge an „KI“ M\u00fcll hin, die er bekommt.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2025\/10\/curl-maintainers-day-1024x550.jpg\")
<\/a><\/figure>\n<\/div>\nTypische Muster f\u00fcr KI-M\u00fcll<\/h2>\n
Bereits diese Beispiele zeigen verschiedene Aspekte, die k\u00fcnstlich generierte „KI“ Meldungen enthalten:<\/p>\n
- \n
- Eine allgemeine Beschreibung, statt spezifischer L\u00fccken\/Angriffsszenarien<\/li>\n
- Sehr ausf\u00fchrliche Texte, die wenig konkretes Aussagen<\/li>\n
- Hinweise aus „potenzielle“ Probleme<\/li>\n
- Fehlerhafte Befehle oder kaputter Code als Beispiel<\/li>\n
- Ein selbst gew\u00e4hlter, sehr formeller Aufbau mit Textbausteinen<\/li>\n
- \u00dcbertrieben h\u00f6fliches, best\u00e4tigendes auftreten<\/li>\n<\/ul>\n
Schlussendlich sind das nur Indikatoren. Theoretisch kann auch ein echter Mensch besonders h\u00f6flich und ausf\u00fchrlich antworten. Je nach verwendetem Textgenerator sind manche Aspekte mehr oder weniger vertreten. Zumal sich dies per Promt beeinflussen l\u00e4sst. Kommen allerdings mehrere Faktoren zusammen, steigt die Wahrscheinlichkeit f\u00fcr einen von „KI“ generierten Report. <\/p>\n
Das beste Erkennungszeichen sind in meinen Augen die potenziellen Probleme, bei denen keine konkrete Gefahr genannt werden kann. Kein echter Mensch w\u00fcrde melden, dass im Code irgendwo z.B.
strcpy() <\/code>verwendet wird, was gef\u00e4hrlich sein k\u00f6nnte<\/em>. Und erst recht nicht antworten, die Codestelle findet sich da, wostrcp()<\/code> aufgerufen wird.<\/p>\nAuch andere Projekte sind betroffen<\/h2>\n
Als verbreitete Software steht curl besonders im Fokus von KI-Bullshit. Grunds\u00e4tzlich sind sie nicht alleine davon betroffen. In anderen OS-Projekten finden sich ebenfalls Tickets, die allem Anschein nach ohne \u00dcberpr\u00fcfung von einem „KI“ Scanner stammen, ggf. mit einem LLM zur Textgenerierung. Ein solches Beispiel ist Ticket #25 von wget.9<\/a><\/sup> Dies stammt vom gleichen Konto, wie das obige Beispiel im curl-Repository. Auch der Aufbau ist identisch.<\/p>\n
Die Community hat eine klare Haltung dazu und zeigt sich zunehmend genervt:<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2025\/10\/2025-10-19_21-29.avif\")
<\/a><\/figure>\n<\/div>\nDer in der Python-Stiftung f\u00fcr Sicherheit verantwortliche Seth Larson hat ebenfalls in mehreren OS-Projekte schlampige, von LLMs halluzinierte Sicherheitsberichte entdeckt.10<\/a><\/sup> 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\u00fcr die Entwickler erh\u00f6ht das den Aufwand, sie zu entlarven. Schlie\u00dflich m\u00fcssen gemeldete Sicherheitsl\u00fccken – \u00e4hnlich wie ein Notruf – grunds\u00e4tzlich erst einmal ernst genommen werden.<\/p>\n
Eine L\u00f6sung hat auch er nicht parat. Sein Blogeintrag enth\u00e4lt daher Handlungsempfehlungen, um die zerm\u00fcrbende Zeitverschwendung auf ein Minimum zu reduzieren. Au\u00dferdem weist er darauf hin: Die meisten Menschen handeln aus guten Motiven. Betroffene sollen sich Unterst\u00fctzung holen. Nicht zuletzt deswegen, weil er durch den „KI“ M\u00fcll eine h\u00f6here Burnout-Gefahr f\u00fcr Entwickler sieht.<\/p>\n
FOSS kann sich das nicht leisten<\/h2>\n
Dabei handelt es sich um keinen Einzelfall. Bereits 2023 (also zu Beginn des KI<\/em> Hypes) gaben 61% der befragten Unternehmen an, dass Automatisierung (oft mit KI<\/em>) ihre Fehlalarme erh\u00f6ht hat.11<\/a><\/sup> W\u00e4hrend Firmen oft die Ressourcen daf\u00fcr h\u00e4tten, die BWL-Abteilung auf Risiko f\u00e4hrt und sparen will, sieht es bei freier & quelloffener Software ganz anders aus.<\/p>\n
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\u00fccke. Ein Student gab an, sie unwissentlich eingebaut zu haben.12<\/a><\/sup> Die Tragweite war riesig, gesch\u00e4tzte 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.13<\/a><\/sup> Ein strukturelles Problem: Nur wenn viele Augen auch in Ruhe pr\u00fcfen d\u00fcrfen, kann OSS sicherer sein.<\/p>\n
Nach diesem Paukenschlag besserte sich die Situation. Zumindest Technik-Konzerne sahen ein, dass sie mehr zum OSS-\u00d6kosystem beitragen m\u00fcssen.14<\/a><\/sup> Wie so oft in der Geschichte ist der Aktionismus nach einer Katastrophe gut. Mit der Zeit schw\u00e4cht er sich wieder ab. 2025 haben lediglich 22% der befragten europ\u00e4ischen Unternehmen & Organisationen eine Abteilung, die sich mit FOSS besch\u00e4ftigt.<\/strong>15<\/a><\/sup> Dabei ist sich l\u00e4ngst die gro\u00dfe Mehrheit \u00fcber die Vorteile einig. Doch die Meisten wollen offensichtlich nur nehmen, ohne etwas beizutragen.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2025\/10\/curl_car-brands-vs-sponsors.avif\")
<\/a>Eine Schande f\u00fcr die Automobilbranche: Nahezu jeder nutzt curl, aber niemand unterst\u00fctzt die Zukunft des Projekts16<\/a><\/sup><\/figcaption><\/figure>\n<\/div>\n Die Eskalation schreitet voran: Wie damit umgehen?<\/h2>\n
Daniel Stenberg, der Hauptentwickler von curl, hat sich bis Anfang 2024 mit seinem Frust \u00fcber „KI“ weitgehend zur\u00fcckgehalten. Dann widmet er dem Problem einen eigenen Blogbeitrag. Der „KI M\u00fcll“ wird zunehmend schwieriger zu erkennen. LLMs sind gut darin, plausibel aussehende Texte zu generieren. Das erh\u00f6ht die Kosten auf der anderen Seite, sie zu pr\u00fcfen.17<\/a><\/sup><\/p>\n
Ende 2024 weist er darauf hin, von „KI“ generierte Meldungen zuk\u00fcnftig als Spam zu markieren.18<\/a><\/sup> Dadurch sind sie nicht mehr \u00f6ffentlich verf\u00fcgbar. 2025 hat er endg\u00fcltig genug und k\u00fcndigt 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\u00fcsse mit einer Flut an Fragen rechnen, welche seine menschliche Intelligenz auf die Probe stellen. Wird „KI M\u00fcll“ heimlich \u00fcbermittelt, folgt eine Sperre.19<\/a><\/sup> Ausl\u00f6ser war eine angebliche Sicherheitsl\u00fccke in einer Funktion, welche es in curl gar nicht gibt. Offensichtlich wurde sie per „KI“ halluziniert.20<\/a><\/sup><\/p>\n
Seine Erkenntnis nach bald 3 Jahren „KI“ Hype:<\/p>\n
\n
Wir haben noch keine einzige echte Sicherheitsmeldung gesehen, die mit Hilfe von KI erstellt wurde.<\/p>\n<\/blockquote>\n
Mitte 2025 nennt er relative Zahlen: Rund 20% aller Einsendungen seien „KI“ generierter Schrott. Nur 5% weisen auf echte Sicherheitsl\u00fccken 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\u00f6ht.21<\/a><\/sup> Sie stellen eine enorme zus\u00e4tzliche Belastung dar. Er und sein Team verbringen jede Woche unz\u00e4hlige Stunden damit, „sich mit diesen hirnverbrannten Dummheiten auseinanderzusetzen“. Da sich bislang keine Besserung oder gar L\u00f6sung abzeichnet, werden zunehmend radikale Wege diskutiert: So sollen m\u00f6glicherweise Bug-Bounty-Pr\u00e4mien entfallen. Damit sei der Anreiz, ungepr\u00fcften „KI M\u00fcll“ einzureichen, geringer. Derzeit steht noch keine Entscheidung. Man wolle 2025 abwarten und bis dahin weiter Daten auswerten.22<\/a><\/sup><\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2025\/10\/froscon-curl-ai-slop_how-often-1024x574.jpg\")
<\/a><\/figure>\n<\/div>\nWie l\u00f6sen wir das Problem?<\/h2>\n
Nat\u00fcrlich 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\u00fcft weiterreichen. In die K\u00f6pfe muss hinein: „KI“ ist kein vertrauensw\u00fcrdiges Werkzeug und muss daher grunds\u00e4tzlich gepr\u00fcft werden.<\/p>\n
W\u00e4hrend Medienkompetenz die Problematik hoffentlich abfedert, liegt das a) in weiter Ferne und wird b) nicht alles l\u00f6sen. Daher m\u00fcssen wir uns darauf einstellen: Quelloffene Software ben\u00f6tigt mehr Ressourcen. Da viele Projekte bereits vor der Welle an k\u00fcnstlich generiertem M\u00fcll schlecht ausgestattet waren, wird dies um so dringender. OSS darf nicht pauschal als kostenfrei angesehen werden. <\/p>\n
Es ist ein Gemeinschaftsprojekt, bei dem jeder das zur\u00fcck geben sollte, was in seinem Handlungsspielraum steht. Private Nutzer spenden vielleicht 5\u20ac und\/oder helfen bei Code, Tickets, Werbung usw. Gr\u00f6\u00dfere Unternehmen k\u00f6nnen 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\u00dfe Unternehmen zum Projekt beitragen und ob das ausreicht:23<\/a><\/sup><\/p>\n
\n
Normalerweise tragen sie \u00fcberhaupt nicht bei, in keiner Weise. \u00dcblicherweise 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\u00fcck: kein Code, kein Geld, keine Patches und keine Fehlerberichte. […]<\/p>\n<\/blockquote>\n
Fazit<\/h2>\n
K\u00fcnstliche Intelligenz<\/em> wird zunehmend eingesetzt, um quelloffene Software mit ungepr\u00fcften Sicherheitsmeldungen zu bombardieren. Dieser „KI M\u00fcll“ klingt plausibel, ist aber nahezu immer schwachsinn. Das pr\u00fcfen 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\u00e4chen. Vor allem unter den ehrenamtlichen Helfern. Neben dem Ressourcenmangel ist es frustrierend, seine Zeit damit zu verschwenden.<\/p>\n
Mit solchen Schattenseiten der Technologie werden wir leben lernen m\u00fcssen. Etwa mit noch mehr Sensibilisierung daf\u00fcr, dass „KI“ generierten Inhalten keinesfalls ungepr\u00fcft getraut werden darf<\/a>. Entwickler k\u00f6nnen Leitf\u00e4den nutzen, um die Zeitverschwendung einzugrenzen. Ob das ausreicht? Vielleicht, wenn wir unseren kollektiven Kurs \u00e4ndern. Derzeit wird „KI“ durch den Hype weiterhin kopflos f\u00fcr nahezu alles eingesetzt. Ein gewisser Anteil schwimmt dort mit – und glaubt mangels Medienkompetenz sogar, mit dem „KI M\u00fcll“ etwas gutes zu tun. In einer naiven Sicht ist das plausibel.<\/p>\n
Hier muss angesetzt werden. Nur so k\u00f6nnen wir von den Vorteilen, welche die Technik in manchen Bereichen bietet, profitieren. Anstatt prim\u00e4r Sch\u00e4den zu verursachen. Ansonsten wird OSS eines der Felder sein, die von v\u00f6llig falschem „KI“ Einsatz zerst\u00f6rt werden. Das kann keiner wollen – immerhin ist das die Grundlage f\u00fcr so ziemlich alles aus der heutigen IT. Und die wiederum ist nahezu \u00fcberall. Schon deswegen sollte quelloffene Software grunds\u00e4tzlich mehr Beachtung sowie Unterst\u00fctzung erhalten, als das aktuell der Fall ist. Die Well der Best\u00fcrzung nach Heartbleed 2014 scheint l\u00e4ngst wieder vergessen zu sein.<\/p>\n
Quellen<\/h2>\n
- \n
- https:\/\/the-decoder.de\/studie-open-source-und-knapp-3-000-entwickler-sind-das-digitale-fundament-der-weltwirtschaft\/<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.helpnetsecurity.com\/2025\/06\/19\/traditional-sast-tools\/<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.usenix.org\/system\/files\/usenixsecurity23-al-kassar.pdf<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/hackerone.com\/reports\/2199174<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/github.com\/curl\/curl\/issues\/12983<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/gist.github.com\/bagder\/07f7581f6e3d78ef37dfbfc81fd1d1cd<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/hackerone.com\/reports\/2871792<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/hackerone.com\/reports\/2887487<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/github.com\/mirror\/wget\/issues\/25<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.golem.de\/news\/open-source-schlampige-ki-bug-reports-nerven-entwickler-2412-191614.html<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/snyk.io\/es\/blog\/snyk-state-of-open-source-security-2023\/<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.telekom.com\/de\/blog\/konzern\/artikel\/-heartbleed-entwickler-spricht-ueber-fehler-bei-openssl-programmierung-64714<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.heise.de\/news\/Nach-Heartbleed-OpenSSL-Projekt-bittet-um-Unterstuetzung-2169393.html<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.spiegel.de\/netzwelt\/web\/core-infrastructure-initiative-firmen-gegen-heartbleed-a-966121.html<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.heise.de\/news\/Open-Source-Dilemma-auch-in-der-EU-Viele-sehen-Vorteile-zu-wenige-tragen-bei-10624469.html<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/de.slideshare.net\/slideshow\/giants-standing-on-the-shoulders-of-by-daniel-stenberg\/282693094#11<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.golem.de\/news\/open-source-curl-entwickler-poebelt-gegen-ki-scheisse-2401-180862.html<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/mastodon.social\/@bagder\/113619364982271341<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.linkedin.com\/posts\/danielstenberg_hackerone-curl-activity-7324820893862363136-glb1<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/hackerone.com\/reports\/3125832<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/media.ccc.de\/v\/froscon2025-3407-ai_slop_attacks_on_the_curl_project#t=2454<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.golem.de\/news\/wegen-ki-schrott-curl-entwickler-erwaegt-ende-der-bug-bounty-praemien-2507-198123.html<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/www.heise.de\/hintergrund\/Wie-KI-generierte-Bug-Reports-das-cURL-Projekt-hemmen-Ein-Interview-10607338.html?view=print<\/a> \u21a9\ufe0e<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Abseits der „KI wird uns alle t\u00f6ten“ Panikmache verursacht die Technik durchaus zunehmend reale Probleme. Und die sind so gar nicht intelligent: Open Source Projekte werden mit k\u00fcnstlich generierten Bugmeldungen geflutet. Das ist ein ernstes Problem, weil diese plausibel wirken – aber sich nach \u00dcberpr\u00fcfung nahezu immer als Bullshit entlarven. Doch gerade durch diese geschickte …<\/p>\n","protected":false},"author":5,"featured_media":15809,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"[{\"content\":\"https:\/\/the-decoder.de\/studie-open-source-und-knapp-3-000-entwickler-sind-das-digitale-fundament-der-weltwirtschaft\/<\/a>\",\"id\":\"5392d1e1-ee51-4c2c-b93b-9b5c4d09aadd\"},{\"content\":\"https:\/\/www.helpnetsecurity.com\/2025\/06\/19\/traditional-sast-tools\/<\/a>\",\"id\":\"3bd33ee4-ab59-4944-b816-7d9906612607\"},{\"content\":\"https:\/\/www.usenix.org\/system\/files\/usenixsecurity23-al-kassar.pdf<\/a>\",\"id\":\"3dc376ee-7a35-444d-866a-480779f0e380\"},{\"content\":\"https:\/\/hackerone.com\/reports\/2199174<\/a>\",\"id\":\"3c361fe1-f4e7-42bb-89ed-c1ab83375221\"},{\"content\":\"https:\/\/github.com\/curl\/curl\/issues\/12983<\/a>\",\"id\":\"23c3f222-1273-433a-b837-cf9cf3a4f6e5\"},{\"content\":\"https:\/\/gist.github.com\/bagder\/07f7581f6e3d78ef37dfbfc81fd1d1cd<\/a>\",\"id\":\"7439a547-963c-4919-8404-2feded14dc72\"},{\"content\":\"https:\/\/hackerone.com\/reports\/2871792<\/a>\",\"id\":\"194cb8ee-50f1-4e40-b718-bc5dd48217e1\"},{\"content\":\"https:\/\/hackerone.com\/reports\/2887487<\/a>\",\"id\":\"c9a9551c-5075-496c-941e-8ed6b1ba81bf\"},{\"content\":\"https:\/\/github.com\/mirror\/wget\/issues\/25<\/a>\",\"id\":\"c3d0d7c2-a57a-4b96-86bb-1f79f974d552\"},{\"content\":\"https:\/\/www.golem.de\/news\/open-source-schlampige-ki-bug-reports-nerven-entwickler-2412-191614.html<\/a>\",\"id\":\"acb38492-5bfd-4a3f-a945-3f096d6b06e9\"},{\"content\":\"https:\/\/snyk.io\/es\/blog\/snyk-state-of-open-source-security-2023\/<\/a>\",\"id\":\"6de356b7-b476-4825-9913-883fcf42a216\"},{\"content\":\"https:\/\/www.telekom.com\/de\/blog\/konzern\/artikel\/-heartbleed-entwickler-spricht-ueber-fehler-bei-openssl-programmierung-64714<\/a>\",\"id\":\"cf623d7d-4c75-4a31-8885-662d1d839426\"},{\"content\":\"https:\/\/www.heise.de\/news\/Nach-Heartbleed-OpenSSL-Projekt-bittet-um-Unterstuetzung-2169393.html<\/a>\",\"id\":\"3bc1c0e2-27ac-4a7f-99ff-f8af7f5bcd7d\"},{\"content\":\"https:\/\/www.spiegel.de\/netzwelt\/web\/core-infrastructure-initiative-firmen-gegen-heartbleed-a-966121.html<\/a>\",\"id\":\"460458ec-8ae7-4e8f-83e8-143918c9489d\"},{\"content\":\"https:\/\/www.heise.de\/news\/Open-Source-Dilemma-auch-in-der-EU-Viele-sehen-Vorteile-zu-wenige-tragen-bei-10624469.html<\/a>\",\"id\":\"7d4a536f-97e7-4c28-aa09-3cde947e1751\"},{\"content\":\"https:\/\/de.slideshare.net\/slideshow\/giants-standing-on-the-shoulders-of-by-daniel-stenberg\/282693094#11<\/a>\",\"id\":\"939e1f47-3646-47d8-badb-e329e945bd93\"},{\"content\":\"https:\/\/www.golem.de\/news\/open-source-curl-entwickler-poebelt-gegen-ki-scheisse-2401-180862.html<\/a>\",\"id\":\"5c7906a0-e73a-4f5b-a78a-a10e82c4b0c0\"},{\"content\":\"https:\/\/mastodon.social\/@bagder\/113619364982271341<\/a>\",\"id\":\"9ff1d49d-54ed-4cad-ad8b-7663b34afae4\"},{\"content\":\"https:\/\/www.linkedin.com\/posts\/danielstenberg_hackerone-curl-activity-7324820893862363136-glb1<\/a>\",\"id\":\"54a8b938-4140-4034-8765-940bdab20085\"},{\"content\":\"https:\/\/hackerone.com\/reports\/3125832<\/a>\",\"id\":\"046fb5de-79fe-4e31-833f-3d02877c889c\"},{\"content\":\"https:\/\/media.ccc.de\/v\/froscon2025-3407-ai_slop_attacks_on_the_curl_project#t=2454<\/a>\",\"id\":\"85861a9f-e0b0-43ec-837b-919c52f162de\"},{\"content\":\"https:\/\/www.golem.de\/news\/wegen-ki-schrott-curl-entwickler-erwaegt-ende-der-bug-bounty-praemien-2507-198123.html<\/a>\",\"id\":\"e974d4a0-8ab9-4dbb-991d-dd12729244f2\"},{\"content\":\"https:\/\/www.heise.de\/hintergrund\/Wie-KI-generierte-Bug-Reports-das-cURL-Projekt-hemmen-Ein-Interview-10607338.html?view=print<\/a>\",\"id\":\"cfb2b88d-ea9d-4864-89c5-ce2720d13516\"}]"},"categories":[61],"tags":[910,1079,960,700],"class_list":["post-15733","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-softwareentwicklung","tag-ki","tag-kuenstliche-intelligenz-2","tag-open-source-2","tag-open-source"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/15733","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=15733"}],"version-history":[{"count":21,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/15733\/revisions"}],"predecessor-version":[{"id":17043,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/15733\/revisions\/17043"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/15809"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=15733"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=15733"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=15733"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- https:\/\/www.helpnetsecurity.com\/2025\/06\/19\/traditional-sast-tools\/<\/a> \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/the-decoder.de\/studie-open-source-und-knapp-3-000-entwickler-sind-das-digitale-fundament-der-weltwirtschaft\/<\/a> \u21a9\ufe0e<\/a><\/li>\n