Risiko Open Source

Entwickler übersehen häufig die mit Open-Source verbundenen Sicherheits- und Lizenzrisiken.

Das Black-Duck-Audit-Services-Team von Synopsys führt jedes Jahr Open-Source-Audits für seine Kunden durch und prüft dabei tausende Codebasen. Diese Prüfungen werden in erster Linie von M&A-Prozessen bestimmt und sind die primäre Quelle anonymisierter Daten für die jährliche Open-Source-Sicherheits- und Risikoanalyse (OSSRA). Die diesjährige OSSRA 2019 Studie untersucht die Ergebnisse von über 1.200 kommerziellen Codebasen und Bibliotheken. Sie zeigt Trends und Muster in der Nutzung von Open-Source sowie die Verbreitung von unsicheren Open-Source-Komponenten wie auch von Lizenzkonflikten auf.

 

Die Audits ergaben, dass mehr als 96% der im Jahr 2018 analysierten Codebasen Open-Source-Komponenten enthielten. Nach 57% im Jahr 2017 machte Open-Source dieses Jahr bereits 60% des geprüften Codes aus. Diese Zahlen spiegeln wider, dass die geprüften Codebasen mehrheitlich von Unternehmen stammen, deren Hauptgeschäft in der Entwicklung von Software besteht. Der Unternehmenswert solcher Firmen liegt häufig in ihrem proprietären Code, deshalb ist das Verhältnis zwischen proprietärem Code und Drittanbietercode hier tendenziell geringer als in anderen Branchen.

Prozentsatz der auditierten Codebasen, die Open Source enthielten, nach Branchen. (Tabelle 1)

Im Gegensatz dazu stellten Analysehäuser wie Forrester und Gartner fest, dass über 90% der IT-Firmen Open-Source-Software auch in geschäftskritischen Workloads einsetzen und dass Open-Source bis zu 90% des Codes ausmachen kann. Laut der aktuellen RedHat State-of-Enterprise-Open-Source–Studie[1] waren über 69% der befragten Unternehmen der Ansicht, dass die Nutzung von Open-Source enorm wichtig sei. Welche Zahlen man auch betrachtet, es wird deutlich, dass Open-Source-Komponenten und -Bibliotheken den Grundstein für nahezu jede Anwendung in jeder Branche bilden. Die meisten Unternehmen verfügen über eine Vielzahl unterschiedlicher Softwareprodukte, von mobilen Apps über cloudbasierte Systeme bis hin zu Altsystemen, die On-Premises ausgeführt werden. Diese Software ist in der Regel eine Mischung aus kommerziellen Standardpaketen, Open-Source-Software und selbst entwickelten Codebasen.

 

Durchschnittlicher Prozentanteil an Open Source in jeder auditierten Codebasis nach Branche. (Tabelle 2)

Nur wenige Unternehmen prüfen die Open-Source-Komponenten ausreichend, die sie in ihrem Code verwenden, und haben entsprechende Richtlinien, Prozesse sowie Tools implementiert. Diese Maßnahmen sind jedoch erforderlich, da Entwickler immer mehr Open-Source einsetzen. Infolgedessen können die Vorteile von Open-Source auch eine Reihe von Risiken mit sich bringen.

 

Die Top-10 der genutzten Open-Source-Komponenten. (Tabelle 3)

 

Ungepatchte Software birgt ein Risiko, nicht aber die Verwendung von Open-Source

Wie der Report von Red Hat feststellt, wird der Faktor Sicherheit als größtes Hindernis für die Verwendung von Open-Source aufgeführt. Interessanterweise wird aber im gleichen Bericht Sicherheit als einer der wichtigsten Vorteile genannt, die IT-Entscheidungsträger bei der Verwendung von Open-Source sehen. Dieser scheinbare Widerspruch spiegelt die Sorge wider, dass Open-Source-Code, der nicht korrekt verwaltet wurde, Sicherheitslücken verursachen kann, sowohl in Open-Source als auch in proprietären Lösungen. Im Gegensatz dazu verringert eine ordnungsgemäße Verwaltung von Open-Source potenzielle Risiken erheblich, einschließlich der Verwendung vertrauenswürdiger Quellen und automatisierter Tools zum Aufdecken und Beheben von Sicherheitsproblemen. Jede Software, ob proprietär oder Open Source, weist Schwachstellen auf, die Unternehmen identifizieren und patchen müssen. Die Open-Source-Community leistet beispielhafte Arbeit bei der Bereitstellung von Patches – oft werden diese schneller veröffentlicht als ihre proprietären Pendants. Eine alarmierende Anzahl von Unternehmen nutzt diese jedoch nicht rechtzeitig oder gar überhaupt nicht.

Die Gründe für das Ausbleiben von Patches sind vielfältig: Einige Unternehmen sind von der schieren Anzahl an verfügbaren Patches überfordert und können diese somit nicht priorisieren. Andere Unternehmen wiederum verfügen nicht über entsprechend geschulte IT-Mitarbeiter und müssen das Risiko gegen die finanziellen Kosten abwägen. Ungepatchte Schwachstellen bleiben eine der größten Cyber-Bedrohungen für Unternehmen. Die OSSRA 2019 Studie zeigt, dass 60% der im Jahr 2018 geprüften Codebasen mindestens eine Open-Source-Schwachstelle enthielten. Synopsys hat seine Black-Duck-KnowledgeBase im letzten Jahr um 7.393 Open-Source-Schwachstellen erweitert. In den letzten zwei Jahrzehnten wurden weit über 50.000 Open-Source-Schwachstellen gemeldet. Diese Entwicklung zeigt, dass es essentiell ist, seine Software zu patchen.

 

Die Top-10-Sicherheitslücken mit hohem Risiko. (Tabelle 4)

 

Welches Risiko besteht?

Bestimmte Merkmale von Open-Source machen Schwachstellen in oft verwendeten Komponenten für Angreifer attraktiv. Im Gegensatz zu kommerzieller Software, deren Anbieter automatisch Patches und Updates an die Kunden verteilen können, verfügt Open-Source über ein Pull-Support-Modell. Nutzer sind demnach selbst dafür verantwortlich Up-to-Date zu bleiben.

Die Allgegenwart von Open-Source bietet Angreifern viele mögliche Angriffsziele, da Schwachstellen durch Quellen wie die National-Vulnerability-Database (NVD), Mailing-Listen, GitHub und Projektseiten offengelegt werden. Wie bereits erwähnt, führen viele Unternehmen keine genauen, umfassenden und aktuellen Bestandslisten der in ihren Anwendungen verwendeten Open-Source-Komponenten. In einem Bericht des U.S. Senate-Permanent-Subcommittee-on-Investigations[2] wurde beispielsweise festgestellt, dass das Fehlen eines vollständigen Softwareinventars ein Faktor für den massiven Datenverstoß im Jahr 2017 bei der US-Firma Equifax war.

 

Korrektes Management von Open-Source-Software ist nicht nur eine Frage der Sicherheit

So gut wie alle Open-Source-Komponenten unterliegen einer von etwa 2.500 bekannten Open-Source-Lizenzen, von denen viele mit Verpflichtungen und unterschiedlichen Einschränkungen verbunden sind. Die Missachtung von Open-Source-Lizenzen kann für Unternehmen ein erhebliches Risiko an Rechtsstreitigkeiten und eine Gefährdung des geistigen Eigentums bedeuten, einschließlich der Eigentumsrechte an firmeneigenem proprietärem Code, der einzelne Open-Source-Komponenten enthält. 68% der in der OSSRA-2019-Studie geprüften Codebasen enthielten Komponenten mit Lizenzkonflikten.

 

Prozentsatz der auditierten Codebasen, die Lizenzkonflikte enthielten, nach Branchen. (Tabelle 5)

 

Nicht verwaltete Open-Source-Komponenten sind riskant

Open-Source bietet Unternehmen viele Vorteile – jedoch nur, wenn die Komponenten ordnungsgemäß verwaltet werden. Zur Abwehr von Open-Source-Sicherheits- und Compliance-Risiken sollten Unternehmen folgende Punkte befolgen:

 

  1. Risikorichtlinien und Prozesse etablieren

Nur eine Handvoll Open-Source-Schwachstellen – wie diejenigen, die Apache-Struts oder OpenSSL betreffen – werden häufig ausgenutzt. Unternehmen sollten sich deshalb bei ihrem Schwachstellenmanagement auf CVSS-Werte (Common-Vulnerability-Scoring-System) und die Verfügbarkeit von Exploits konzentrieren, und das über die gesamte Nutzungsdauer der Open-Source-Komponente hinweg. Es sollte ein automatisierter Prozess eingerichtet werden, der die Open-Source-Komponenten in einer Codebasis und ihre bekannten Sicherheitslücken sowie operationelle Risiken nachverfolgt und Probleme nach ihrem Schweregrad priorisiert.

 

  1. Eine vollständige Bestandsaufnahme durchführen

Es ist wichtig, eine vollständige, genaue und zeitnahe Bestandsaufnahme des verwendeten Open-Source durchzuführen. Diese sollte sowohl den Quellcode, als auch Informationen darüber umfassen, wie Open-Source in bereitgestellter Software verwendet wird.

  1. Open Source bekannten Schwachstellen zuordnen

Öffentliche Quellen wie die National-Vulnerability-Database stellen eine gute erste Anlaufstelle für Informationen zu gemeldeten Schwachstellen dar. Man sollte sich jedoch nicht ausschließlich auf die NVD verlassen, sondern auch sekundäre Quellen berücksichtigen, die im Idealfall eine frühere Benachrichtigung über Sicherheitsrisiken sowie zusätzliche technische Details, Upgrades und Patches bereitstellen können.

  1. Schritthalten mit neuen Sicherheitsbedrohungen

Unternehmen müssen ein kontinuierliches Monitoring ihrer Produkte, Systeme und Applikationen sicherstellen – und zwar so lange, wie diese verwendet werden.

  1. Lizenzrisiken angehen

Die Missachtung von Open-Source-Lizenzen kann Unternehmen Rechtsstreitigkeiten einbringen und ihr geistiges Eigentum gefährden. Deshalb sollten die Entwickler über die Open-Source-Lizenzen informiert sein und entsprechend geschult werden. Der Syndikusrechtsanwalt sollte in diesen Schulungsprozess eingebunden werden und auch die Einhaltung lizenzrechtlicher Verpflichtungen überwachen.

  1. Open-Source-Audit zum Teil der Due-Diligence-Prüfung machen

Im M&A-Geschäft sollte man wissen, ob Open-Source im Spiel ist. Dies ist insbesondere dann regelmäßig der Fall, wenn Software-Assets einen wesentlichen Teil der Bewertung ausmachen. Softwarerisiken können sich im schlechtesten Fall zum Deal-Breaker entwickeln. Man sollte daher nicht zögern, Fragen hinsichtlich der Verwendung und Verwaltung von Open-Source zu stellen. Auch ein Code-Audit durch externe Experten sollte in Erwägung gezogen werden.

 

Fred Bals ist „Coporate Storyteller“ für Synopsys. Sein erklärtes Ziel ist es Sicherheits-, Risiko-, Entwickler-, M&A- und Rechtsteams den notwendigen Einblick zu verschaffen, um Open-Source-Sicherheits- sowie Lizenzrisikenbesser verstehen zu können,. Fred Bals ist Forscher am Cybersecurity Research Center (CyRC) von Synopsys und Autor der Open-Source-Sicherheits- und Risikoanalyse 2019 (OSSRA). Vor seiner Tätigkeit für Synopsys arbeitete er als Firscher für Bob Dylan und Google.

 

[1] https://www.redhat.com/it/enterprise-open-source-report/2019

[2] https://www.hsgac.senate.gov/imo/media/doc/FINAL%20Equifax%20Report.pdf

Victoria Krautter


Leave a Reply