Das Open Source-Paradoxon: Risiken, Fairness und Akzeptanz

Open Source war schon immer ein Paradoxon: Es handelt sich dabei um Software, die von engagierten Entwicklerinnen und Entwicklern entwickelt und kostenlos verfügbar gemacht, dabei jedoch von einigen der größten Unternehmen der Welt monetarisiert und finanziert wird. Ein Außenseiter, einst sogar als „Krebsgeschwür“ bezeichnet, und doch die größte Triebkraft für Innovation und technologischen Fortschritt, die wir je gesehen haben. In der Welt von Open Source wird es immer Widersprüche geben, aber nirgendwo sind diese so ausgeprägt wie beim Verständnis von Sicherheitslücken.

Vor 25 Jahren wurde das CVE-Programm (Common Vulnerabilities and Exposures) ins Leben gerufen, um die Benennung und Nachverfolgung von Softwareschwachstellen zu standardisieren. In einer Zeit, in der die Identifizierung einer bestimmten Vulnerability oft nicht eindeutig möglich war und es mehrere Probleme in gängiger Software wie Sendmail gab, entstand CVE, um Klarheit und Struktur zu schaffen. Es gab zwar frühe Projekte wie Security Fokus und Bugtraq, aber das CVE von MITRE bot ein dringend benötigtes globales System. Im ersten Jahr, das war 1999, wurden 894 Vulnerabilities katalogisiert, was die schon frühe Notwendigkeit einer konsistenten Identifizierung auch bei einer relativ kleinen Anzahl unterstreicht. Dieser historische Kontext ist entscheidend für das Verständnis der Herausforderungen, denen wir heute mit CVEs gegenüberstehen.

Die Landschaft der Softwareschwachstellen hat sich in dieser Zeit stark verändert. Allein in den ersten 6 Jahren des Programms stieg die Zahl der zugewiesenen CVEs um über 450 %, was auf die allgemeine Akzeptanz zurückzuführen ist. Dieses Wachstum setzte sich exponentiell fort und erreichte 2017 fast 15.000 CVEs, eine Steigerung von 125 % innerhalb von nur 2 Jahren. Bis 2023 stieg die Anzahl um weitere 50 % auf über 29.000. Dieses explosive Wachstum verdeutlicht die zunehmende Komplexität und Verfügbarkeit von Software sowie die Einführung von CVE durch immer mehr Anbieter.

Die Anzahl der Vulnerabilities wächst weiterhin dramatisch. 2024 stieg die Zahl der zugewiesenen CVEs um 39 % auf über 40.000, was teilweise auf den Status des Linux-Kernels als CVE Numbering Authority (CNA) zurückzuführen ist. Dieses Wachstum könnte sich erheblich beschleunigen, wenn andere Softwaresektoren, wie etwa die Entwicklung mobiler Apps oder Spiele, damit beginnen, CVEs offiziell zu erfassen. Aufgrund dieser enormen Anzahl müssen wir unsere Strategie für das Vulnerability Management grundlegend überdenken.

„Alles patchen“ ist nicht nachhaltig

Wir haben lange daran festgehalten, dass das bestehende Mantra „alles patchen“ zwar in einfacheren Zeiten vielleicht umsetzbar ist, aber in den komplexen Umgebungen von heute nicht nachhaltig und strategisch nicht solide ist. Es erfolgt ohne echte Risikobeurteilung. Nicht jede Vulnerability erfordert eine sofortige, ressourcenintensive Behebung. Faktoren wie Ausnutzbarkeit und potenzielle Auswirkungen sind von entscheidender Bedeutung. Alle identifizierten Probleme gleich zu behandeln, ist vergleichbar mit der Empfehlung aggressiver Operationen bei sowohl gut- als auch bösartigen Tumoren – dabei werden das tatsächliche Bedrohungsniveau und das mit der Behandlung selbst verbundene Risiko ignoriert.

Die entscheidende Kennzahl für die Priorisierung von Maßnahmen ist die tatsächliche Ausnutzung. Die Datenanalyse, die Quellen wie den KEV-Katalog (Known Exploited Vulnerabilities) der Cybersecurity and Infrastructure Security Agency (CISA) nutzt, zeigt konsistent, dass die Exploit-Quoten mit deutlich unter 0,5 % pro Jahr bemerkenswert niedrig bleiben. Dies bedeutet, dass etwa 1 von 200 Vulnerabilities aktiv und böswillig ausgenutzt wird. In diesem Wissen sollten wir uns auf pragmatische, risikobasierte Ansätze konzentrieren.

Unser Fokus muss sich auf die Vulnerabilities verlagern, die am wahrscheinlichsten ausgenutzt werden und gleichzeitig erheblichen Schaden anrichten können. Dazu zählen typischerweise diejenigen, die einen nicht authentifizierten Remote-Zugriff mit einer hohen Berechtigungseskalation ermöglichen – was wir als kritisch oder wichtig bezeichnen würden. Indem wir die Fehlerbehebung auf diese Vulnerabilities mit hohem Risiko und großen Auswirkungen konzentrieren, können wir die Risikominderung mit den verfügbaren Ressourcen maximieren. Dies bedeutet zwangsläufig, dass Sie strategisch das geringere Restrisiko akzeptieren, das von Vulnerabilities ausgeht, die wahrscheinlich nicht angegriffen werden oder bei Ausnutzung keine wesentlichen Auswirkungen haben, also meist Probleme mit geringem und mittlerem Schweregrad. 

Bei einem effektiven Risikomanagement geht es nicht um die Beseitigung aller Vulnerabilities. Es geht darum, die Prioritäten auf die zu setzen, die eine echte, mögliche Bedrohung darstellen, und bewältigbare Risiken bewusst in Kauf zu nehmen.

Was hat das mit Open Source zu tun?

Bedenken im Hinblick auf ungepatchte Vulnerabilities konzentrieren sich oft auf Open Source, und zwar in erster Linie aufgrund der Transparenz. Wir alle können sowohl den Code als auch die CVEs sehen. Im Gegensatz dazu geben proprietäre Anbieter häufig keine Informationen zu Vulnerabilities mit geringen Auswirkungen weiter, deren Behebung sie für nicht notwendig erachten, wodurch eine undurchsichtige Risikolandschaft entsteht. Selbst ein kleiner Fehler, der in Open Source zu einer öffentlichen CVE führt, wird möglicherweise nicht gemeldet, nicht behoben oder in proprietärer Software stillschweigend gepatcht.

Diese unterschiedliche Sichtbarkeit führt zu einer Doppelmoral. Richtlinien, die „keine bekannten Vulnerabilities“ verlangen, zielen auf die Transparenz von Open Source ab, nicht unbedingt auf das höhere Risiko. Entscheidend ist, dass Ihre Organisation das Risiko nicht offengelegter kleiner Fehler in der proprietären Software, die Sie täglich verwenden, bereits implizit akzeptiert. Echtes Risikomanagement erfordert, dies zu erkennen. Wir müssen eine konsistente, explizite Risikobewertung vornehmen, die sich auf die mögliche Ausnutzbarkeit und die Auswirkungen auf Software konzentriert, anstatt die inhärente Transparenz von Open Source zu bestrafen.

Echte Fairness im Bereich des Vulnerability Managements erfordert, dass wir anerkennen, dass Open Source anders ist. Open Source ist von Grund auf transparenter (und das ist auch gut so) und scheint daher mehr Vulnerabilities zu haben. Open Source erfordert die explizite Akzeptanz des Risikos, das wir bei proprietärer Software implizit in Kauf nehmen.

Dazu gibt es einige interessante Daten. Wenn wir Red Hat und die Daten aus unserem 2024 Risk Report mit denen eines bekannten großen Anbieters von proprietärer Software vergleichen, erhalten wir einige sehr interessante Erkenntnisse, die die oben genannte Hypothese bestätigen. Wenn der proprietäre Anbieter nicht nur Bugs mit großen Auswirkungen entwickelt (also: leicht ausnutzbar), würden wir eine ähnliche Verteilung von kritischen und wichtigen Problemen bis hin zu mittleren und niedrigen Problemen erwarten. Mit anderen Worten: Wenn die dadurch verursachten Sicherheitslücken nicht immer groß, schlimm und hässlich sind, würden Sie eine höhere Anzahl von weniger schwerwiegenden Sicherheitslücken erwarten. Die Zahlen zeigen jedoch eine fast unbedeutende Anzahl von Problemen mit geringem Schweregrad. Dieser Anbieter verwendet dieselbe vierstufige Bewertungsskala für den Schweregrad wie Red Hat.

Metriken in der Meldung von Vulnerabilities können ein trügerisches Bild vermitteln. Die höhere Anzahl an CVEs mit geringerem Schweregrad, die von Open Source-Projekten transparent gemeldet wird (92 % der Vulnerabilities bei Red Hat wurden 2024 als „Mittel“ und „Niedrig“ eingestuft) im Vergleich zu diesem proprietären Anbieter (mit 5,5 % der Vulnerabilities „Mittel“ und „Niedrig“ in 2024), verdeutlicht nicht das relative Risiko, da es sich in erster Linie um unterschiedliche Offenlegungsphilosophien handelt.

Anstatt reinem Volumen oder Schweregrad nachzujagen, ist es besser, sich auf den entscheidenden Faktor zu konzentrieren: die tatsächliche Ausnutzung. 2024 waren nur 0,26 % der Open Source Vulnerabilities (11 von über 4.200), die Software von Red Hat betrafen, bekanntermaßen auf beliebigen Plattformen ausgenutzt worden. Eine Priorisierung ausschließlich auf Basis der Anzahl führt zu einem erheblichen Ressourcenverbrauch bei Problemen, die praktisch nur eine minimale Bedrohung darstellen.

Sowohl proprietäre als auch Open Source-Anbieter priorisieren grundsätzlich die Problembehebung. Der entscheidende Unterschied ist oft die Transparenz bei ungepatchten Vulnerabilities mit geringeren Auswirkungen. Dieses Restrisiko von Closed Source-Software akzeptieren wir bereits implizit. Es ist an der Zeit, dieselbe pragmatische, risikobasierte Bewertung explizit auf sämtliche Software anzuwenden, einschließlich Open Source. Bei der Philosophie sind wir uns einig: Korrigieren Sie die wichtigen Dinge, und vernachlässigen Sie die unwichtigen Dinge.

Als führendes Unternehmen im Bereich Sicherheit sind wir der Meinung, dass Sie in Ihrem Programm darauf achten sollten, dass Vulnerabilities nicht einfach nur gezählt werden. Setzen Sie sich für eine Strategie ein, die sich auf Erkenntnisse über die Ausnutzbarkeit und potenzielle geschäftliche Auswirkungen konzentriert. Implementieren Sie Verfahren, die den Anteil der Bedrohungen, die wahrscheinlich für Angriffe genutzt werden, streng priorisieren, und fördern Sie eine Kultur, die überschaubare Restrisiken versteht und bewusst akzeptiert. Setzen Sie Ihre Ressourcen ein, um die Bedrohungen zu mindern, die Ihr Unternehmen tatsächlich gefährden.

Wenn Sie tiefer in dieses Thema einsteigen möchten: Ich habe auf der SOSS/Fusion-Konferenz von OpenSSF letztes Jahr einen Vortrag zu diesem Thema mit Daten von 2023 gehalten, ebenso dieses Jahr auf der VulnCon 2025 mit aktualisierten Daten von  2024.