gustavofrazao - Fotolia

Sicherheitsrisiko Open-Source- und Drittanbieter-Komponenten

In vielen Anwendungen kommen ganz selbstverständlich Open-Source- und Drittanbieter-Bestandteile zum Einsatz. Und die können Schwachstellen aufweisen.

Fast die Hälfte des Codes, den Entwickler in ihre Software integrieren, besteht entweder aus Open-Source-Code oder kommerziellen, lizenzierten Komponenten von Drittanbietern. Eine proaktive Kontrolle und Pflege findet dabei nur selten statt. Oft ist den Entwicklern nur rund vier Prozent des Codes von Drittanbietern überhaupt bekannt.

So kommt es, dass über die Softwarekomponenten sich auch bekannte Sicherheitslücken einschleichen.

Ein typisches Entwicklerteam besitzt nur in den seltensten Fällen einen detaillierten und vollständigen Überblick über die Softwarekomponenten von Drittanbietern – obwohl das Führen einer Liste mit allen Open-Source-Komponenten grundsätzlich für die Compliance notwendig ist. In der Regel können Unternehmen sogar nur eine von 25 Open-Source-Komponenten benennen.

Mühevolle Nachverfolgung

Die mangelnde Nachverfolgung hat verschiedene Gründe: So wird das Einhalten von Open-Source-Lizenzbedingungen häufig als manueller und freiwilliger Prozess betrachtet. Relevant wird dieser erst oft nur im Rahmen von Veränderungen der Unternehmensstruktur. Zu diesem Zeitpunkt kann es schwierig werden, die Compliance einzuhalten oder bekannte Schwachstellen, die sich in der Codebasis verbergen, zu beseitigen.

Eine manuelle Überprüfung oder eine Nachverfolgung, die rein auf Workflows basiert, erfasst lediglich die größten Bestandteile der Softwarearchitektur oder beschränkt sich auf Komponenten, die von gut geschulten Teammitgliedern in die Software eingebunden wurden. Wird eine Vulnerability mit hohem Sicherheitsrisiko veröffentlicht, ist es nötig, den gesamten Softwarecode schnellstmöglich auf diese Schwachstelle hin untersuchen zu können – sowohl in bereits ausgelieferten als auch im Auslieferungszustand befindlichen Versionen.

Zwischen der Entwicklung und der Bereitstellung von Software sollte die Untersuchung auf Schwachstellen erfolgen.
Abbildung 1: Zwischen der Entwicklung und der Bereitstellung von Software sollte die Untersuchung auf Schwachstellen erfolgen.

Der Zeitaufwand, um sämtliche betroffenen Komponenten zu finden, ist enorm. Zumal jeder erneute Vorfall eine weitere Suche auslöst und das Entwickler- und Testteam von ihrer eigentlichen Arbeit abhält.

Automatisierte Scan-Vorgänge

Effizienter ist es, Prozesse zu implementieren, die automatisch alle Dateien und Ressourcen überprüfen, die in allen Produkten verwendet werden – egal ob diese in der Entwicklung stecken oder bereits beim Kunden zum Einsatz kommen. Nur wenn jede einzelne Datei sowie ihre Abhängigkeiten genauestens unter die Lupe genommen werden, wird deutlich, welche Komponenten von Drittanbietern zum Aufbau und zur Ausführung einer Anwendung tatsächlich nötig sind.

Komponenten von Drittanbietern können auf unterschiedliche Weise in Anwendungen gelangen:

  • Eine relativ neue Methode ist es, eine Komponente über einen Repository-Manager, wie zum Beispiel Maven oder Nuget, einzubinden. Diese Systeme lesen Konfigurationsdateien ein, in denen die Entwickler die zu verwendenden Komponenten von Drittanbietern angegeben haben. Anschließend durchsucht der Repository-Manager zum Zeitpunkt der Kompilierung das Internet nach den benötigten Komponenten sowie deren Abhängigkeiten und lädt diese herunter. Zu diesem Zeitpunkt kann es vorkommen, dass die eigentlich gesuchte Komponente eines Drittanbieters nicht im Quellcode-Management-System gespeichert ist, sondern erst in der finalen Version gefunden wird. Unter Umständen fehlt den Teams daher ein umfassender Überblick, ob eine Komponente oder eine enthaltene Teilkomponente vorliegen. Zu einer typischen Open-Source-Komponente gehören bis zu zehn Teilkomponenten sowie Abhängigkeiten, die dem Nutzer der Komponenten oft nicht bekannt sind.
  • Entwicklerteams legen für eine Komponente von Drittanbietern oft auch monolithische Verzeichnisbäume manuell an. Zwar können diese Verzeichnisbäume eindeutig benannt sein. Nach einer Einbindung in einen größeren Verzeichnisbaum weist jedoch nichts mehr speziell auf diese Verzeichnisbäume hin, da sich die Zeilenzahl der Anwendung erhöht. Sofern die Komponente nicht eindeutig lizenziert ist oder von einem Team stammt, das Wert auf die Einhaltung von Lizenzbestimmungen legt, ist die Komponente ohne Hinweis auf den Urheber des Quellcodes oder ohne Techniken zur eingehenden Durchsuchung unter Umständen nicht mehr auffindbar.
  • Zu einer weiteren großen Gruppe nicht überwachter Komponenten gehören vorkompilierte Binärdateien von Partnern oder anderen Teams. Diese Binärdateien (oftmals ausführbare Dateien oder verlinkungsfähige Bibliotheken) enthalten keine eindeutig erkennbaren Informationen über Lizenzierung oder Eigentümer, zum Beispiel Dateien mit dem Namen „readme.txt“ oder „license.txt“. Eine einzige Datei kann dutzende Open-Source-Zeilen oder kommerziellen Abhängigkeiten enthalten. Sobald derartige Dateien in einen Softwarecode eingebunden sind, werden sie in der Regel – und solange keine eindeutigen Probleme auftreten – nicht mehr aktualisiert. Hier finden sich häufig langbekannte Schwachstellen, unter anderem auch deshalb, weil die Binärdateien im Vergleich zu Quellcode relativ transparent sind. Tief in diese Dateien eingebettet finden sich beispielsweise weitverbreitete Komponenten wie die Verschlüsselungsbibliothek OpenSSL oder Multimedia-Verarbeitungsbibliotheken wie libpng. Aufgrund ihrer langen Geschichte und Nutzung ist es also nicht ungewöhnlich, dort alte Versionen mit bekannten Schwachstellen zu entdecken.
  • Dateien und Routinen, die aus einer größeren Bibliothek kopiert werden, gehören ebenfalls zu Orten, an denen nicht überwachter Code zu finden ist. Das kommt vor allem dann vor, wenn nicht die gesamte Bibliothek benötigt wird, sondern nur eine bestimmte Funktionalität hinzugefügt werden soll. Dieser Code erweckt den Anschein, als handele es sich um eine Eigenentwicklung. Er wird oftmals ohne Original-Lizenzhinweise oder Urheberrechtshinweise kopiert. Enthaltener verwundbarer Code wird beim Patchen von Vulnerabilities oft übersehen, da er augenscheinlich nichts mit der ursprünglichen Komponente zu tun hat. Eine Nachverfolgung auf der Softwarepaketebene sowie einfache Tabellen reichen nicht aus, um derartige Dateien erkennen und kontrollieren zu können.

Richtlinien aufstellen

Der erste Schritt, um Richtlinien zur Erkennung, Überwachung und Beseitigung von Open-Source-Risiken aufzustellen, ist zu wissen, wo Komponenten von Drittanbietern enthalten sein können. Klare Regeln sind entscheidend. Allerdings sollten sie auch auf die Entscheidungen und Bedürfnisse der Entwickler sowie auf die zu entwickelnden Produkte abgestimmt sein.

Keine Richtlinie ist so umfassend, dass sie nie mehr geändert werden muss. Die erste Überprüfung eines Produkts kann oft zu einem Aha-Erlebnis führen und drastische Änderungen von bestehenden Vorgehensweisen bewirken. Neue Richtlinien sind beispielsweise nötig, um problematische Abhängigkeiten Dritter in kommerziellen Komponenten zu handhaben und zu beseitigen. Auch für Daten, die an unbekannte Webdienste weitergegeben werden, sowie für bekannte, jedoch nicht gepatchte Schwachstellen sind eindeutige Regeln festzusetzen.

„Um Richtlinien zur Erkennung, Überwachung und Beseitigung von Open-Source-Risiken aufzustellen, muss man wissen, wo Komponenten von Drittanbietern enthalten sein können.“

Jeff Luszcz, Flexera Software

Eine Strategie für das Scannen und das Management von Komponenten ist entscheidend, um das Risiko von Software-Sicherheitslücken für Unternehmen zu reduzieren. Durch dynamische und gleichzeitig fest etablierte Richtlinien sowie entsprechender Schulung und Aufklärung der Entwickler lassen sich Komponenten von Drittanbietern sicherer nutzen. Sind solche Prozesse erst einmal etabliert, können immer tiefere Analysen durchgeführt werden, um Abhängigkeiten aufzudecken, die ein Sicherheitsrisiko für die Produkte darstellen.

Über den Autor:
Jeff Luszcz ist Vice President of Product Management bei Flexera Software.

Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Veraltete Open-Source-Komponenten gefährden kommerzielle Anwendungen

Angriffspunkt Open-Source-Software

Einsatzszenarien für das Schwachstellen-Management

Die am häufigsten ausgenutzten Software-Schwachstellen

Artikel wurde zuletzt im Mai 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Sicherheit von Webanwendungen

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close