Sicherheitslücken in Open Source-Komponenten | Report

Security-Software soll Anwender und Unternehmen vor Hacker-Angriffen schützen. Umso überraschender ist es, dass die Schutzprogramme oft selbst ein Sicherheitsrisiko darstellen. Ein Grund dafür: Die Anwendungen nutzen häufig Open Source-Komponenten, in denen sich Vulnerabilities verstecken.

Das Sicherheitsrisiko von Security-Software ist bekannt. Ein Report von Flexera Software identifizierte unter insgesamt 46 untersuchten Anwendungen, die es innerhalb von drei Monate mindestens einmal in die Top 20 der Produkte mit den meisten Schwachstellen schafften, 11 Sicherheitsanwendungen. Betroffen sind u. a. Produkte von AlienVault, IBM, Juniper, McAfee, Palo Alto und Splunk. Viele der Schwachstellen fanden sich dabei in den Open Source-Komponenten der Programme.

Einsatz von Open Source Software

Heutzutage ist es für ein Software-Entwicklungsteam undenkbar, bei der Programmierung neuer Produkte nicht auf Open Source-Module oder Komponenten von Dritten zurückzugreifen. Tatsächlich besteht eine Anwendung im Durchschnitt aus mindestens 50% Open Source Software (OSS). Open Source erlaubt Entwicklern den Funktionsumfang eines Softwareproduktes ohne großen Aufwand zu erweitern. Hersteller können dadurch Produkte mit mehr Funktionalität anbieten. Allerdings ist damit die Sicherheit des Produktes im starken Maße abhängig von der langen und komplexen Software-Supply Chain und der darin genutzten Komponenten.

Obwohl ihre Technologie in hohem Maße von OSS abhängt, sind viele Unternehmen nachlässig wenn es um die Nachverfolgung und das Monitoring der eingesetzten Komponenten geht. Eine Stückliste (BOM) der eingesetzten OSS-Komponenten zu erstellen ist für die meisten eine Herausforderung. Auch bei Konzernübernahmen – wenn Transparenz entscheidend ist – kann ein Großteil der Unternehmen häufig kein einziges Projekt nennen, das auf OSS angewiesen ist. Liegt eine Liste mit Open Source-Komponenten vor, führt diese in der Regel nur einen Bruchteil auf – im Schnitt 20mal weniger Open Source-Komponenten als tatsächlich im Unternehmen genutzt. 

So gut wie jede Open Source-Komponente unterliegt einer Lizenzvereinbarung, an die sich Unternehmen bei der Verwendung der Komponenten in ihren Produkten halten müssen. Dazu gehören in der Regel die Weitergabe des genauen Wortlautes der Lizenz, urheberrechtliche Erklärungen und in manchen Fällen der Quellcode der Komponente oder der komplette Quellcode. Häufig verstoßen viele Unternehmen gegen OSS-Lizenzen, indem sie die geforderten Informationen nicht zur Verfügung stellen.

Mangelndes Bewusstsein

Entwickler stehen beim Erstellen von Softwareprodukten unter enormem Druck und müssen im Hinblick auf ihre Veröffentlichung einen engen Terminplan einhalten. Eine Rückverfolgung und Verwaltung der verwendeten Open Source-Komponenten gehört in vielen Unternehmen nicht zum üblichen Procedere. Die OSS-Landschaft hat sich in den letzten Jahren stark verändert. Der Umfang an frei verfügbarem Code ist so hoch wie nie. Gleichzeitig herrscht in vielen Unternehmen ein fehlendes Bewusstsein für Compliance und Sicherheit in Verbindung mit OSS. Relevanz gewinnt das Thema oft erst im Ernstfall, wenn Schwachstellen der Software veröffentlicht oder Anwendungen gehackt werden, eine Übernahme bevorsteht oder eine Compliance-Anfrage von Kundenseite eintrifft. 

Sicherheitsrisiken

Wenn Unternehmen die verwendete OSS nicht gut verwalten sehen sie sich hauptsächlich mit zwei Problemen konfrontiert: Die Lizenzen entsprechen nicht mehr den Compliance-Vorgaben und/oder die genutzte Open Source-Komponenten enthalten Schwachstellen, die nicht gekennzeichnet wurden.

Wissen Unternehmen nicht, welche Open Source Software genutzt wird, ist eine Einhaltung der Compliance-Richtlinien unmöglich. Zudem lassen sich aktuelle und künftige Schwachstellen innerhalb der Open Source-Komponenten nicht effektiv beheben. Viele Sicherheitslücken werden erst entdeckt, wenn die Software bereits im Umlauf ist. Häufig bleiben sie unentdeckt bis sie von Hackern ausgenutzt werden. Deswegen ist eine Nachverfolgung besonders dann wichtig, wenn ein Unternehmen Produkte im Sicherheits- oder Netzwerkbereich anbietet.

Open Source Software verwalten

Der erste Schritt zu einem effektiven Open Source Management beginnt mit der Schulung von Mitarbeitern. Die Grundlagen von Compliance und OSS-Management sollten im gesamten Unternehmen bekannt sein – nicht nur im Entwicklerteam. Die Führungsebene muss sich der Compliance-Vorgaben bewusst sein und dafür sorgen, dass herausgegebene Produkte regelmäßig aktualisiert werden, um mögliche Sicherheitslücken in Open Source-Komponenten zu schließen. Werden diese Maßnahmen nicht vorausschauend eingeplant und im Budget berücksichtigt, werden sie nur selten umgesetzt. Vielen Unternehmen bilden ein firmeninternes Open Source Review Board (OSRB) mit Mitarbeitern aus technischen Fachbereichen, Juristen, IT-Spezialisten und Führungskräften. Das OSRB legt Richtlinien fest, adressiert aufkommende Compliance- oder Sicherheitsfragen und schult das restliche Personal im Hinblick auf Open Source. Das Team kann für den Einzelfall oder als feste Einheit gebildet werden, abhängig von der Größe des Unternehmens oder der Notwendigkeit. 

Die erlassenen Richtlinien werden dann von den Entwicklerteams umgesetzt. So wird zum einen die Einhaltung aller OSS-Lizenzvereinbarungen sichergestellt. Zum anderen kann ein Prozess festgelegt werden, um Sicherheitslücken in Komponenten aufzudecken und entsprechende Upgrades zur Verfügung zu stellen. Tools für Software Composition Analysis (SCA) unterstützen Unternehmen dabei, sämtliche eingesetzte OSS aufzuspüren und zu verwalten. Zudem ermöglichen sie automatisierte Benachrichtigung beim Aufdecken neuer Schwachstellen. 

Beginnt ein Unternehmen Richtlinien festzulegen, Mitarbeiter zu schulen und SCA-Lösungen einzuführen, ist es auf dem besten Weg zu einem effektiven OSS-Management, das sämtlichen Compliance-Vorgaben entspricht. Dazu gehört die Erstellung einer BOM für jedes Software-Release, die Einhaltung der Lizenzvereinbarungen und die Bereitstellung von Updates für bereits veröffentlichte Produkte, sobald Schwachstellen entdeckt werden. So erfüllen Unternehmen nicht nur die Erwartungen der Community, sondern verringern auch das Risiko von OSS-basierten Sicherheitslücken.

Autor: Jeff Luszcz, VP of Product Management, Flexera Software