Open-Source-Schwachstellen: Jetzt ein Problem für jedes Unternehmen

Wie der KI-Boom und die zunehmende Abhängigkeit von Open-Source-Komponenten die „Sicherheitsschuld“ von Unternehmen erhöhen – und was du dagegen tun kannst

Risiken, die bei der Entwicklung und Nutzung von Open-Source-Software auftreten

spezialisierte Softwareunternehmen und Technologiegiganten schlaflose Nächte. Doch die Zeiten haben sich geändert. Inzwischen betreiben sogar kleine Unternehmen ihre eigenen Entwicklungsabteilungen, wodurch diese Probleme für alle relevant werden. In jedem zweiten Unternehmen sind interne IT-Teams damit beschäftigt, Code zu schreiben, Integrationen zu konfigurieren und Workflows zu automatisieren – auch wenn das Kerngeschäft absolut nichts mit Software zu tun hat. Anders funktioniert die moderne Geschäftseffizienz 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.

Moderne Software-Entwicklung ist untrennbar mit Open-Source-Komponenten verknüpft. Die damit verbundenen Risiken sind in den letzten Jahren jedoch sowohl vielfältiger als auch komplexer geworden. Bösartiger Code wird in populäre Repositorys eingeschleust, fragmentierte und fehlerhafte Daten über Programmschwachstellen werden häufiger, veraltete, anfällige Komponenten werden systematisch verwendet und Abhängigkeitsketten werden immer komplexer.

Schlechte Datenlage bei Open-Source-Schwachstellen

Selbst wenn das Schwachstellen-Management für kommerzielle Drittanbieter-Software vorbildlich organisiert ist, muss dieser Prozess für Open-Source-Code komplett überarbeitet werden muss. Die meistgenutzten öffentlichen Datenbanken sind oft lückenhaft und ungenau oder werden für Open Source einfach zu langsam aktualisiert. Dadurch wird die Priorisierung von Schwachstellen zum Rätselraten. Bei unvollständigen Ausgangsdaten kann auch die beste Automatisierung nur wenig helfen.

Nach Angaben von Sonatype haben etwa 65 % der Open-Source-Schwachstellen, denen eine CVE-ID zugewiesen wurde, keinen Severity Score (CVSS) in der NVD, der die am häufigsten verwendeten Wissensdatenbank für Schwachstellen. Fast 46 % dieser nicht bewerteten Schwachstellen würden bei einer ordnungsgemäßen Analyse als hoch eingestuft.

Bei Schwachstellen, für die ein CVSS-Score verfügbar ist, herrscht Durcheinander: Verschiedene Quellen sind sich nur in etwa 55 % der Fälle über den Schweregrad einig. Ein und dieselbe Schwachstelle gilt möglicherweise in einer Datenbank als kritisch, während sie in einer anderen nur mittlere Priorität hat. Auch in detaillierten Metadaten (z. B. betroffene Paketversionen) wimmelt es oft von Fehlern und Unstimmigkeiten. Deshalb kann es passieren, dass Schwachstellen-Scanner, die für den Vergleich von Software-Versionen verantwortlich sind, falschen Alarm schlagen oder – im Gegenteil – bei Gefahr gar keine Warnung geben.

Das Defizit an Daten über Schwachstellen wächst ständig. Gemeldete Lücken werden zu langsam verarbeitet. In den letzten fünf Jahren hat sich die Gesamtzahl der CVEs verdoppelt, während 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 nach der Entdeckung einer Schwachstelle öffentlich verfügbar. Es dauerte jedoch durchschnittlich 15 Tage, bis dieselbe Schwachstelle in der NVD eingetragen wurde. Untergeordnete Prozesse wie die Zuweisung eines CVSS-Scores verlaufen noch langsamer. Sonatype schätzt in derselben Studie, dass es durchschnittlich 41 Tage dauert, bis ein CVSS-Score zugewiesen wird. Einige Fehler bleiben sogar bis zu einem Jahr ohne Bewertung.

Veralteter Open-Source-Code

Laut HeroDevs finden sich in 5 bis 15 % aller Unternehmensprojekte Bibliotheken, Anwendungen und Dienste, die nicht mehr gewartet werden. Dies sind Elemente, die entweder aufgegeben wurden oder deren Lebensdauer (EOL) abgelaufen ist. In fünf gängigen Open-Source-Code-Registrys tummeln sich mindestens 81.000 Pakete, die bekannte Schwachstellen enthalten, aber zu veralteten, nicht mehr unterstützten Versionen gehören. Für diese mängelbehafteten Pakete wird es niemals offizielle Patches geben. Solche „Altlasten“ machen etwa 10 % der Pakete in Maven Central und PyPI aus, und sogar sagenhafte 25 % in npm.

Die Verwendung dieser Art von Open-Source-Code behindert die standardmäßige Patch-Verwaltung: Abhängigkeiten, die nicht mehr unterstützt werden, können weder automatisch noch manuell aktualisiert werden. Wenn EOL-Versionen nicht in den offiziellen Schwachstellen-Bulletins erwähnt werden, werden sie möglicherweise als „fehlerfrei“ eingestuft und von Sicherheitsscannern ignoriert.

Ein Paradebeispiel dafür ist Log4Shell, eine kritische Schwachstelle (CVSS 10), die bereits 2021 in der beliebten Log4j-Bibliothek entdeckt wurde. 2025 entfielen 40 Millionen von 300 Millionen Log4j-Downloads auf die verwundbare Version. Dabei handelt es sich um eine der berüchtigtsten Schwachstellen in der Geschichte, die aktiv ausgenutzt, vom Entwickler gepatcht und in jedem größeren nachgelagerten Produkt behoben wurde. Wesentlich schlechter steht es um weniger bekannte Sicherheitslücken.

Dieses Problem wird durch mangelnde Sichtbarkeit noch vertieft. Viele Unternehmen haben nicht die erforderlichen Tools, um Abhängigkeitsstrukturen vollständig abzubilden oder die spezifischen Pakete und Versionen, die zu ihrem Software-Inventar gehören, komplett zu überblicken. Aus diesem Grund bleiben veraltete Komponenten oft unsichtbar und werden überhaupt nicht zur Wartung vorgesehen.

Malware in Open-Source-Registrys

Angriffe mit infizierten oder inhärent schädlichen Open-Source-Paketen zählen zu den am schnellsten wachsenden Bedrohungen für die Software-Lieferkette. Nach Angaben von Kaspersky-Forschern wurden bis Ende 2024 etwa 14.000 bösartige Pakete in gängigen Registrys gefunden – ein Anstieg um 48 % gegenüber dem Vorjahr. Für 2025 meldete Sonatype einen noch explosiveren Anstieg: Mehr als 450.000 bösartige Pakete wurden erkannt.

Die Motive für diese Angriffe sind ganz unterschiedlich: Diebstahl von Kryptoguthaben, Abgreifen der Anmeldeinformationen von Entwicklern, Wirtschaftsspionage, Zugriff auf geschäftliche Infrastrukturen über CI/CD-Pipelines oder auch Kompromittierung öffentlicher Server für Spam- und Phishing-Kampagnen. Diese Taktiken werden sowohl von APT-Spionagegruppen als auch von finanziell motivierten Cyberkriminellen genutzt. Immer häufiger ist die Kompromittierung eines Open-Source-Pakets der erste Schritt zu einem mehrstufigen Angriff auf Unternehmen.

Es gibt schon eine ganze Reihe von Angriffsszenarien: Kompromittierung der Anmeldedaten eines legitimen Mitarbeiters von Open-Source-Paketen, Veröffentlichung einer „praktischen“ Bibliothek mit eingebettetem Schadcode oder Veröffentlichung einer bösartigen Bibliothek mit einem täuschend ähnlichen Namen. Ein besonders alarmierender Trend war 2025 die Zunahme automatisierter, wurmartiger Angriffe. Das gefährlichste Beispiel ist die Shai-Hulud-Kampagne. Dabei stahl bösartiger Code GitHub- und npm-Token, infizierte immer wieder neue Pakete und breitete sich letztendlich auf über 700 npm-Pakete und Zehntausende von Repositorys aus. Zudem wurden CI/CD-Geheimnisse und Cloud-Zugriffsschlüssel preisgegeben.

Obwohl dieses Szenario technisch betrachtet nichts mit Schwachstellen zu tun hat, sind für die Eindämmung dieselben Sicherheitstools und -richtlinien erforderlich, die auch für das Schwachstellen-Management eingesetzt werden.

KI-Agenten erhöhen die Risiken bei Open-Source-Code

KI-Agenten werden derzeit überall und leider völlig überstürzt in die Software-Entwicklung integriert – mit erheblichen Vorteilen für die Entwicklungsgeschwindigkeit, wobei jedoch gleichzeitig jeder Fehler multipliziert wird. Ohne strenge Kontrolle und klar definierte Richtlinien ist KI-generierter Code ausgesprochen anfällig. Untersuchungen haben gezeigt: 45 % des KI-generierten Codes enthalten Fehler aus den OWASP-Top-10 und 20 % der bereitgestellten KI-basierten Anwendungen weisen gefährliche Konfigurationsfehler auf. Der Grund: KI-Modelle werden mit riesigen Datensätzen trainiert, die große 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ß oft nicht, welche Paketversionen derzeit existieren oder welche als anfällig gelten. Stattdessen schlägt es eine Abhängigkeitsversion vor, die aus seinen Trainingsdaten stammt und höchstwahrscheinlich veraltet ist. Und dann Halluzinationen: In einigen Fällen versuchen Modelle, nicht vorhandene Versionen oder Bibliotheken aufzurufen. Dies ebnet den Weg für Angriffe durch eine gezielte Verwirrung der Abhängigkeitsverhältnisse.

2025 empfahlen sogar führende LLMs in 27 % der Fälle falsche Abhängigkeitsversionen, die ihrer Fantasie entsprungen waren.

Kann KI alle Schwachstellen beheben?

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ändig lösen. Die bereits angesprochenen, grundlegenden Hürden gelten sowohl für KI-Agenten also auch für menschliche Entwickler. Wenn Daten über Schwachstellen fehlen oder unzuverlässig sind, ist es sinnlos, nach bekannten Schwachstellen zu suchen – dann geht es um neue Schwachstellen. Und diese Suche ist ein sehr ressourcenintensiver Prozess, der Spezialwissen erfordert und für die meisten Unternehmen unerreichbar ist.

Wenn eine Schwachstelle in einer veralteten oder abgelaufenen Komponente erkannt wird, kann ein KI-Agent sie zudem nicht automatisch beheben. Dafür müssen geeignete Patches entwickelt werden oder eine komplexe Migration ist erforderlich. Und wenn ein Fehler tief in einer Abhängigkeitskette verborgen ist, übersieht die KI ihn wahrscheinlich vollkommen.

Was tun?

Um die oben beschriebenen Risiken zu minimieren, muss der Prozess für das Schwachstellen-Management erweitert werden: Richtlinien für den Download von Open-Source-Paketen, Nutzungsregeln für KI-Assistenten und Prozesse für die Software-Erstellung. Dazu gehören:

Weitere Informationen zur Verwaltung von Open-Source-Schwachstellen findest du in unserem speziellen Blog-Artikel.

Tipps
  • Für alle anderen Länder