Wachstum und Risiken im Bereich der Open-Source-Software 2025

Die digitale Landschaft entwickelt sich rapide, und Open-Source-Software (OSS) spielt dabei eine immer zentralere Rolle. Eine aktuelle Analyse von Sonatype beleuchtet die Dynamiken dieser Entwicklung, von einem signifikanten Anstieg im Konsum bis hin zu wachsenden Herausforderungen in den Bereichen Sicherheit und regulatorische Compliance.

Wachstum und Herausforderungen im Open-Source-Ökosystem

Im Jahr 2025 verzeichnete der Konsum von Open-Source-Software einen bemerkenswerten Anstieg von 67 % im Vergleich zum Vorjahr, was sich in 9,8 Billionen Downloads über die vier größten Repositories widerspiegelt. Dieses Wachstum unterstreicht die Integration von Open Source in moderne Entwicklungsprozesse, wobei CI/CD-Pipelines, ephemere Build-Umgebungen und aggressive Caching-Strategien eine entscheidende Rolle spielen.

Brian Fox, Mitbegründer und CTO von Sonatype, kommentiert diese Entwicklung: „In unserem elften Jahr dieser Analyse bestätigt sich das Open-Source-Prinzip: Wir alle sind schneller, weil wir teilen. Was sich geändert hat, ist das Ausmaß und die Risiken.“ Das Ökosystem hat sich zu einer kritischen Infrastruktur entwickelt, die jedoch oft mit der Anfälligkeit eines Hobbyprojekts betrieben wird. Die Herausforderung für 2026 besteht darin, die operativen und sicherheitstechnischen Kosten der Nutzung von Open Source in großem Maßstab zu bewältigen.

Die Industrialisierung von Malware im Open-Source-Bereich

Die Bedrohungslandschaft hat sich verändert. Früher isolierte Angriffe von „Script Kiddies“ sind weitgehend durch industrialisierte und oft staatlich geförderte Kampagnen abgelöst worden, die darauf abzielen, die Entwickler selbst zu kompromittieren. Im Jahr 2025 identifizierte Sonatype nahezu 455.000 neue bösartige Pakete, wodurch die Gesamtzahl bekannter schadhafter Komponenten auf über 1,233 Millionen anstieg. Angreifer nutzen Open-Source-Repositories zunehmend als zuverlässige Kanäle für die Malware-Verteilung, optimiert, um Perimeter-Verteidigungen zu umgehen und direkt auf Entwickler-Workstations ausgeführt zu werden.

Ein Beispiel hierfür ist die Lazarus Group, eine berüchtigte, mit Nordkorea verbundene Akteurengruppe. Ihre Kampagnen sind als „Produktionslinien“ und nicht als opportunistische Angriffe zu verstehen. Analysen zeigen, dass 97 % der Lazarus-Aktivitäten auf npm konzentriert waren und das JavaScript-Ökosystem ins Visier nahmen, wo die Abhängigkeitsfluktuation am höchsten ist. Diese Akteure setzen „Social Engineering Mimicry“ ein, indem sie Pakete veröffentlichen, die gängige Frontend-Tools wie Tailwind oder Vite-Plugins imitieren, um Entwickler zu täuschen.

Besonders besorgniserregend ist das Auftreten sich selbst replizierender Malware. Ende 2025 demonstrierte ein Wurm namens „Shai-Hulud“ die Fähigkeit zur autonomen Verbreitung. Er wartete nicht auf die manuelle Installation durch einen Entwickler, sondern kompromittierte Zugangsdaten von Maintainern und verbreitete sich ohne menschliches Eingreifen über Repositories und Maschinen. Für DevOps-Teams bedeutet dies, dass die Entwicklerumgebung nicht mehr hinter der Firewall liegt; sie ist der neue Perimeter.

Das Intelligenzdefizit von KI-Agenten

Während Unternehmen Large Language Models (LLMs) in ihre Entwicklungsworkflows integrieren, zeichnet sich eine „stille Krise“ der Datenqualität ab. KI-Coding-Assistenten sind leistungsfähig, leiden jedoch unter einer „zeitlichen Blindheit“, die sie zu riskanten Beratern für das Abhängigkeitsmanagement macht.

Tests mit fast 37.000 Upgrade-Empfehlungen ergaben, dass GPT-5 bei 27,8 % der Versionsempfehlungen „halluzinierte“, also nicht existierende Versionsnummern vorschlug. Die Modelle empfehlen häufig Paketversionen, die nicht existieren, oder, schlimmer noch, schlagen Upgrades auf Versionen vor, die nach dem Trainingszeitraum des Modells kompromittiert wurden.

Die Gefahr wird durch das Vertrauen der Entwickler in diese Tools verstärkt. Katie Norton, Research Manager bei IDC, erklärt, dass „Entwickler durchschnittlich 39 % des KI-generierten Codes ohne Überarbeitung akzeptieren, was verdeutlicht, wie oft KI-Ausgaben unverändert übernommen werden.“ Da diese Modelle keine Live-Verbindung zu Registry-Daten haben, können sie nicht wissen, dass ein zuvor sicheres Paket gestern kompromittiert wurde. In einem Fall empfahl ein KI-Agent selbstbewusst sweetalert2 Version 11.21.2, eine Version, die bekanntermaßen „Protestware“ mit politischen Payloads enthielt.

Während das Upgrade auf die „neueste“ Version oft als Best Practice beworben wird, kann dies blindlings zu finanziellen Einbußen führen. Analysen deuten darauf hin, dass eine unkontrollierte „neueste Version“-Strategie pro Anwendung etwa 29.500 US-Dollar an Entwicklerstunden kostet, die für die Behebung von Breaking Changes aufgewendet werden. KI-gesteuerte Empfehlungen schnitten in Effizienztests schlecht ab und schlugen oft Upgrades vor, die die Sicherheitslage der Anwendung verschlechterten. Die Lehre für Entwickler ist klar: KI benötigt Leitplanken. Automatisierung ohne Live-Intelligenz führt zu selbstbewussten Fehlern.

Der Kollaps von Vulnerability-Daten erhöht Open-Source-Risiken

Selbst wenn Teams versuchen, das Richtige zu tun, indem sie nach Schwachstellen suchen und diese umgehend beheben, werden sie oft durch die Datengrundlage im Stich gelassen. Das globale System zur Verfolgung von Schwachstellen kann mit der Geschwindigkeit der Software-Release-Zyklen nicht Schritt halten.

Im Jahr 2025 fehlte bei fast 65 % der Open-Source-CVEs (Common Vulnerabilities and Exposures) ein Schweregrad-Score der National Vulnerability Database (NVD). Dies führt dazu, dass Sicherheitsteams „im Blindflug“ agieren und nicht effektiv priorisieren können. Als Forscher diese unbewerteten Schwachstellen analysierten, stellten sie fest, dass 46 % tatsächlich „hoch“ oder „kritisch“ in ihrer Schwere waren.

Die durchschnittliche Zeit, die die NVD benötigte, um eine Schwachstelle zu bewerten, betrug im letzten Jahr 41 Tage, wobei einige bis zu einem Jahr dauerten. In einer Zeit, in der Exploits oft innerhalb weniger Stunden nach der Offenlegung verfügbar sind, macht eine Verzögerung von sechs Wochen die offiziellen Daten für die sofortige Triage nahezu unbrauchbar. Dieses Versagen wirkt sich auf die Konsumschicht aus. Organisationen laden weiterhin bekannte anfällige Komponenten in alarmierendem Tempo herunter, nicht unbedingt aufgrund von Nachlässigkeit, sondern weil das Signal-Rausch-Verhältnis in Sicherheitstools so schlecht ist.

„Alert Fatigue“ führt oft dazu, dass Teams Warnungen ignorieren, was zur anhaltenden Nutzung kompromittierter Bibliotheken wie Log4j Jahre nach Verfügbarkeit von Fixes führt. Allein im Jahr 2025 erreichte Log4Shell 42 Millionen Downloads und setzte Organisationen einer kritischen Schwachstelle aus, die vor über vier Jahren behoben wurde.

Transparenz als Betriebsgrundlage

Regierungen und Regulierungsbehörden haben die Geduld mit dem „Move fast and break things“-Ethos verloren. Transparenz wird zu einer rechtlichen Anforderung für die Geschäftstätigkeit. Schätzungen zufolge unterliegen 90 % der globalen Organisationen mittlerweile einem oder mehreren regulatorischen Mandaten, die den Nachweis der Software-Sicherheit erfordern. In der EU zwingen der Cyber Resilience Act (CRA) und die NIS2-Richtlinie Unternehmen, die Kontrolle über ihre Lieferkette nachzuweisen. In den USA hat die Executive Order 14028 Software Bills of Materials (SBOMs) zu einer Voraussetzung für die Bundesbeschaffung gemacht.

Dies verändert Compliance von einer reinen Abhakeübung zu einer Ingenieurdisziplin. Es reicht nicht mehr aus, nur eine Sicherheitsrichtlinie zu haben; Organisationen müssen Artefakte (z. B. SBOMs, signierte Provenienz und Attestierungen) vorlegen, die nachweislich während des Build-Prozesses generiert wurden. Für Anbieter und Unternehmensentwicklungsteams bedeutet dies, dass die Ära des „Vertrau mir einfach“ vorbei ist. Beschaffungsteams und Auditoren verlangen jetzt maschinenlesbare Beweise dafür, dass Software sicher erstellt wurde. Organisationen, die auf Anfrage keine saubere SBOM vorlegen können, werden vom Markt und von Verträgen ausgeschlossen.

Reduzierung der Belastung für Open-Source-Repositories

Die Belastung von Repositories wie Maven Central ist größtenteils selbstverschuldet. Der automatisierte Konsum belastet die gemeinsame Infrastruktur, wobei 86 % des Maven Central-Traffics im Jahr 2025 von Cloud Service Providern (CSPs) stammten. Redundante Downloads – bei denen CI/CD-Systeme dieselben Artefakte Tausende Male herunterladen – machen einen massiven Teil des Traffics aus. Einfache Änderungen, wie die Implementierung von dauerhaftem Caching und die Verwendung privater Repositories als Proxy für öffentliche Repositories, können diese Last dramatisch reduzieren.

Die Bewältigung der Sicherheitskrise erfordert einen „Block by Default“-Ansatz. Organisationen sollten Repository-Firewalls einsetzen, um zu verhindern, dass bekannte bösartige Komponenten und „Schatten-Downloads“ überhaupt in den Entwicklungslebenszyklus gelangen. Wenn eine Komponente nicht überprüft werden kann, sollte sie nicht installierbar sein.

Schließlich muss anerkannt werden, dass Software altert. End-of-Life (EOL)-Komponenten, die von Maintainern nicht mehr unterstützt werden, stellen ein permanentes Risiko dar. Daten zeigen, dass 18,5 % der NuGet-Komponenten und über 25 % der npm-Pakete in Unternehmensumgebungen effektiv aufgegeben wurden. Dies sind Verbindlichkeiten, die nicht gepatcht werden können; sie müssen entfernt werden.

Wie Christopher Robinson, CTO der Open Source Security Foundation, feststellt: „Der Bericht zeigt, wie Paket-Repositories und die darin enthaltene Software kritische Assets sind, die Unterstützung benötigen, wenn sie weiterhin Dienste für die Entwickler und Verbraucher bereitstellen wollen, die sie nutzen.“ Die Softwarelieferkette ist zum Nervensystem der globalen Wirtschaft geworden. Ihr Schutz erfordert einen Übergang vom passiven Konsum zu einer aktiven und intelligenten Governance.

Fazit

Die Zunahme des Open-Source-Konsums bietet immense Innovationsmöglichkeiten, birgt aber auch erhebliche Risiken. Die Industrialisierung von Malware, die Anfälligkeit von KI-Tools ohne Echtzeitdaten, mangelhafte Schwachstelleninformationen und der steigende regulatorische Druck erfordern eine proaktive und informierte Strategie. Unternehmen müssen ihre Praktiken anpassen, um die Vorteile von Open Source sicher und effizient nutzen zu können.

Bibliographie

Ryan Daws. (2026, 28. Januar). Sonatype: Open-source consumption jumps 67%. Developer-Tech. Abgerufen von https://www.developer-tech.com/news/sonatype-open-source-consumption-jumps-67-percent/ Sonatype. (2026, 28. Januar). Sonatype Research Reveals Open Source Malware Grows 75%. Sonatype. Abgerufen von https://www.sonatype.com/press-releases/sonatype-research-reveals-open-malware-grows-75-percent?hs_amp=true Business Insider. (2026, 28. Januar). Sonatype Research Reveals OSS Malware Grows 75% as Yearly Open Source Downloads Surpass 9.8 Trillion. Markets Insider. Abgerufen von https://markets.businessinsider.com/news/stocks/sonatype-research-reveals-oss-malware-grows-75-as-yearly-open-source-downloads-surpass-9-8-trillion-1035754779 Sonatype. (o. J.). Open Source Supply, Demand, and Security. Sonatype. Abgerufen von https://www.sonatype.com/state-of-the-software-supply-chain/2023/open-source-supply-and-demand Sonatype. (o. J.). Scale of Open Source. Sonatype. Abgerufen von https://www.sonatype.com/state-of-the-software-supply-chain/2024/scale Aaron Linskens. (2025, 27. Februar). The scale of open source: Growth, challenges, and key insights. Sonatype. Abgerufen von https://www.sonatype.com/blog/the-scale-of-open-source-growth-challenges-and-key-insights Jenna Barron. (2026, 28. Januar). Report: AI hallucinates 27% of upgrade recommendations for open source projects. SD Times. Abgerufen von https://sdtimes.com/security/report-ai-hallucinates-27-of-upgrade-recommendations-for-open-source-projects/ Sonatype. (2024, 10. Oktober). Sonatype’s 10th Annual State of the Software Supply Chain Report Reveals 156% Surge in Open Source Malware. Sonatype. Abgerufen von https://www.sonatype.com/en/press-releases/sonatypes-10th-annual-state-of-the-software-supply-chain-report Sonatype. (o. J.). A Decade of Evolution, Innovation, and Growing Risks. Sonatype. Abgerufen von https://www.sonatype.com/state-of-the-software-supply-chain/open-source-supply-demand-security Sonatype. (o. J.). 2026 State of the Software Supply Chain Report. Sonatype. Abgerufen von https://www.sonatype.com/8th-software-supply-chain-report-climb