Open Source ist das größte Sicherheitsrisiko der Welt — Und wir alle ignorieren es
2 Min. Lesezeit
96 Prozent aller kommerziellen Software enthält Open-Source-Komponenten. Die meisten werden von einzelnen, unbezahlten Entwicklern gewartet. Log4j war nur der Anfang – die nächste Katastrophe schlummert in einer Bibliothek, die ein Maintainer in Nebraska in seiner Freizeit pflegt. Warum das Open-Source-Modell in einer Sicherheitskrise steckt.
Das Wichtigste in Kürze
- 96 Prozent der kommerziellen Codebases enthalten Open-Source-Bibliotheken – im Schnitt über 500 Dependencies pro Projekt
- Die Log4Shell-Schwachstelle (2021) betraf über 35.000 Java-Pakete und verursachte geschätzte 10 Milliarden Dollar Schaden
- Über 25 Prozent aller Open-Source-Projekte werden von einem einzigen Maintainer gewartet – ohne Vergütung, ohne Security-Audit
- Supply-Chain-Angriffe über kompromittierte Open-Source-Pakete stiegen 2024 um 740 Prozent gegenüber dem Vorjahr
Das xz-Utils-Warnsignal
Im März 2024 entdeckte ein Microsoft-Entwickler zufällig eine Backdoor in xz Utils – einer Komprimierungsbibliothek, die in praktisch jeder Linux-Distribution steckt. Die Backdoor war raffiniert: Ein Angreifer hatte sich über zwei Jahre als hilfsbereiter Contributor in das Projekt eingeschlichen, das Vertrauen des überarbeiteten Maintainers gewonnen und schließlich eine SSH-Backdoor eingebaut.
Der Angriff wurde nur durch Zufall entdeckt – weil ein Entwickler bemerkte, dass SSH-Logins 500 Millisekunden langsamer waren als erwartet. Wäre er nicht neugierig gewesen, hätte die Backdoor Millionen Server weltweit kompromittiert. Das ist kein Sicherheitsmodell. Das ist Glück.
Die unbequeme Wahrheit über „Given Enough Eyeballs“
Das Open-Source-Mantra lautet: „Given enough eyeballs, all bugs are shallow.“ Linus‘ Law. Die Idee, dass offener Code automatisch sicher ist, weil ihn jeder prüfen kann. Die Realität: Niemand prüft ihn.
OpenSSL – die Kryptobibliothek, die halb das Internet absichert – wurde jahrelang von zwei Personen gewartet, mit einem Jahresbudget von unter 10.000 Dollar. Heartbleed, eine der schlimmsten Schwachstellen der Internet-Geschichte, schlummerte zwei Jahre lang im Code. Nicht weil der Code geheim war, sondern weil niemand hinschaute.
Log4j – die Java-Logging-Bibliothek, die 2021 das Internet in den Ausnahmezustand versetzte – wurde von drei Freiwilligen gewartet. Sie hatten die Schwachstelle nicht absichtlich eingebaut. Sie hatten nur nicht die Ressourcen, jeden Code-Pfad auf Sicherheit zu prüfen.
Supply Chain: Der perfekte Angriffsvektor
Angreifer haben verstanden, dass der effizienteste Weg in Tausende Unternehmen nicht über deren Firewalls führt, sondern über ihre Dependencies. Ein kompromittiertes npm-Paket mit 10 Millionen wöchentlichen Downloads infiziert automatisch Tausende Build-Pipelines.
Die Angriffe werden sophistizierter: Typosquatting (Pakete mit ähnlichen Namen wie populäre Bibliotheken), Dependency Confusion (interne Paketnamen, die durch externe ersetzt werden), Maintainer Takeover (wie bei xz Utils). Und die Verteidigung? Fragmentiert, unterfinanziert und reaktiv.
Was getan werden muss
Finanzierung der kritischen Infrastruktur: Open-Source-Bibliotheken, die in mehr als 10.000 Projekten genutzt werden, sind de facto kritische Infrastruktur. Sie müssen als solche behandelt und finanziert werden – durch staatliche Programme, Industriekonsortien oder verbindliche Abgaben der Unternehmen, die darauf aufbauen.
Software Bill of Materials (SBOM): Jedes Unternehmen muss wissen, welche Open-Source-Komponenten in seinen Produkten stecken. SBOMs müssen verpflichtend werden – die EU arbeitet daran, aber die Umsetzung dauert zu lang.
Automatisierte Security-Audits: Jedes Update einer kritischen Bibliothek muss durch automatisierte Sicherheitsprüfung laufen, bevor es in Produktionssysteme gelangt. Tools wie Dependabot, Snyk oder Socket.dev helfen – aber sie müssen Standard werden, nicht Option.
Fazit: Open Source braucht ein neues Sicherheitsmodell
Open Source ist nicht das Problem – es ist die Lösung für unzählige technologische Herausforderungen. Aber das Sicherheitsmodell basiert auf einer Illusion: dass Freiwilligkeit und Transparenz ausreichen. Sie tun es nicht. Die Welt baut ihre digitale Infrastruktur auf unbezahlte Arbeit – und wundert sich, wenn sie zusammenbricht.
Key Facts
xz-Utils-Angriff: Die Backdoor wurde nur durch Zufall entdeckt – der Angreifer hatte zwei Jahre investiert und wäre ohne einen aufmerksamen Entwickler erfolgreich gewesen.
Finanzierungslücke: Die Linux Foundation schätzt, dass die globale Open-Source-Infrastruktur mindestens 2 Milliarden Dollar jährliche Investition benötigt – tatsächlich fließen unter 200 Millionen.
Häufige Fragen
Ist proprietäre Software sicherer als Open Source?
Nicht pauschal. Proprietäre Software hat dieselben Schwachstellen, sie werden nur weniger transparent behandelt. Der Unterschied: Proprietäre Software hat bezahlte Entwickler und Security-Teams. Open Source braucht dasselbe – ohne die Transparenz aufzugeben.
Was sollten Unternehmen sofort tun?
Erstens: SBOM für alle Produkte erstellen. Zweitens: Automated Dependency Scanning in die CI/CD-Pipeline integrieren. Drittens: Kritische Open-Source-Projekte, von denen man abhängt, finanziell unterstützen.
Wird der Cyber Resilience Act (CRA) das Problem lösen?
Der CRA der EU fordert Security by Design für Software-Produkte – einschließlich Open-Source-Komponenten. Das ist ein wichtiger Schritt, aber die Umsetzung muss sicherstellen, dass unbezahlte Maintainer nicht kriminalisiert werden, sondern unterstützt.
Verwandte Artikel
- Supply Chain Security 2026: So schützen Unternehmen ihre Software-Lieferkette
- Cybersecurity-Trends 2026: Die 7 Entwicklungen
- NIS2 und Geschäftsführerhaftung
Mehr aus dem MBF Media Netzwerk
- Cloud-Infrastruktur und DevSecOps auf cloudmagazin.com
- IT-Strategien für Entscheider auf digital-chiefs.de
Quelle Titelbild: Pexels
