Open-Source-Risiken begegnen

Gastbeitrag

Neue Untersuchung zeigt: Sichere Nutzung von Open Source bleibt eine Herausforderung

Wenn ich Ihnen sagen würde, dass die durchschnittliche Anzahl der Schwachstellen in kommerzieller Software im letzten Jahr um 93 % gestiegen ist, würden Sie meine Quelle anzweifeln. Doch genau das ist Befund der 6. Iteration des Open Source Security and Risk Analysis (OSSRA) Berichts, erstellt vom Synopsys Cybersecurity Research Center (CyRC). Eine der Ursachen ist sicherlich, dass auch die Anzahl der Open Source-Komponenten in Anwendungen gestiegen ist – innerhalb eines Jahres um fast 19 %. Anders ausgedrückt: Wenn die Nutzung von Open Source in einer Codebasis wächst, steigt die Zahl der Schwachstellen explosionsartig – aber warum?

Um das zu beantworten, muss man einen genaueren Blick auf die Daten selbst werfen. Die Daten im diesjährigen OSSRA-Bericht stammen aus 1.546 Audits kommerzieller Software, die 2020 im Rahmen einer technischen Due-Diligence-Prüfung während einer Fusion oder Übernahme durchgeführt wurden. Solche Prüfungen durchzuführen gehört zum Kerngeschäft des Black Duck® Audit Services-Teams. Das Synopsys Cybersecurity Research Center nutzt diese Informationen für den jährlich erscheinenden OSSRA-Bericht. Ziel ist es, Trends in der Open Source-Nutzung in kommerziellen Anwendungen zu ermitteln und Einblicke zu geben, die Entwicklungsteams helfen, das Software-Ökosystem besser zu verstehen, von dem sie ein Teil sind.

Software-Ökosystem besser verstehen

Bei den im letzten Jahr überprüften Codebasen enthielten 98 % Open Source-Komponenten, von denen satte 84 % mindestens eine Schwachstelle aufwiesen (mit einem Durchschnitt von 158 pro Codebasis). Dies ist ein Anstieg von 9 % gegenüber 2019 und die zweithöchste Wachstumsrate seit 2017. In ähnlicher Weise erhöhte sich 2020 der Prozentsatz der Codebasen mit hochriskanten Open Source-Schwachstellen auf 60 %, ein dramatischer Anstieg von 11 % gegenüber 2019. In diesem Zusammenhang spricht man von einer Schwachstelle mit hohem Risiko, wenn eine Schwachstelle bereits aktiv ausgenutzt wurde, es dokumentierte Proof-of-Concept-Exploits gibt oder sie sich eignet, um Remote-Code auszuführen. Und ein weiterer Befund gibt Anlass zur Besorgnis: Vier der „Top Ten“ Open Source-Schwachstellen der 2019 geprüften Codebasen, tauchen auch in der aktuellen Untersuchung wieder auf. Alle mit signifikanten prozentualen Zuwächsen.

Interessanterweise enthielten 91 % der überprüften Codebasen Open Source-Komponenten, bei denen sich in den letzten zwei Jahren keinerlei Entwicklungstätigkeit feststellen ließ. Das heißt, weder wurde der Code verbessert, noch wurden Sicherheits-Fixes veröffentlicht. Grundsätzlich leistet die Open Source Community zwar vorbildliche Arbeit bei der Behebung von Sicherheitsproblemen, aber eine beunruhigend große Zahl von Unternehmen spielt die Patches nicht ein. Bei älterem Code steigt die Wahrscheinlichkeit von Sicherheitsschwachstellen. Das ist aber nicht das einzige Problem.

Neben den offensichtlichen Folgen von nicht eingespielten Sicherheits-Patches reichen die Auswirkungen aber noch weiter. Wer veraltete Open Source-Komponenten nutzt, nimmt ein schwer in den Griff zu bekommendes technologisches Risiko billigend in Kauf. Nämlich unerwünschte Funktionalitäts- und Kompatibilitätsprobleme, die bei künftigen Aktualisierungen auftreten können. Im Gegensatz zu kommerzieller Software, wo gezielte Hotfixes die Norm sind, ist ein Sicherheitsupdate für ein Open Source-Projekt viel wahrscheinlicher ein einfaches Point Release. Mit anderen Worten: Wenn Sie beispielsweise Version 1.2.5 einsetzen und die Aktualisierung der Komponente liegt eine Weile zurück, erfordert der Fix einer riskanten Schwachstelle in Version 1.2.26 nicht nur, den Patch einzuspielen. Vielmehr müssen Sie sich auch um alle funktionalen Änderungen kümmern, die zwischen den Versions-Nummern liegen. Eine solche Schwachstelle führt potenziell an anderer Stelle zu Problemen und erfordert zusätzliche Tests. Die erst stellen sicher, dass alle Anwendungen mit dem Update korrekt funktionieren.

In Bezug auf die Open Source-Lizenzierung enthalten über 90 % der geprüften Codebasen mindestens eine Open Source-Komponente mit Lizenzkonflikten, angepassten Lizenzen oder sie haben erst gar keine Lizenz. Tatsächlich weisen 65 % der 2020 geprüften Codebasen Open Source Software-Lizenzkonflikte auf, üblicherweise im Zusammenhang mit der GNU General Public License. 26 % der Codebasen verwenden Open Source-Komponenten ohne Lizenz oder mit einer angepassten Lizenz. Alle diese Probleme betreffen mögliche Verletzungen der Rechte an geistigem Eigentum oder andere juristische Belange und müssen häufig dahingehend beurteilt werden. Das gilt ganz besonders im Zusammenhang mit Fusionen oder Übernahmen.

Was also sollten Unternehmen tun, um die Open Source-Nutzung sicherer zu machen?

Bestandsaufnahme/Inventarisierung: Können Sie mit Sicherheit sagen, dass Sie alle Open Source-Komponenten kennen, die irgendwo im Unternehmen zum Einsatz kommen? Wissen Sie, woher sie stammen und wie die Projektverantwortlichen Updates kommunizieren? Haben Sie die gleiche Transparenz über Open Source in kommerziellen Anwendungen oder sogar Firmware? Wenn Sie diese Fragen nicht beantworten können, dann hat Ihr Patch-Management einen blinden Fleck. Sie können nichts patchen, von dem Sie nicht wissen, dass Sie es haben.

Auf Updates achten: Im Gegensatz zu kommerzieller Software, bei der Fixes, Patches und Updates im Push-Modus an den Anwender übermittelt werden, kommuniziert Open Source über einen Pull-Support. Sie sind also selbst dafür verantwortlich, sich über die Updates der von Ihnen verwendeten Open Source Software auf dem Laufenden zu halten. Angesichts der weit verbreiteten Nutzung von Open Source ist das eine Aufgabe, die weit über Tabellenkalkulation, manuelle Nachverfolgung und gelegentliche Bestandsaufnahmen hinausgeht.

Sicherheitsscans fokussieren: Fokussieren Sie Ihre Scan-Aktivitäten auf der Grundlage der Open Source-Inventarisierung. Verwenden Sie CVSS-Scores (Common Vulnerability Scoring System) als Basis, um Maßnahmen zur Abhilfe und Schadensbegrenzung zuzuordnen. Achten Sie dabei besonders auf zeitliche Metriken. Exploits treten möglicherweise nicht an Tag 1 einer Schwachstelleoffenlegung auf, eher einige Tage später. Das erfassen die CVSS-Scores.

Fazit

Die Nutzung von Open Source wird weiter zunehmen. Sie ist ein Innovationsmotor. Was wir allerdings nicht akzeptieren sollten, ist, dass damit zwangsläufig auch eine immense Zunahme an nicht gepatchten Schwachstellen einhergeht. Die Open Source Community leistet ihren Beitrag, indem sie Schwachstellen so schnell wie möglich behebt. Unternehmen sollten ihren Beitrag leisten, indem sie diese Patches einspielen, sobald sie veröffentlicht werden. Nur so lässt sich die Zahl nicht gepatchter Schwachstellen in Software-Anwendungen senken.

Tim Mackey,
Principal Security Strategist, Synopsys Cybersecurity Research Center
https://www.synopsys.com/software-integrity/cybersecurity-research-center.html

Aufmacherbild / Quelle / Lizenz

Aufmacherbild / Quelle / Lizenz
Photo by Árpád Czapp on Unsplash