06.05.2021 | Fachthema

Open Source Software - Stolperfallen vermeiden

Open Source Software - Stolperfallen vermeiden

Open Source Software erfolgreich einsetzen

Musste man vor ein paar Jahren das Thema Open Source Software (OSS) in vielen Projekten noch erklären, ist das heutzutage kaum mehr so. Dank Android, Qt, Flutter, Tensorflow und Co hat OSS in vielen kommerziellen Projekten Einzug gefunden.

Das finden Entwickler großartig, denn diese offenen Projekte können auch die kommerzielle Produktentwicklung schneller und einfacher zum Erfolg führen. Doch mit der großen und einfach verfügbaren Funktionalität der Open Source Komponenten kommt auch die große Verantwortung. Denn es gibt einige Stolperfallen, die beachtet werden müssen, um erfolgreich ans Ziel zu kommen.



Stolperfallen auf dem Weg zum Ziel

Der erste Stolperstein ist, sich blind auf unkontrollierte (=nicht aktiv gewartete) Open Source Komponenten zu verlassen. Ein Zweiter ist es, kein aktives Monitoring auf Sicherheitslücken in seiner produktiven Software zu betreiben. Beide Stolpersteine führen dazu, sich schwere Sicherheitslücken ins Produkt zu holen.

Zu diesen Themen wurde von Synopsys der Bericht  "Open Source Security and Risk Analysis" (OSSRA) publiziert. Dieser bietet Einblick in den aktuellen Stand der Open Source-Sicherheit, Compliance, Lizenzierung und Code-Qualitätsrisiken bei kommerzieller Softwareprojekten. Synopsis untersuchte dabei anonymisierte Audit-Ergebnisse von über 1.500 kommerziellen Codebasen (Die Codebase sind der Code und die Bibliotheken, die eine Anwendung oder Service ausmachen) in 17 unterschiedlichen Branchen. Im Bericht wird schnell klar, dass Open-Source-Bibliotheken die Grundlage für buchstäblich jede Anwendung in jeder Branche sind.

 

Im Branchenvergleich sieht der Einsatz von Open-Source Bibliotheken wie folgt aus:


Statistik Einsatz von OSS in %:

  • Medical: 84%
  • Energy and Clean Tech: 81%
  • Computer Hardware and Semiconductors: 74%
  • Internet and Mobile: 82%
  • Retail and E-Commerce: 48%

 

Dabei wird klar: Speziell in den Kernbereichen Energy und Medical, in denen Ginzinger electronic systems  tätig ist, ist die Verbreitung von OSS enorm. Das Schlusslicht E-Commerce bildet dabei eine Ausnahme. Aber was bedeutet dieser breite Einsatz für die Sicherheit der eingesetzten Komponenten? Hier kommen gemischte Gefühle auf.

 

Bei 84% der analysierten wurde mindestens eine Schwachstelle gefunden. Das sind durchschnittlich 158 offene Schwachstellen pro Codebase, wobei diese schon seit rund zwei Jahren bekannt waren. Ob dies jetzt fatal schlecht oder im Vergleich noch ganz in Ordnung ist, ist als Nicht-Experte schwer einzuordnen. Fakt ist aber, das die Anzahl und Kritikalität von Schwachstellen in den letzten Jahren beständig steigt. Das zeigt auch folgende Statistik:

Statistik über mindestens eine Schwachstelle pro Codebase:

 

 

  • 2018: 60%
  • 2019: 75%
  • 2020: 84%

 

 


Noch unwohler wird einem, wenn man sich die Entwicklung der Anzahl von Codebases der letzten Jahre ansieht, die eine kritische Schwachstelle aufweisen:

  •     2018: 40%
  •     2019: 49%
  •     2020: 60%


Erfreulicherweise zeigen einige Branchen einen klaren Trend zur Verbesserung. Führend sind hier vor allem die Bereiche IoT, Hardware & Halbleiter, sowie Internet & Mobile und Produktion und Robotik. Hier ist die Anzahl der kritischen Schwachstellen der Codebases deutlich zurück gegangen.

Bei einer näheren Analyse der Schwachstellen (CVEs) wird schnell klar: Die Top-Schwachstellen kommen zum größten Teil aus der Java Script-Welt. Hier wurde teilweise einfach nicht auf aktuelle Versionen hochgezogen. Oder es wurden Bibliotheken verwendet, die selbst auf alten Ressourcen aufsetzen.


Schwachstellen vermeiden mit Software BOMs

Lösungen für diese Themen sind dabei durchaus vorhanden. Eine Software BOM (Bill of Material) beispielsweise verschafft Überblick über die eingesetzten Softwarekomponenten und Bibliotheken. Diese Software BOM kann dann über ein aktives Monitoring mit Schwachstellendatenbanken verglichen werden. So sieht man rasch, ob es kritische Schwachstellen im eigenen Produkt gibt. Auch hier gilt: Was heute sicher ist, kann morgen schon als unsicher gelten. Die aktualisierte Software kann dann in einem Softwarepatch z.B. über sichere Over-the-air-Updates auf alle im Feld befindlichen Produkte ausgerollt werden. Ebenfalls Teil der Lösung ist es, mit seiner Software nahe an den Langzeit Support Versionen (LTS) und Mainline Versionen dranzubleiben. Damit fährt man in der Regel am stabilsten und auf lange Sicht gesehen am besten.

 

GELin als Garant für sichere Produkte

Ginzinger electronic systems bietet eine einfache Lösung. Mit GELin, dem eigenen Linux Betriebssystem setzen wir auf aktives Monitoring der Software-komponenten, auf ein stabiles und langfristig gewartetes Mainline Linux, sowie auf einer einfach zu erstellenden Software BOM. Damit kann ein Projekt rasch und ohne große Mühe umgesetzt werden. GELin ist so Garant für langfristig erfolgreiche und sichere Produkte.

 

Das ergänzt sich mit den Schlussworten des Synopsis Berichts, der wie folgt resümiert:
„Um die im Bericht erwähnten Herausforderung zu meistern, benötigen Entwicklungsteams zuverlässige und zeitnahe Informationen zu Schwachstellen, ein umfassendes Inventar der Open-Source-Abhängigkeiten, die ihre Software nutzt, genaue Hinweise zum Schweregrad der Schwachstellen und zur Ausnutzbarkeit, sowie klare Anweisungen zum Patchen der betroffenen Open-Source-Software.“


Link zum Bericht: https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html

Aktuelle Webinare zum Thema finden Sie hier

Kontakt

Sie haben Fragen

oder möchten Kontakt aufnehmen?