Augen auf beim Cut-&-Paste von Open-Source-Software
In Zeiten von Internet of Things (IoT) und vernetzten Smart Devices gewinnt Open-Source-Software weiter an Bedeutung. Sie bringt zahlreiche Vorteile mit sich, birgt aber auch Risiken hinsichtlich Sicherheit und Compliance. Open Source kommt auf verschiedenen Wegen in die Software von Herstellern, oft per Cut-&-Paste. Hier ist Vorsicht geboten.
Open-Source-Software (OSS) hat die Art und Weise, wie Software entwickelt wird, verändert. Um Zeit zu sparen und um sich ganz auf den kreativen, komplexen und anspruchsvolleren Teil ihrer Arbeit zu konzentrieren, greifen Softwareentwickler für Programmierroutinen gerne auf OSS- und kommerzielle Komponenten zurück. Mit dieser Arbeitsmethode können sie Software schneller und effizienter entwickeln und testen. Zudem teilen sie ihre entwickelten Codes in der Community und stellen Erweiterungen und Verbesserungen des bereits veröffentlichten Codes bereit. Dadurch bietet OSS grundsätzlich ein höheres Maß an Sicherheit und Qualität.
Mit dem IoT gewinnt OSS weiter an Bedeutung. Neun von zehn IoT-Entwicklern verwenden OSS. Das im IoT weit verbreitete Betriebssystem Linux, das von vielen smarten und vernetzten Geräten verwendet wird, enthält beispielsweise Dutzende bis Hunderte von Open-Source-Paketen. In der Folge machen OSS-Komponenten bis zu 50 Prozent des Codes kommerzieller Software aus. Open Source gelangt auf unterschiedlichen Wegen in den Code von Herstellern, entweder durch die Verwendung kompletter Pakete oder auch durch das Einfügen kleinerer Snippets in den eigenen Code per Cut-&-Paste.
Warum ist Cut-&-Paste von Open-Source-Code so beliebt?
Es gibt mehrere Gründe, warum Entwickler sich für Cut-&-Paste von Code in ihre Codebasis entscheiden. Oft kann beispielsweise eine Softwarekomponente erst dann eingesetzt werden, nachdem Code hinzugefügt oder entfernt wurde. Der Code stammt häufig von einem vorangegangenen Projekt. Dieser Basiscode ist zumeist nicht mit eindeutigen Copyrights und Lizenzbedingungen gekennzeichnet, fließt aber dennoch in den Kerncode des Projektes ein.
Open-Source-Projekte können dabei helfen, diese Code-Fragmente und Beispielcode eindeutig zu kennzeichnen und dabei auch mögliche Lizenzunterschiede zwischen den beiden Codes zu berücksichtigen. Ein weiterer typischer Grund für die Cut-&-Paste-Methode ist, wenn nur das Kernstück einer Routine verwendet werden soll, während die restlichen Programmierroutinen nicht gebraucht werden. Beispiele dafür sind Algorithmen, Hilfsfunktionen und statische Daten.
Welche Risiken sind mit der Nutzung von OSS verbunden?
Trotz der gängigen Praxis sind auch zwei Risiken mit der Nutzung von Open-Source-Software verbunden: Compliance und Sicherheit. Denn in der Praxis kann nur schwer nachvollzogen werden, aus welchen Codekomponenten ein Softwareprodukt besteht. Fragen wie "Woher kommt der Code eigentlich?", "Welche Compliance geht mit dem Code einher?" und "Gibt es Schwachstellen im Code?" gilt es zu beantworten. Firmen, die nicht eindeutig wissen, welche Komponenten sie verwenden, gehen ein Risiko ein, denn sie können Risiken, die von Open-Source- und Drittanbieter-Code kommen, nicht hinreichend kontrollieren.
Was gilt es bei OSS-Compliance zu beachten?
Heutzutage hat OSS-Compliance für Sicherheits-, Entwicklungs- und Rechtsabteilungen oberste Priorität. Dies gilt insbesondere für das IoT, wo die Mehrzahl der Geräte und Embedded Systemen auf Linux basiert und damit der General Public License (GPL) unterliegen. Danach sind Entwicklerteams bei der Nutzung verpflichtet, den Quellcode aller Produkte und Komponenten, in denen sie GPL-lizenzierte, unveränderte oder veränderte Komponenten verwenden, offenzulegen. Wichtig ist dabei, die richtige Version der GPL anzugeben. Drei gängige Versionen stehen zur Verfügung: GPLv1, GPLv2 und GPLv3.
Doch das ist nicht alles. Zusätzlich kann jede Lizenz mit einer Ausnahme verbunden sein, die verstanden, respektiert und weitergegeben werden muss. Ist die Lizenzierung einer Open-Source-Komponente nicht eindeutig, sollten Entwickler reagieren. Entweder wird die Komponente wenig genutzt oder der Anwenderkreis ist relativ klein. Das bedeutet jedoch nicht, dass keine Lizenzvorgaben zu erfüllen sind. So ist es denkbar, dass ein Mitentwickler im Rahmen des ursprünglichen Entwicklungsprojekts nachträglich einen Antrag stellt, um den Code unter eine Lizenz zu stellen oder die lizenzrechtliche Lage neu festzulegen. Noch komplexer wird es, wenn die Einhaltung von GPL – und damit die Weitergabe des Quellcodes an die Nutzer – mit anderen Lizenzverpflichtungen (z. B. für kommerzielle Software) im Widerspruch steht.
Welche Sicherheitsrisiken können entstehen?
Zu Open-Source gehören mehr als nur Linux und die gängigen OSS-Unternehmensanwendungen (wie SugerCRM, Pentaho, Open Office). Insbesondere namenlose OSS-Komponenten bereiten Chief Security Officer Bedenken hinsichtlich ihrer Sicherheit. Wird eine Vulnerability mit hohem Sicherheitsrisiko veröffentlicht, ist es nötig, den gesamten Softwarecode schnellstmöglich auf diese Schwachstelle hin zu untersuchen – sowohl in bereits ausgelieferten als auch im Auslieferungszustand befindlichen Versionen. 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.
Fast 90 Prozent der Angriffe auf Software zielen auf die Anwendungsebene selbst ab, darunter Software-Schwachstellen und fehlerhafte Codes. Die Menge an Malware, die Schwachstellen in Software von Drittanbietern ausnutzt, steigt kontinuierlich. Eine geeignete Angriffsfläche finden Schadprogramme auch in bereits ausgelieferten Produkten, die nach wie vor Sicherheitslücken aufweisen. So nutzte Bashlite IoT ursprünglich die Shellshock/Bash-Schwachstelle, um IoT-Systeme zu infizieren und sich weiter zu verbreiten. Andere Angriffe zielten auf kommerzielle Komponenten in White-Label-Überwachungskameras, deren eingebettete Benutzernamen und Passwörter bekannt waren. Um hier Software-Lösungen zuverlässig zu schützen, empfiehlt es sich für IoT-Entwickler, das Management von Open-Source-Komponenten explizit in ihre allgemeine Sicherheitsstrategie mit einzubinden.
Welche Herausforderungen bestehen beim Cut-&-Paste von OSS?
Trotz der Risiken kopieren Softwareentwickler gelegentlich Dateien, Codefragmente, Bilder, Binärdateien oder ganze Module ohne die entsprechenden Open-Source-Lizenzen einzuhalten. Auch wenn die Entwickler sorgfältig darauf achten, Lizenzen für ihre Hauptkomponenten anzugeben, besteht das Risiko, dass sie Code verwenden, der bereits zufällig kopiert und bearbeitet wurde. Laut Umfragen beträgt der Anteil der in Verzeichnissen aufgeführten Komponenten in Unternehmen durchschnittlich nur vier Prozent. Auf jede bekannte Komponente fallen 24 weitere Komponenten, die unerkannt und unverwaltet in der Software verwendet und ausgeliefert werden.
Die Herausforderung beim Cut-&-Paste von Codefragmenten ist, dass das ursprüngliche Copyright und die Lizenz oft fehlen oder nicht übernommen werden. In den seltensten Fällen wird die fehlende Dokumentation bewusst in Kauf genommen. Meist herrscht Unklarheit und Unsicherheit darüber, welche Vorgaben bei welchen Projekten und auf welche Weise eingehalten werden müssen. Oft sind bestehende Prozesse im Bereich Cut-&-Paste schlicht überholt oder über die Jahre hinweg eingeschlafen. GPL-Binärdateien beispielsweise gelangen in der Regel zunächst über die Software Supply Chain in ein Unternehmen und werden, einmal verwendet und integriert, an das nächste Projekt und den nächsten Entwickler weitergegeben – oftmals ohne erneute Überprüfung. Das gleiche gilt für Software-Vulnerabilities, die sich unerkannt über Jahre im Code befinden, ohne dass Updates und Patches vorgenommen werden.
Es ist wichtig, klare Richtlinien aufzustellen, wie man Codeteile für Lizenzierungs- und Sicherheitsüberprüfungszwecke richtig dokumentiert, um die Einhaltung der Bestimmungen zu gewährleisten. Auch für zukünftige Bearbeiter des Quellcodes ist es von unschätzbarem Wert, zu wissen, welcher Entwickler was erstellt oder verändert hat.
Was sind die Vorteile von Source-Code-Fingerprinting?
Das Scannen von Code mit Hilfe von Fingerabdrücken im Quellcode ist ein effizienter Weg, um zuverlässig herauszufinden, welche Inhalte von Drittentwicklern im Code enthalten sind. Das heißt, Quellcode-Fingerprinting ermöglicht den Vergleich des Quellcodes in einer Anwendung mit einer Datenbank von Open-Source-Projekten, um zu sehen, ob es Code gibt, der kopiert und eingefügt oder anderweitig hinzugefügt wurde. Anhand dieses Abgleichs können Entwickler beispielsweise auch feststellen, ob kürzlich veröffentlichte Vulnerabilities auch ihre Produkte betreffen. Mit einem so detaillierten Abgleich schließen Unternehmen die Lücke zwischen den ihnen bekannten und den tatsächlich verwendeten Komponenten und versetzen sich damit in die Lage, einen kompletten Bill of Material zu erstellen und all ihre Komponenten – egal wie sie in den Code gelangt sind – effektiv zu managen.
Der Bill of Materials
Um den Basisabgleich durchführen zu können, müssen Entwickler wissen, welcher Code in welcher Software genutzt wird und welche Lizenzen damit verbunden sind. Ein aktuelles Verzeichnis aller Abhängigkeiten oder eine Stückliste (Bill of Materials – BOM) der im Unternehmen genutzten Komponenten als auch der Komponenten von Drittanbietern ist zwingend notwendig. Eine Aufstellung zu den genutzten Softwarekomponenten war lange Zeit bis auf wenige Ausnahmen kaum zu finden. Das änderte sich schlagartig mit Heartbleed. Die OpenSSL-Sicherheitslücke gilt nach wie vor als eindrücklicher Beweis dafür, wie wichtig ein aktuelles Verzeichnis aller Abhängigkeiten und eine BOM der eingesetzten Komponenten sind. Es enthält in der Regel Quellangaben und Informationen zur Lizenzierung jeder OSS-Komponente. So lassen sich Lizenzvorgaben einhalten und die Risiken von Software-Vulnerabilities minimieren.
Mithilfe eines Selbsttests lässt sich schnell überprüfen, ob eine aktuelle BOM im Unternehmen geführt wird. Dabei sind die folgenden Handlungsempfehlungen zu beachten:
- Eine Stückliste ist mit hoher Sicherheit nicht vollständig, wenn sie allein auf den Einschätzungen der Entwickler basiert.
- Stichproben des Quellcodes erlauben es, die angegebenen Versionsnummern auf Aktualität hin zu prüfen.
- Für einen ersten Überblick empfiehlt sich die Durchsicht der Bibliotheks-Namen, die Suche nach Copyright-Informationen, Lizenzen und kopierten Dateien sowie die Überprüfung auf Dateiendungen vermeintlicher Drittanbieter (z. B. .JAR, .DLL).
- Die Suche nach dem String "OpenSSL" ermöglicht es, Kopien von bislang nicht bekannten Fällen von OpenSSL in Open-Source- und in kommerziellen Komponenten zu finden – in Binärprogrammen und in Quelldateien.
Wie kann ein Software-BOM erstellt werden?
Um eine ganzheitliche Software-Stückliste zu erstellen, können Entwickler folgende Schritte durchführen:
- Erstellen eines Verzeichnisses von neuen Top-Level-Komponenten, die in der Regel in eindeutig bezeichneten Dateien und Directories zu finden sind. Dies deckt jedoch in der Regel nur 10 bis 30 Prozent der tatsächlich zu erfassenden Stückliste ab.
- Erfassen der Teilkomponenten, die deutlich schwerer zu ermitteln sind und in denen sich selbst bekannte Vulnerabilities wie Heartbleed leicht verstecken können.
- Überprüfen der Codebasis der verbleibenden Quelldateien, um festzustellen, ob Open-Source-Komponenten durch Cut-&-Paste, Refactoring oder Umstellungen von größeren Paketen in das Produkt gelangt sind.
Ist eine Stückliste erstellt, folgt der Abgleich mit Komponenten, die bekannte Vulnerabilities enthalten. Eine Liste dieser Schwachstellen findet sich beispielsweise in der National Vulnerability Database oder in der Schwachstellenampel des BSI [1]. Erfahrungsgemäß finden Entwickler hier besonders bei einer ersten Überprüfung eine Vielzahl an gefährdeten Komponenten. Einige dieser Vulnerabilities sind einfacher auszunutzen als andere, daher ist es gängige Praxis, Prioritäten festzulegen und eine Handlungsreihenfolge für den Ernstfall zu bestimmen. Zu den Maßnahmen der Gefahrenbehebung zählen Upgrades auf die nächste Version, Patch-Prozesse, Blockieren des Zugriffs und in manchen Fällen auch das vollständige Entfernen der Komponente und aller betroffener Produktfeatures.
Die BOM wird genutzt, um den kompletten Code zu scannen und zu analysieren und damit letztendlich Lizenzverstöße zu identifizieren und zu beheben. Dazu kann es nötig sein, den Code zu entfernen oder neu zu schreiben, Angaben für Dritte zu erstellen oder den Quelltext bei Copyleft-Code weiterzugeben. In Folgeprojekten fällt es damit deutlich leichter, die Compliance einzuhalten, da weniger Unklarheiten über den Ursprung von OS-Code bestehen. In den meisten Fällen werden Ergänzungen und Änderungen in der Codebasis vom aktuellen Entwicklerteam vorgenommen. Das erlaubt, sämtliche Veränderungen direkt bei ihrer Durchführung, am selben Tag oder im selben Sprint, zu überprüfen.
Welche Inhalte sollten OSS-Richtlinien abdecken?
Es gibt viele Diskussionen darüber, wieviel beim Cut-&-Paste von OSS erlaubt ist. Unternehmensinterne Richtlinien sollten Entwicklern genaue Vorgaben zur Erkennung, Überwachung und Beseitigung von Open-Source-Risiken bieten. Nicht alle diese Vorgaben machen für alle Unternehmen und Anwendungsfälle gleich viel Sinn. Trotzdem gilt es grundsätzlich, den Eigentümer, die Kontaktinformationen und die Lizenz für das betreffende Codefragment zu erfassen. Wenn diese Informationen nicht sofort verfügbar sind, kann eine Nachfrage an den ursprünglichen Entwickler gestellt werden, die auf den betreffenden Code verweist, den Anwendungsfall vorstellt und nach der entsprechenden Lizenz fragt. Bleibt die Antwort aus oder die genannte Lizenz des Entwicklers verstößt gegen die unternehmensinternen Richtlinien, ist es üblich, nach einem neuen, passenden Quellcode zu suchen.
Keine Richtlinie ist so umfassend, dass sie nie mehr geändert werden kann.
Daneben sollte eine einheitliche Vertragssprache, die die Offenlegung von Fremdkomponenten sowie den Prozess der Benachrichtigung über Patches oder Upgrades im Zusammenhang mit Schwachstellen detailliert regelt, eingeführt werden. Wichtig ist zudem, dass alle Richtlinien und Vorgaben auf die Entscheidungen und Bedürfnisse der Entwickler sowie auf die zu entwickelnden Produkte abgestimmt sind. Keine Richtlinie ist so umfassend, dass sie nie mehr geändert werden kann. Die erste Überprüfung eines Produktes kann oft zu einer nachhaltigen Einsicht führen und drastische Änderungen bestehender Abläufe bewirken. Neue Richtlinien sind beispielsweise nötig, um problematische Abhängigkeiten Dritter in kommerziellen Komponenten zu regeln und zu beseitigen.
Fazit
Wer im Rahmen seiner Open-Source-Strategie sichere Anwendungen gewährleisten will, muss über entsprechende Prozesse und leicht verständliche Richtlinien, Schulungen und Werkzeuge verfügen, die auch Vorgaben zum Cut-&-Paste von Code umfassen. Die gute Zusammenarbeit der Teams für Sicherheit und Engineering ist ein weiterer wichtiger Baustein. Hierzu gehört zum einen eine genaue Bestandsaufnahme der verwendeten Open-Source-Komponenten unter der Zuständigkeit des Engineering-Teams, zum anderen die Überprüfung der verwendeten Open-Source-Projekte auf bekannte und veröffentlichte Schwachstellen unter der Zuständigkeit des Sicherheitsteams. Um die genannten Lücken schließen zu können, bedarf es robuster neuer Werkzeuge für das Open-Source-Management und ein geschärftes Risikobewusstsein.
