Ein wachsendes Problem: Veraltete Open Source-Komponenten
Boris Cipot erläutert in seinem Beitrag die Rolle der Software-Stückliste in einem verantwortungsvollen Open Source Management.
von Boris Cipot
Die Open Source-Nutzung hat im Laufe der Jahre deutlich Fahrt aufgenommen. Parallel dazu hat sich das Open Source Management weiterentwickelt. Zunächst haben Unternehmen sich bei ihren Bemühungen auf die Lizenzidentifikation bei Open Source konzentriert – nach wie vor ein wesentlicher Bestandteil jeder Open Source-Managementstrategie.
Mit der wachsenden Popularität von Open Source-Anwendungen hat sich neben der Lizenzproblematik ein weiteres Risiko herauskristallisiert: bekannte Schwachstellen zu identifizieren und einzudämmen. Ein kritischer Faktor innerhalb eines verantwortungsvollen Open Source Managements.
Gartner-Analytiker Dale Gardner beschreibt das in seinem Beitrag „Technology Insight for Software Composition Analysis“ so: „ (…) erweitern erfahrene Unternehmen heute das Open Source Management um die Bewertung des allgemeinen „Gesundheitszustands“ der Software anhand der Herkunft und des Supports eines bestimmten Pakets.“
Das Problem veralteter Technologie macht auch vor Open Source nicht Halt
Einer der Gründe warum Open Source so beliebt ist liegt darin, dass hinter funktionierenden Open-Source-Projekten in der Regel starke Communities stehen. Sie kümmern sich darum Schwachstellen zu überarbeiten, upzudaten und zu patchen, sobald sie bekannt werden. Viele Entwickler machen sich allerdings nicht unbedingt die Mühe, zunächst die Leistungsfähigkeit einer Community zu überprüfen, bevor sie eine Open-Source-Komponente herunterladen. Und selbst dann, wenn ein Entwickler Komponenten nur von zuverlässigen Open Source-Communitys herunterlädt, ist das noch keine Garantie dafür, dass die Community diese Komponente oder eine spezifische Version weiterhin aktiv pflegt.
Das Problem veralteter Technologie macht offensichtlich auch vor Open Source nicht Halt. Tatsächlich hinken Unternehmen erstaunlich weit hinterher, wenn es um die Verwendung der aktuellen Version einer bestimmten Open-Source-Komponente geht. Laut den Ergebnissen des vom Synopsys Cybersecurity Research Center (CyRC) veröffentlichten 2020 Open Source Security and Risk Analysis (OSSRA) Bericht, enthalten 88 % der auditierten Codebasen Open-Source-Komponenten, die seit vier Jahren nicht weiterentwickelt wurden.
Jede Software altert. In der Folge mangelt es an Support. Bei Open Source Software verhält es sich kaum anders. Hier nimmt die Zahl der Entwickler, die sonst für Updates sorgen, mit der Zeit ab. Das betrifft Funktionsverbesserungen, aber auch Updates, die für mehr Sicherheit und Stabilität sorgen. Ohne die Bereitstellung von Fixes, wird eine überalterte Open-Source-Komponente irgendwann wahrscheinlich nicht mehr funktionieren – oder eine Codebasis offen legen, die sich leicht auszunutzen lässt.
„Unternehmen hinken erstaunlich weit hinterher, wenn es um die Verwendung der aktuellen Version einer bestimmten Open-Source-Komponente geht.“
Boris Cipot
Die mangelnde Update-Häufigkeit kann zu Sicherheitsproblemen führen, die vielleicht seit über 20 Jahren in einer Codebasis bestehen. Das war beispielsweise bei PuTTY SSH der Fall, einer Open-Source-Applikation für den File Transfer im Netzwerk. Die zwei Jahrzehnte alte Schwachstelle wurde erst im Juni 2019 entdeckt und im September offengelegt. Man mag sich fragen, wie gefährlich eine Schwachstelle ist, die über zwanzig Jahre lang unentdeckt blieb. Allerdings verfügen gerade ältere Open-Source-Tools wie PuTTY oft über Funktionen, die selten genutzt werden, aber Schwachstellen aufweisen. Angreifer wissen das und suchen gezielt nach solchen Lücken, die es ermöglichen die Codebasis zu öffnen und auszunutzen.
Die Open-Source-Community veröffentlicht kleine, weniger umfangreiche Updates normalerweise sehr viel schneller als ein durchschnittlicher kommerzieller Softwareanbieter. Enthalten diese Updates Sicherheitsverbesserungen, müssen Unternehmen eine Strategie entwickeln, Aktualisierungen zügig zu übernehmen. Open Source Updates müssen jedoch von den Nutzern „abgerufen“ werden. Dieser Umstand hat dazu geführt, dass eine alarmierende Anzahl von Unternehmen zwar Open-Source-Komponenten einsetzt, die benötigten Updates oder Patches aber nicht einspielt. Das birgt Risiken wie die eines Angriffs oder eines potenziellen Exploits wichtiger Applikationen. Zweiundachtzig Prozent der im Rahmen des OSSRA-Berichts überprüften 1.253 Codebasen enthalten Open-Source-Komponenten, die seit über vier Jahre veraltet sind.
Das „Einfügen und Vergessen“-Syndrom
Wenn Unternehmen mit der Versionierung in Verzug geraten, erhöht sich das Sicherheitsrisiko. Das ist aber noch nicht alles. Es besteht zusätzlich die Gefahr, dass ein einfaches Updaten auf die neueste Version zu unerwünschten Funktionsänderungen führt, z.B. können wichtige Funktionen verschwinden. Entwicklungsteams müssen zudem befürchten zusätzlichen Code ändern zu müssen, wenn sie die neuere Version einer Open-Source-Komponente verwenden wollen. Dadurch entsteht ein Dominoeffekt, der die Entwicklung zum Stillstand bringen kann.
Dass so viele der eingesetzten Komponenten veraltet sind, ist jedoch nicht das Ergebnis einer bewussten Entscheidung. Vielmehr ist es das Resultat einer Mentalität, die man am besten mit „insert an forget“ beschreibt. Entwickler tragen normalerweise keine Versionsinformationen zu einer Komponente in eine Inventar-Tabelle ein, bevor sie mit anderen Tätigkeiten fortfahren. Solange der Code funktioniert wie er soll, wird er ignoriert und schließlich vergessen – bis er eben nicht mehr wunschgemäß funktioniert oder angegriffen wird.
Die Software-Stückliste – unverzichtbar
Unabhängig vom Alter oder Versionierung kann man Probleme mit veralteten Open Source-Komponenten nur auf Basis eines aktuellen, präzisen Software-Bestandsverzeichnisses angehen, allgemein auch unter dem Namen Software-„Stückliste“ oder BOM (Bill of Materials) bekannt. Eine umfassende Software-Stückliste sollte, über eine reine Inventar-Tabelle hinaus, alle Open Source-Komponenten, die verwendeten Versionen und Speicherorte für Downloads für jedes verwendete oder in der Entwicklung befindliche Projekt enthalten. Die Stückliste sollte zudem alle Abhängigkeiten oder Bibliotheken verzeichnen, die der betreffende Code aufruft, sowie die Bibliotheken, mit denen diese Abhängigkeiten verknüpft sind.
Das Konzept der Stückliste stammt ursprünglich aus der Fertigung. Hier ist die klassische Stückliste ein Inventar, in dem alle in einem Produkt enthaltenen Elemente detailliert aufgeführt werden. Wenn im Automobilbau ein defektes Teil entdeckt wird, weiß der Hersteller genau, welche Fahrzeuge betroffen sind, und kann mit dem Reparatur- oder Austauschprozess beginnen. In ähnlicher Weise ist die Pflege einer genauen, aktuellen Software-Stückliste, die ein Inventar von Drittanbieter- und Open-Source-Komponenten enthält, für Unternehmen unabdingbar. Die Liste gewährleistet, dass die verwendeten Open Source-Komponenten qualitativ hochwertig, konform und sicher sind. Und wie in der Fertigung, lassen sich mithilfe einer vollständigen Stückliste der Open Source-Komponenten problematische Komponenten schnell lokalisieren und Abhilfemaßnahmen priorisieren.
Ãœber den Autor
Boris Cipot,
Senior Sales Engineer, Synopsys
