Open Source-Risiken im Auge behalten

Es ist kaum anzunehmen, dass Oberstufenschüler ihrem Berufsberater „Chief Inventory Officer“ als ihren persönlichen Traumberuf vorschlagen – falls es diesen Titel überhaupt gibt. Er klingt auf jeden Fall kaum nach Glamour, Prestige oder aufregender Tätigkeit – vielmehr nach eintöniger Arbeit wie in noch nicht komplett vergangenen Tagen: mit dem Klemmbrett im Warenlager.

Dennoch ist Inventarisierung in der Realität mindestens so wichtig wie die scheinbar aufregenderen Alternativen. Vielleicht sogar noch wichtiger, wenn es um Softwarekomponenten geht, die für die Entwicklung und den Betrieb von Anwendungen, Netzwerken und Systemen verwendet werden. Insbesondere, wenn es sich dabei um Komponenten von Open-Source-Software handelt. Open Source macht heutzutage den Großteil all dessen aus, was mittels Software produziert oder betrieben wird. Behält man diese Bausteine nicht konsequent im Auge, haben die damit verbundenen Risiken potenziell schwerwiegende Folgen. 

Software Composition Analytics 

Zum Glück muss dazu heute niemand mehr Zehntausende von Softwarekomponenten manuell durchkämmen. Die Software Composition Analysis (SCA) ist ein Werkzeug, das diese Aufgabe automatisiert und dabei hilft, Software vollständig zu inventarisieren und entsprechende Stücklisten (Bill of Materials, kurz BOM) zu führen. Sinn und Zweck des Ganzen ist es, die Vorteile von Open Source zu nutzen, aber gleichzeitig die damit verbundenen Risiken zu senken. Open Source ist per se nicht mehr oder weniger risikoreich als proprietäre oder kommerzielle Software. In vielerlei Hinsicht ist sie sogar besser, und sie wird aus guten Gründen immer beliebter. Sie steht kostenlos zur Verfügung, und sie ist ein anpassungsfähiger Baustein für die Bedürfnisse von Anwendungsentwicklern. Und Open Source ist einer der größten Innovationsmotoren schlechthin.

Daher ist es wenig überraschend, dass der jüngst veröffentlichte Open Source Security and Risk Analysis (OSSRA) Bericht diese Einschätzung bestätigt. Bei der Überprüfung von über 1.250 Codebasen in 17 verschiedenen Branchen war Open Source das dominierende Element. Nicht nur, dass praktisch 100 Prozent der Codebasen Open Source-Komponenten enthalten, auch durchschnittlich 70 Prozent des Codes war Open Source. Das ist fast eine Verdopplung der 36 Prozent aus dem ersten OSSRA-Bericht. Ein weiterer Nachweis für diesen Anstieg: 2019 waren im Durchschnitt 445 Open-Source-Komponenten pro Codebasis vorhanden, ein Anstieg von fast 50 Prozent gegenüber 298 im Vorjahr.

Open Source in vielen Branchen unverzichtbar

Eine Vielzahl von Branchen ist auf Open Source angewiesen, von Unternehmenssoftware bis hin zu Virtual Reality, die Unterhaltungs- und Medienbranche, aber auch die Internet- und Software-Infrastruktur, Einzelhandel und E-Commerce und das Internet der Dinge (IoT) basieren auf Open Source ebenso wie Finanzdienstleistungen, Big Data, Machine Learning, der Energiesektor und nicht zuletzt Cybersicherheit und Marketing-Technologien. Im Umkehrschluss gehen die Chancen gegen Null, in einem durchschnittlichen Unternehmen keinerlei Open Source-Software zu finden. Eher im Gegenteil. Wahrscheinlich kommen in einem Unternehmen deutlich mehr Open-Source-Komponenten zum Einsatz als den Verantwortlichen bewusst ist. Vor allem mehr als man manuell nachhalten kann. Doch gerade hier ist es eminent wichtig den Überblick zu behalten. Denn die Tatsache, dass Open Source kostenlos ist, bedeutet keinesfalls, dass ihre Verwendung keine Risiken birgt oder nicht mit rechtlichen Verpflichtungen verbunden ist.

Im Wesentlichen gibt es zwei Risiken. Das eine betrifft die Sicherheit als solche, das andere die mit Open Source verbundenen Lizenzverpflichtungen. Beide lassen sich mithilfe einer Bill of Materials (BOM) erfassen und reduzieren. Eine BOM verzeichnet alle verwendeten Komponenten, inklusive der exakten Version und Bezugsquelle für jedes verwendete oder in Entwicklung befindliche Projekt. In Sachen Sicherheit ist Open Source nicht mehr oder weniger sicher als proprietäre (also nicht offener) Code. Es gibt zwangsläufig Schwachstellen, die gepatcht werden müssen. Wenn Apps oder Netzwerke aufgrund von Open Source-Schwachstellen, von denen ein Unternehmen nichts weiß, gehackt werden, sind die Auswirkungen weitreichend: gestohlenes geistiges Eigentum (Intellectual Property, IP) oder personenbezogene Daten (PII, Personally Identifiable Information), Ransomware-Angriffe, Rufschädigung, haftungsrechtliche Folgen und nicht zuletzt juristische Konsequenzen samt Strafzahlungen.

Open-Source-Software zu patchen ist nicht schwierig, erfordert aber ein gewisses Maß an Sorgfalt. Es ist meist nicht ganz so simpel wie die automatischen Updates, mittels derer bei kommerzieller Software die meisten Anbieter Sicherheitsupdates automatisch an die Benutzer “pushen”. Zwar werden Open Source-Patches ebenfalls zur Verfügung gestellt, aber die Benutzer sind selbst dafür verantwortlich, diese im Auge zu behalten und gegebenenfalls auf dem Quell-Repository herunterzuladen und einzupflegen. Wer das nicht tut, wird schlimmstenfalls zum nächsten Equifax. Das Unternehmen entdeckte am 29. Juli 2017 eine Datenschutzverletzung, bei der Sozialversicherungsnummern und andere personenbezogene Daten von mehr als 147 Millionen Kunden offengelegt wurden. Der Grund: Equifax hatte versäumt einen Patch für Apache Struts, ein beliebtes Open-Source-Framework für Web-Anwendungen, einzuspielen. Einen Patch, der bereits seit Monaten verfügbar war. 

Zumindest dieses spezifische Problem scheint behoben zu sein. Der diesjährige OSSRA-Bericht bestätigt, dass keine der 2019 geprüften Codebasen eine ungepatchte Version von Apache Struts enthält. Aber es existieren weitere Risiken: 82 Prozent der Open-Source-Komponenten in den geprüften Codebasen sind veraltet und 75 Prozent enthalten mindestens eine bekannte (also bereits veröffentlichte) Schwachstelle. Das Durchschnittsalter der gefundenen Schwachstellen betrug etwas weniger als 4,5 Jahre. Der Prozentsatz der Schwachstellen, die sogar älter als 10 Jahre waren, beläuft sich immerhin noch auf 19 Prozent.

Das könnte Sie auch interessieren:

Bericht zur Open-Source-Sicherheits- und Risikoanalyse

Synopsys hat den Bericht zur Open-Source-Sicherheits- und Risikoanalyse (OSSRA) 2020 veröffentlicht. Er vermittelt Sicherheits-, Risiko-, Rechts- und Entwicklungs-Teams Einsichten und Empfehlungen, mögliche Risiken hinsichtlich Open-Source-Sicherheit und -Lizenzen besser zu verstehen. 

Deutsch, 39 Seiten, PDF 2,1 MB, kostenlos

Fazit

Inventarisierung ist entscheidend, wenn man Risiken tatsächlich senken will. Software-Experten predigen es seit Jahren: man kann nichts patchen, von dem man nicht weiß, dass es existiert. Das zweite Risiko betrifft die rechtliche Seite. Open Source Code ist zwar kostenlos, bindet den Nutzer aber an Lizensierungsbedingungen, die zum Risiko werden, sollte man sie nicht beachten. Und es gibt viele unterschiedliche Arten solcher Lizenzbestimmungen. Der OSSRA-Bericht hat herausgefunden, dass die 20 beliebtesten Open Source-Komponenten etwa 98 Prozent des verwendeten Open Source-Codes abdecken. Die Black Duck Knowlege Base enthält über 2.500 Open-Source-Lizenzen. 

Compliance-Anforderungen einzuhalten, ist nicht unbedingt schwierig. Aber selbst ausgesprochen benutzerfreundliche Open Source-Lizenzen sind mit Verpflichtungen verbunden und sehen mindestens eine korrekte Wiedergabe der Urheberrechte vor. Auch potentielle Lizenzkonflikte können zum Problem werden. Zum Beispiel, wenn man die Software in einer Art und Weise verwendet, die nicht mit den Lizenzbestimmungen in Einklang zu bringen ist. Im Extremfall verliert ein Unternehmen das Recht auf die Nutzung der Software oder die Firma findet sich in einem Rechtsstreit wieder. 

Selbst wenn Open Source-Komponenten keine erkennbaren Lizenzbestimmungen enthalten, ist man nicht zwangsläufig juristisch auf der sicheren Seite. Keine erkennbaren Lizenzbestimmungen bedeutet einfach, dass ein Unternehmen den betreffenden Code nicht verwenden, verändern oder weitergeben darf, da ihm kreative Arbeit zugrunde liegt, die ihrerseits standardmäßig dem ausschließlichen Urheberrecht unterliegt. Eine Lizenz ist im Kern nichts anderes als eine Nutzungsberechtigung. Inventarisierung ist also an dieser Stelle wichtig. Ohne umfassende BOM ist ein Unternehmen blind gegenüber einer Reihe von zum Teil schwerwiegenden Risiken. SCA-Werkzeuge sollten im Rahmen der Softwareentwicklung obligatorisch sein. Sie helfen nicht nur dabei, Open-Source-Komponenten in einer Codebasis zu finden, sondern erkennen auch die verwendete Version und bekannte Schwachstellen dieser Komponenten. Zusätzlich werden die Auflagen aufgeführt, die man gemäß der jeweiligen Lizenzbestimmungen erfüllen muss. Dies ist während des gesamten Software-Entwicklungszyklus (Software Development Lifecycle, SDLC) gewährleistet. 

Weder Experten noch Tools machen eine Software unverwundbar. Aber ein SCA-Werkzeug kann dazu beitragen, diese Risiken zu kontrollieren, damit Unternehmen sich auf ihre eigentliche Kerntätigkeit fokussieren können.