{"id":33399,"date":"2026-04-16T13:09:19","date_gmt":"2026-04-16T11:09:19","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=33399"},"modified":"2026-04-17T13:13:03","modified_gmt":"2026-04-17T11:13:03","slug":"open-source-vulnerabilities-in-ai-era","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/open-source-vulnerabilities-in-ai-era\/33399\/","title":{"rendered":"Open-Source-Schwachstellen: Jetzt ein Problem f\u00fcr jedes Unternehmen"},"content":{"rendered":"

spezialisierte Softwareunternehmen und Technologiegiganten schlaflose N\u00e4chte. Doch die Zeiten haben sich ge\u00e4ndert. Inzwischen betreiben sogar kleine Unternehmen ihre eigenen Entwicklungsabteilungen, wodurch diese Probleme f\u00fcr alle relevant werden. In jedem zweiten Unternehmen<\/a> sind interne IT-Teams damit besch\u00e4ftigt, Code zu schreiben, Integrationen zu konfigurieren und Workflows zu automatisieren\u00a0\u2013 auch wenn das Kerngesch\u00e4ft absolut nichts mit Software zu tun hat. Anders funktioniert die moderne Gesch\u00e4ftseffizienz einfach nicht. Der Nebeneffekt ist eine neue Art von Software-Schwachstellen, die sich nicht einfach durch das neueste Windows-Update beheben lassen. Es ist leider viel komplizierter.<\/p>\n

Moderne Software-Entwicklung ist untrennbar mit Open-Source-Komponenten verkn\u00fcpft. Die damit verbundenen Risiken sind in den letzten Jahren jedoch sowohl vielf\u00e4ltiger als auch komplexer geworden. B\u00f6sartiger Code wird in popul\u00e4re Repositorys eingeschleust, fragmentierte und fehlerhafte Daten \u00fcber Programmschwachstellen werden h\u00e4ufiger, veraltete, anf\u00e4llige Komponenten werden systematisch verwendet und Abh\u00e4ngigkeitsketten werden immer komplexer.<\/p>\n

Schlechte Datenlage bei Open-Source-Schwachstellen<\/h2>\n

Selbst wenn das Schwachstellen-Management<\/a> f\u00fcr kommerzielle Drittanbieter-Software vorbildlich organisiert ist, muss dieser Prozess f\u00fcr Open-Source-Code komplett \u00fcberarbeitet werden muss. Die meistgenutzten \u00f6ffentlichen Datenbanken sind oft l\u00fcckenhaft und ungenau oder werden f\u00fcr Open Source einfach zu langsam aktualisiert. Dadurch wird die Priorisierung von Schwachstellen zum R\u00e4tselraten. Bei unvollst\u00e4ndigen Ausgangsdaten kann auch die beste Automatisierung nur wenig helfen.<\/p>\n

Nach Angaben von Sonatype haben etwa 65\u00a0% der Open-Source-Schwachstellen<\/a>, denen eine CVE-ID zugewiesen wurde, keinen Severity Score<\/a> (CVSS) in der NVD, der die am h\u00e4ufigsten verwendeten Wissensdatenbank f\u00fcr Schwachstellen. Fast 46\u00a0% dieser nicht bewerteten Schwachstellen w\u00fcrden bei einer ordnungsgem\u00e4\u00dfen Analyse als hoch eingestuft.<\/p>\n

Bei Schwachstellen, f\u00fcr die ein CVSS-Score verf\u00fcgbar ist, herrscht Durcheinander: Verschiedene Quellen sind sich nur in etwa 55\u00a0% der F\u00e4lle \u00fcber den Schweregrad einig. Ein und dieselbe Schwachstelle gilt m\u00f6glicherweise in einer Datenbank als kritisch, w\u00e4hrend sie in einer anderen nur mittlere Priorit\u00e4t hat. Auch in detaillierten Metadaten (z.\u00a0B. betroffene Paketversionen) wimmelt es oft von Fehlern und Unstimmigkeiten. Deshalb kann es passieren, dass Schwachstellen-Scanner, die f\u00fcr den Vergleich von Software-Versionen verantwortlich sind, falschen Alarm schlagen oder\u00a0\u2013 im Gegenteil\u00a0\u2013 bei Gefahr gar keine Warnung geben.<\/p>\n

Das Defizit an Daten \u00fcber Schwachstellen w\u00e4chst st\u00e4ndig. Gemeldete L\u00fccken werden zu langsam verarbeitet. In den letzten f\u00fcnf Jahren hat sich die Gesamtzahl der CVEs verdoppelt, w\u00e4hrend die Zahl der CVEs ohne Schweregrad-Angabe um das 37-fache gewachsen ist. Laut Tenable war der PoC-Exploit-Code (Proof-of-Concept) im Jahr 2025 normalerweise innerhalb einer Woche<\/a> nach der Entdeckung einer Schwachstelle \u00f6ffentlich verf\u00fcgbar. Es dauerte jedoch durchschnittlich 15\u00a0Tage, bis dieselbe Schwachstelle in der NVD eingetragen wurde. Untergeordnete Prozesse wie die Zuweisung eines CVSS-Scores verlaufen noch langsamer. Sonatype sch\u00e4tzt in derselben Studie<\/a>, dass es durchschnittlich 41\u00a0Tage dauert, bis ein CVSS-Score zugewiesen wird. Einige Fehler bleiben sogar bis zu einem Jahr ohne Bewertung.<\/p>\n

Veralteter Open-Source-Code<\/h2>\n

Laut HeroDevs finden sich in 5\u00a0bis 15\u00a0% aller Unternehmensprojekte<\/a> Bibliotheken, Anwendungen und Dienste, die nicht mehr gewartet werden. Dies sind Elemente, die entweder aufgegeben wurden oder deren Lebensdauer (EOL) abgelaufen ist. In f\u00fcnf g\u00e4ngigen Open-Source-Code-Registrys tummeln sich mindestens 81.000\u00a0Pakete, die bekannte Schwachstellen enthalten, aber zu veralteten, nicht mehr unterst\u00fctzten Versionen geh\u00f6ren. F\u00fcr diese m\u00e4ngelbehafteten Pakete wird es niemals offizielle Patches geben. Solche \u201eAltlasten\u201c machen etwa 10\u00a0% der Pakete in Maven Central und PyPI aus, und sogar sagenhafte 25\u00a0% in npm.<\/p>\n

Die Verwendung dieser Art von Open-Source-Code behindert die standardm\u00e4\u00dfige Patch-Verwaltung: Abh\u00e4ngigkeiten, die nicht mehr unterst\u00fctzt werden, k\u00f6nnen weder automatisch noch manuell aktualisiert werden. Wenn EOL-Versionen nicht in den offiziellen Schwachstellen-Bulletins erw\u00e4hnt werden, werden sie m\u00f6glicherweise als \u201efehlerfrei\u201c eingestuft und von Sicherheitsscannern ignoriert.<\/p>\n

Ein Paradebeispiel daf\u00fcr ist Log4Shell<\/a>, eine kritische Schwachstelle (CVSS 10), die bereits 2021 in der beliebten Log4j-Bibliothek entdeckt wurde. 2025 entfielen 40\u00a0Millionen von 300\u00a0Millionen Log4j-Downloads auf die verwundbare Version<\/a>. Dabei handelt es sich um eine der ber\u00fcchtigtsten Schwachstellen in der Geschichte, die aktiv ausgenutzt, vom Entwickler gepatcht und in jedem gr\u00f6\u00dferen nachgelagerten Produkt behoben wurde. Wesentlich schlechter steht es um weniger bekannte Sicherheitsl\u00fccken.<\/p>\n

Dieses Problem wird durch mangelnde Sichtbarkeit noch vertieft. Viele Unternehmen haben nicht die erforderlichen Tools, um Abh\u00e4ngigkeitsstrukturen vollst\u00e4ndig abzubilden oder die spezifischen Pakete und Versionen, die zu ihrem Software-Inventar geh\u00f6ren, komplett zu \u00fcberblicken. Aus diesem Grund bleiben veraltete Komponenten oft unsichtbar und werden \u00fcberhaupt nicht zur Wartung vorgesehen.<\/p>\n

Malware in Open-Source-Registrys<\/h2>\n

Angriffe mit infizierten oder inh\u00e4rent sch\u00e4dlichen Open-Source-Paketen z\u00e4hlen zu den am schnellsten wachsenden Bedrohungen f\u00fcr die Software-Lieferkette. Nach Angaben von Kaspersky-Forschern<\/a> wurden bis Ende\u00a02024 etwa 14.000\u00a0b\u00f6sartige Pakete in g\u00e4ngigen Registrys gefunden\u00a0\u2013 ein Anstieg um 48\u00a0% gegen\u00fcber dem Vorjahr. F\u00fcr 2025 meldete Sonatype einen noch explosiveren Anstieg: Mehr als 450.000\u00a0b\u00f6sartige Pakete wurden erkannt.<\/p>\n

Die Motive f\u00fcr diese Angriffe sind ganz unterschiedlich: Diebstahl von Kryptoguthaben, Abgreifen der Anmeldeinformationen von Entwicklern, Wirtschaftsspionage, Zugriff auf gesch\u00e4ftliche Infrastrukturen \u00fcber CI\/CD-Pipelines oder auch Kompromittierung \u00f6ffentlicher Server f\u00fcr Spam- und Phishing-Kampagnen. Diese Taktiken werden sowohl von APT-Spionagegruppen<\/a> als auch von finanziell motivierten Cyberkriminellen<\/a> genutzt. Immer h\u00e4ufiger ist die Kompromittierung eines Open-Source-Pakets der erste Schritt zu einem mehrstufigen Angriff auf Unternehmen.<\/p>\n

Es gibt schon eine ganze Reihe von Angriffsszenarien: Kompromittierung der Anmeldedaten eines legitimen Mitarbeiters von Open-Source-Paketen, Ver\u00f6ffentlichung einer \u201epraktischen\u201c Bibliothek mit eingebettetem Schadcode oder Ver\u00f6ffentlichung einer b\u00f6sartigen Bibliothek mit einem t\u00e4uschend \u00e4hnlichen Namen. Ein besonders alarmierender Trend war 2025 die Zunahme automatisierter, wurmartiger Angriffe. Das gef\u00e4hrlichste Beispiel ist die Shai-Hulud-Kampagne<\/a>. Dabei stahl b\u00f6sartiger Code GitHub- und npm-Token, infizierte immer wieder neue Pakete und breitete sich letztendlich auf \u00fcber 700 npm-Pakete und Zehntausende von Repositorys aus. Zudem wurden CI\/CD-Geheimnisse und Cloud-Zugriffsschl\u00fcssel preisgegeben.<\/p>\n

Obwohl dieses Szenario technisch betrachtet nichts mit Schwachstellen zu tun hat, sind f\u00fcr die Eind\u00e4mmung dieselben Sicherheitstools und -richtlinien erforderlich, die auch f\u00fcr das Schwachstellen-Management eingesetzt werden.<\/p>\n

KI-Agenten erh\u00f6hen die Risiken bei Open-Source-Code<\/h2>\n

KI-Agenten werden derzeit \u00fcberall und leider v\u00f6llig \u00fcberst\u00fcrzt in die Software-Entwicklung integriert\u00a0\u2013 mit erheblichen Vorteilen f\u00fcr die Entwicklungsgeschwindigkeit, wobei jedoch gleichzeitig jeder Fehler multipliziert wird. Ohne strenge Kontrolle und klar definierte Richtlinien ist KI-generierter Code ausgesprochen anf\u00e4llig. Untersuchungen haben gezeigt: 45\u00a0% des KI-generierten Codes enthalten Fehler aus den OWASP-Top-10<\/a> und 20\u00a0% der bereitgestellten KI-basierten Anwendungen weisen gef\u00e4hrliche Konfigurationsfehler auf. Der Grund: KI-Modelle werden mit riesigen Datens\u00e4tzen trainiert, die gro\u00dfe Mengen an veraltetem Code, Demonstrationscode oder reinem Trainingscode enthalten. Diese systemischen Probleme bestehen auch, wenn ein KI-Modell entscheidet, welche Open-Source-Komponenten in ein Projekt aufgenommen werden sollen. Das Modell wei\u00df oft nicht, welche Paketversionen derzeit existieren oder welche als anf\u00e4llig gelten. Stattdessen schl\u00e4gt es eine Abh\u00e4ngigkeitsversion vor, die aus seinen Trainingsdaten stammt und h\u00f6chstwahrscheinlich veraltet ist. Und dann Halluzinationen: In einigen F\u00e4llen versuchen Modelle, nicht vorhandene Versionen oder Bibliotheken aufzurufen. Dies ebnet den Weg f\u00fcr Angriffe durch eine gezielte Verwirrung der Abh\u00e4ngigkeitsverh\u00e4ltnisse<\/a>.<\/p>\n

2025 empfahlen sogar f\u00fchrende LLMs in 27\u00a0% der F\u00e4lle<\/a> falsche Abh\u00e4ngigkeitsversionen, die ihrer Fantasie entsprungen waren.<\/p>\n

Kann KI alle Schwachstellen beheben?<\/h2>\n

Die Idee ist einfach und verlockend: Du richtest einen KI-Agenten ein, der deine Codebasis auf Schwachstellen durchsucht und Fehler behebt. Leider kann KI dieses Problem nicht vollst\u00e4ndig l\u00f6sen. Die bereits angesprochenen, grundlegenden H\u00fcrden gelten sowohl f\u00fcr KI-Agenten also auch f\u00fcr menschliche Entwickler. Wenn Daten \u00fcber Schwachstellen fehlen oder unzuverl\u00e4ssig sind, ist es sinnlos, nach bekannten Schwachstellen zu suchen\u00a0\u2013 dann geht es um neue Schwachstellen. Und diese Suche ist ein sehr ressourcenintensiver Prozess, der Spezialwissen erfordert und f\u00fcr die meisten Unternehmen unerreichbar ist.<\/p>\n

Wenn eine Schwachstelle in einer veralteten oder abgelaufenen Komponente erkannt wird, kann ein KI-Agent sie zudem nicht automatisch beheben. Daf\u00fcr m\u00fcssen geeignete Patches entwickelt werden oder eine komplexe Migration ist erforderlich. Und wenn ein Fehler tief in einer Abh\u00e4ngigkeitskette verborgen ist, \u00fcbersieht die KI ihn wahrscheinlich vollkommen.<\/p>\n

Was tun?<\/h2>\n

Um die oben beschriebenen Risiken zu minimieren, muss der Prozess f\u00fcr das Schwachstellen-Management erweitert werden: Richtlinien f\u00fcr den Download von Open-Source-Paketen, Nutzungsregeln f\u00fcr KI-Assistenten und Prozesse f\u00fcr die Software-Erstellung. Dazu geh\u00f6ren:<\/p>\n