Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
Op e n So u r c e 0 8 -2 2 · w w w c o m p u t e r - a u t o m a t i o n d e | 13 • Und drittens bieten Open-Source-Technologien nicht selten eine populäre Lösung für ein allfälliges Problem Beispielsweise gibt es viele Optionen für die Container-Orchestrierung aber Kubernetes hat die Nase vorn – das heißt die Implementierung genießt sowohl bei Fachleuten als auch bei Wettbewerbern ein hohes Vertrauen Was in der Diskussion um die Akzeptanz verloren geht ist dass Open-Source-Software genau wie kommerzielle Software oft aus mehreren Komponenten besteht Es gibt weder eine einzige ausführbare Linux-Datei noch eine einzige ausführbare Kubernetes-Datei Jede einzelne erfordert eine beträchtliche Anzahl von Abhängigkeiten Das Gleiche gilt für mobile Anwendungen IoT-Firmware und sogar simple Logikfunktionen bei geschäftlichen Anwendungen wie sie über AWS Lambda bereitgestellt werden Sie alle weisen Abhängigkeiten auf die notwendig sind damit die Anwendung richtig funktioniert Wenn Leute dann von einer „Software Supply Chain“ sprechen ist es diese Liste von Abhängigkeiten auf die sie sich beziehen und es ist auch genau diese Liste von Abhängigkeiten in der das größte Risiko bei Open Source liegt Die Frage der Resilienz Wenn ein Open-Source-Projekt ausreichend weit verbreitet ist um zu einem De-Facto-Standard zu werden wie etwa Kubernetes dann arbeiten viele freiwillige Entwickler am Code Manch ein Unternehmen stellt sogar Entwickler ab welche sich ausdrücklich nur um Kubernetes kümmern Das bedeutet Resilienz Wenn ein Entwickler pausiert oder sich ganz aus dem Projekt zurückzieht geht es trotzdem weiter Populäre Projekte verkraften es deshalb sogar relativ gut wenn sich zentrale Entwickler verabschieden Bei kleineren Projekten ist die Sachlage eine völlig andere Es gibt Millionen von GitHub-Projekten bei denen sich die Zahl der Entwickler im einstelligen Bereich bewegt Und GitHub ist nicht das einzige Repository für Open-Source-Aktivitäten Wenn sich dann nur ein einziger Entwickler zurückzieht ist das nicht selten jemand der genau versteht warum bestimmte Bereiche des Codes so geschrieben wurden wie sie jetzt sind Solche Projekte finden sich am häufigsten auf der Liste der Abhängigkeiten für eine Anwendung Oft decken sie elementare Aktivitäten ab wie etwa das Schreiben von Logdaten – wie im Fall von log4j Da die Zahl der Entwickler bei Open-Source-Projekten so stark variiert überrascht es auch nicht dass sie sehr unterschiedlich auf einen Sicherheitsvorfall reagieren Einige wie Kubernetes oder das Xen-Projekt haben entsprechend ihrem Standing sehr gut definierte Sicherheitsprozesse Andere behandeln ein Sicherheitsproblem exakt wie jeden anderen Bug der zwar behoben werden muss – aber eher zu einem unbestimmten Zeitpunkt in der Zukunft Ein gut definierter Sicherheitsprozess verknüpft wahrscheinlich einen Patch mit einer Offenlegung im CVE-Format Projekte die Sicherheitsprobleme wie Bugs behandeln beheben häufig einfach nur den Fehler legen ihn aber nicht offen Das macht es für ein Unternehmen nicht unbedingt leichter das Risiko in der Supply Chain realistisch zu bewerten und angemessene Richtlinien zu entwickeln die eben dieses Risiko senken sollen Ein Muss Umfassende Inventarisierung Wenn man das mit Open-Source-Software verbundene unternehmerische Risiko senken will das in Wirklichkeit ein Softwarerisiko ist sollte man eine Prämisse akzeptieren Firmen profitieren von Open-Source-Software Ein Großteil des geschäftlichen Risikos rührt daher dass Open-Source-Software anders verwaltet wird als kommerzielle Software Die Beschaffungsund Patch-Prozesse bei beiden sind unterschiedlich Realistisch betrachtet lassen sich OSS und kommerzielle Software nicht auf ein und dieselbe Art managen Wer das Risiko senken will sollte mit einer umfassenden Inventarisierung des Bestandes sämtlicher im Unternehmen verwendeten Software beginnen Asset Management und zwar unabhängig davon woher die Software stammt und welcher Beschaffungsprozess zugrunde liegt Anhand dieses Inventars kann man feststellen welche Open-Source-Komponenten von den einzelnen Assets verwendet werden Das passiert mithilfe der so genannten Software Composition Analysis SCA Eine Software kann sowohl in eine Binärdatei kompiliert oder quellbasiert sein Das ausgewählte SCA-Tool sollte also sowohl binäre als auch quellbasierte Assets mit den gleichen Mitteln verarbeiten können Ein Asset-Inventar umfasst vermutlich tausende von Einträgen Es macht also Sinn wenn ein SCA-Tool aktiv auf Änderungen des Sicherheitsrisikos innerhalb der Assets hinweist und zwar ohne dass ein erneuter Scan nötig ist An diesem Punkt lässt sich festlegen wie mit einem veränderten Risiko aufgrund einer neu offengelegten Schwachstelle umgegangen werden soll Schließlich ist es nicht ganz einfach etwas zu patchen von dem bislang niemand wusste dass es überhaupt vorhanden ist Genauso wie man nie gewiss sein kann wann wieder eine neue Software mit einer anfälligen Komponente erstellt worden ist hap Web-Tipp Sie wollen wissen was sich hinter einer Software Composition Analysis verbirgt? https bit ly 3Py5AqH Lucas v Stockhausen ist Senior Director Solutions and Sales Engineering bei Synopsys SIG sps 2022 | Wir sind dabei computerautomation de sps ifm