Immersive Open Source Compliance-Visualisierung

Stellen Sie sich vor, Sie könnten jede einzelne Komponente Ihrer Software wie eine Landkarte durchforsten – Risiken auf einen Blick erkennen, versteckte Abhängigkeiten aufspüren und Schwachstellen mühelos entlarven. Genau das macht eine Software-Stückliste (SBOM) möglich! Der Artikel beleuchtet, warum diese „Zutatenliste“ moderner Softwareprojekte heute unverzichtbar ist, vor allem da Open Source mittlerweile einen Löwenanteil in der Entwicklung einnimmt. Noch besser: In einem innovativen Forschungsprojekt mit der Hochschule Bonn-Rhein-Sieg, unterstützt vom Bundesministerium für Wirtschaft und Klimaschutz, wurde eine neuartige Visualisierung entwickelt. Mit dieser lassen sich Risiken nicht nur identifizieren, sondern auch simulieren, sodass selbst komplexe Lizenz- und Kompatibilitätsprobleme sichtbar werden. Tauchen Sie ein in die Welt der SBOM – eine spannende Entdeckungsreise durch die verborgenen Schichten Ihrer Software!

Versetzen sie sich in die Lage eines IT-Sicherheitsverantwortlichen in einem Krankenhaus. Sie erhalten eine SBOM für ein neues Patientenmanagementsystem, das Sie implementieren sollen. Diese SBOM ist mehrere hundert Seiten lang und listet tausende von Softwarekomponenten, Bibliotheken und Abhängigkeiten auf. Wie gehen sie vor?

Diese Frage ist schwieriger als gedacht, aber zuerst: woher kommt eine SBOM überhaupt?

Erfahrene Entwickler schreiben ihren Code nun mal nicht von Grund auf neu, sondern nutzen vorhanden Software, kommerzielle Pakete und Open Source für die Entwicklung. Die Gründe für den Einsatz von Open Source liegen in der Verbesserung der Produktivität, der Verkürzung der Entwicklungszeit und in der Reduzierung der Entwicklungskosten. KI unterstützt immer mehr bei der Erstellung von Software. Angelernt durch Code aus Open-Source Repositories lässt sich qualitativ hochwertiger Code blitzschnell erzeugen.

Wir sehen dies über alle Branchen hinweg (Automobil, Embedded, IoT, Healthcare, Finanzen,…), und auch über die unterschiedlichsten Technologien (Linux, Windows, Embedded, Container, SaaS). Selbst eine einfache elektrische Zahnbürste oder ein Kochgerät wie der Thermomix beinhalten eine große Anzahl an Open Source. Mittlerweile hat Open Source einen Anteil in einem durchschnittlichen Projekt von 70%-90%.

Wichtig ist hierbei die Beachtung einiger Risiken: Cybersicherheit, Beachtung geistigen Eigentums, Lizenzvorgaben (wie Veröffentlichung von Code oder Nennung von Urhebern), Exportrestriktionen, Vermeidung Inkompatibilitäten, Zukunftssicherheit. Für eine rechtssichere Verwendung müssen in einer Software alle Open Source Bestandteile bekannt sein und kontinuierlich auf Sicherheitslücken oder Änderungen geprüft werden.

Eine Software-Stückliste (Software Bill of Materials, SBOM) spezifiziert das Inventar der Komponenten, die zur Erstellung eines Software-Artefakts wie einer Software-Anwendung verwendet werden. Sie ist vergleichbar mit einer Zutatenliste auf einer Lebensmittelverpackung: So wie man ein Etikett konsultieren kann, um Lebensmittel zu vermeiden, die Allergien auslösen können, können SBOMs Organisationen oder Einzelpersonen helfen, den Konsum von Software zu vermeiden, die ihnen schaden könnte.

Das Konzept der Stückliste ist in der traditionellen Fertigung als Teil des Lieferkettenmanagements fest etabliert. Ein Hersteller verwendet eine Stückliste, um die Teile zu verfolgen, die er zur Herstellung eines Produkts verwendet. Werden später Mängel an einem bestimmten Teil festgestellt, lassen sich die betroffenen Produkte anhand der Stückliste leicht auffinden.

Eine „Software-Stückliste“ (Software Bill of Materials, SBOM) ist ein formaler Datensatz, der die in Softwareprodukten enthaltenen kommerziellen und freien Softwarekomponenten enthält. Sie macht Abhängigkeiten von Komponenten Dritter transparent und hilft so Herstellern, Sicherheitsforschern und Anwendern bei der Überwachung von Schwachstellen und vielem mehr.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat einen technischen Leitfaden zu den Mindestanforderungen an eine SBOM veröffentlicht. Darin sind zum Beispiel einige Mindest-Elemente gelistet: Angaben zum Lieferanten, Autor und Zeitstempel, Version, andere eindeutige Identifikatoren (CPE, Purl, etc.), Abhängigkeitsbeziehung und Lizenz.

Normale Softwaresysteme beinhalten mittlerweile durchschnittlich über 3000 open-source Komponenten. Wohlgemerkt durchschnittlich. Unsere bisherige Erfahrung in der Software-Qualitäts-Analyse hat gezeigt, wie sehr Visualisierungen helfen können komplexe Sachverhalte einfach darzustellen. Also lag es nahe dies auch für die Struktur von open-source Komponenten umzusetzen.

Unser Ziel der Visualisierung ist schlussendlich eine einfache Übersicht mit Filtern und Simulationen, um Auswertung zu vereinfachen. Eine grafische Darstellung einer SBOM ist äußerst nützlich, um die Komplexität und Struktur von Software-Komponenten verständlich zu machen.

Einige Vorteile der grafischen Darstellung sind:

• Übersichtlichkeit und Klarheit durch einfache Navigation.
• Erkennung von Abhängigkeiten und Risiken.
• Einfachere Kommunikation und Zusammenarbeit.
• Grundlage für Wartung und Weiterentwicklung.

Folglich ist die Visualisierung der SBOM wie eine detaillierte Landkarte, die das Terrain der Software-Landschaft übersichtlich und verständlich darstellt. So wie eine Landkarte verschiedene geografische Elemente zeigt, wie Städte, Straßen, Flüsse und Berge, zeigt eine SBOM die verschiedenen Komponenten, Abhängigkeiten und Beziehungen innerhalb der Software. Sie erleichtert die Navigation durch die Komplexität der Software, unterstützt die Erkennung von Abhängigkeiten und Risiken und fördert die Kommunikation und Zusammenarbeit im Team.

Bei der Entwicklung und Gestaltung waren uns vorrangig die Benutzerfreundlichkeit und Übersicht wichtig. Durch viel Kommunikation zwischen Designer, Entwickler und Anwaltskanzlei haben wir versucht die Visualisierung so intuitiv wie möglich zu gestalten, um die User-Experience frustfrei zu halten.

Wir fangen hier einmal mit der Grundform an: Komponenten werden als Rechteck abgebildet, Name im Titel, Konnektor als kleiner Kreis. Wenn es sich um ein Codeschnipsel handelt, wird es als abgeschnittenes Rechteck gezeigt.

Über die Farbe des Rahmens können wir das Risiko abbilden. Die anfangs erwähnten verschiedenen Lizenztypen werden durch farbliche Umrandung nach ihrer Priorität gekennzeichnet. Dabei gehen wir nach Ampelprinzip vor.

• Rot bedeutet, dass Sie besondere Bedingungen einhalten müssen.
• Gelb bedeutet, dass Vorsicht geboten ist und eine gründliche Prüfung nötig ist.
• Grün bedeutet, dass Sie die Freiheit haben, voranzufahren und den Code nach Belieben zu nutzen.

So wie eine Ampel Ihnen hilft dieses Farbcodesystem dabei, die richtigen Entscheidungen bei der Nutzung von Software-Lizenzen zu treffen.

Weitere Informationen wie Sicherheitslücken oder Exportrestriktionen werden als Symbole links von der Komponente hervorgehoben

 

 

 

 

Weiterhin können folgende Punkte wichtig sein:

• Auswirkung auf Patente: z.b. Apache: Kann wichtig sein, wenn Firma Patente hält, oder Software und Hardware zusammen ein Produkt ergeben.
• Betriebliche Risiken: Beispielsweise eine kleine Community, wenig Updates, kein Support: Hier müssen sie entweder selbst für Support sorgen, oder nach alternativen Komponenten suchen.