Open Source Software (OSS)

Open Source verwenden - eine Erleichterung im Entwickleralltag, die Risiken mitbringt.

Software zu entwickeln bedeutet, sich einer komplizierten Herausforderung zu stellen und vielen Anforderungen gerecht werden zu müssen. Glücklicherweise sind Teilschritte, die dabei bewältigt werden müssen, üblicherweise nicht einzigartig. Stattdessen gibt es für viele von ihnen bereits Lösungen, die unter Umständen verwendet werden können. Diese Lösungen finden sich in Form von Libraries, die oft anzutreffende Concerns angehen. Sie zu verwenden kann die bessere Alternative zur Eigenentwicklung sein. Dabei hat man oft die Wahl, im Entwicklungsprozess auf proprietäre Software eines anderen Unternehmens zurückzugreifen - also Lösungen einzukaufen - oder auch Open Source Lösungen zum Einsatz zu bringen. Dabei hat sich freie Software schon lange von dem Ruf befreit, zwar kostenlos aber dafür technisch nur zweite Wahl zu sein.

STATTDESSEN IST DIE VERWENDUNG VON OPEN SOURCE BIBLIOTHEKEN IN VIELEN BEREICHEN DER DE-FACTO STANDARD

Ob es sinnvoll ist, eine bestehende Library zu verwenden, hängt aber vom Einzelfall ab. Es muss im Prinzip eine make-or-buy Entscheidung getroffen werden, eben auch wenn es um Open Source geht. Dabei ist der Impuls, ein paar Zeilen Code durch Verwendung einer Bibliothek zu ersetzen, aus Entwicklersicht vollkommen nachvollziehbar. Ob es allerdings ratsam ist, für eine kleine Einsparung an Arbeit eine Abhängigkeit von einer weiteren, vielleicht umfangreichen OSS Library einzuführen muss durchdacht werden.

DENN AUCH OPEN SOURCE SOFTWARE ARBEITET AUF EINE SPEZIFISCHE ART UND WEISE. WIE AUCH BEI SELBST ENTWICKELTER SOFTWARE MÜSSEN DABEI DIE KONSEQUENZEN DER VERWENDETEN LÖSUNG BEACHTET WERDEN

Zum Beispiel sollte man sich Gedanken um den Erfüllungsgrad von nicht funktionalen Anforderungen – wie z.B. Sicherheit, Stabilität und Performance – machen. Es müssen aber auch die Pflege der Bibliothek und die rechtlichen Implikationen ihrer Verwendung beachtet werden – also der Umgang mit Maintenance und Compliance.

Ein ungewünschter Nebeneffekt einer Softwarelösung kann zum Beispiel durch eine unsaubere Implementierung von Sicherheitsfeatures auftreten. Dadurch ergibt sich leicht eine Sicherheitslücke, die desaströse Folgen haben kann. Das kann bei selbst entwickelter Software passieren, aber auch Open Source Bibliotheken können Vulnerabilities mitbringen. Ein prominentes Beispiel hierfür ist die 2014 in OpenSSL entdeckte Sicherheitslücke CVE-2014-0160, besser bekannt unter dem Namen Heartbleed. Sie machte Software, die auf OpenSSL baute, angreifbar. Der wenige Tage nach Veröffentlichung der Sicherheitslücke bereitgestellte Patch für OpenSSL verhinderte nicht, dass auch lange Zeit später noch riesige Datenverluste an kritischen Stellen auf das Konto von Heartbleed gingen. Sogar 2019 war der Patch noch nicht auf allen betroffenen Geräten eingebunden.

Die langsame Reaktion lag unter anderem daran, dass nicht jedem Unternehmen bewusst war, ob das eigene System betroffen sein könnte. Es gab bei einigen Softwareherstellern einen Verlust der Kontrolle über die eingesetzten Open Source Bibliotheken. Es ist teilweise schwer festzustellen, welche Abhängigkeiten zu Open Source Libraries im eigenen Code bestehen, besonders wenn Bibliotheken eingebunden wurden, die sich ihrerseits auf weitere Bibliotheken verlassen.

UM UNDURCHSICHTIGKEIT UND EINSCHRÄNKUNGEN DER SICHERHEIT DER GESAMTEN SOFTWARE ZU VERMEIDEN, MUSS DIE KONTROLLE ÜBER DEN OPEN SOURCE EINSATZ GEWÄHRT SEIN

Ein Weg, um die Kontrolle zurück zu gewinnen, ist es, ein automatisiertes Verfahren in den Entwicklungsprozess zu integrieren, das ständig einen belastbaren Überblick über verwendete Open Source Komponenten liefern kann. Dies bietet eine wichtige Grundlage von Informationen und zeigt mögliche Herausforderungen – und damit auch mögliche Handlungen- in Bezug auf neue Erkenntnisse zu Anforderungen sowie Maintenance und Compliance an.

Weitere Informationen unter: Video