Umfassende Einsicht in den Softwarecode

Compliance beginnt auf Code-Ebene. Wer Software nutzt oder in seine Produkte integriert, sollte umfangreich dokumentieren, was in den Anwendungen steckt und welche Lizenzen und Sicherheitsrisiken mit ihnen verbunden sind. Das Management von Open Source Software (OSS) setzt dabei auf Analysetools und Prozesse rund um Software Composition Analyse (SCA).

Entwickler nutzen vermehrt Open Source Software (OSS)-Komponenten: tatsächlich liegt der Anteil von OSS in heutigen Anwendungen bei 80-90%. Das Zurückgreifen auf externen OSS-Code verleiht der Softwareentwicklung Geschwindigkeit und Effizienz, jedoch unterliegen die Komponenten nicht immer denselben Kontrollen und Sicherheitstests wie der im eigenen Entwicklerteam erstellte Code. Entlang der Software Supply Chain mangelt es an Dokumentation und Herkunft, so sind Version, Inhalt und Lizenzierung der Codebausteine oft unklar.

Abb. 01 Revenera Software Supply Chain — *Abb. 01: Software Supply Chain und ihre vielen Bestandteile, Codequellen und Lieferanten (Quelle: Revenera)*

Im Rahmen einer Open Source License Compliance Studie von 2021 wurden innerhalb von 2,6 Milliarden Codezeilen insgesamt 230.000 Compliance-Verstöße oder Softwareschwachstellen gefunden [1]. Was dabei überrascht: Die Mehrheit (83%) der aufgedeckten Risiken war den Entwickler-, Sicherheits- und Compliance-Teams der Unternehmen im Vorfeld der Untersuchung nicht einmal bekannt.

Risikofaktor Nummer Eins: Schwachstellen

Einmal verbaut in den Softwarecode ist die Sicherheit einzelner OSS-Komponenten nur noch schwer zu garantieren. Sicherheitsteams verlieren kostbare Zeit, wenn sie nach Aufdeckung einer neuen Schwachstelle zunächst ihren gesamten Softwarecode scannen müssen, um zu wissen, ob sie überhaupt von dem aktuellen Vorfall betroffen sind.

Ein prominentes Beispiel dafür ist Log4Shell. Die Zero-Day-Sicherheitslücke befand sich in der Java-Logging-Bibliothek Log4j, die in unzähligen Anwendungen zum Einsatz kommt. Was die Schwachstelle besonders gefährlich machte, war unter anderem, dass Hacker sich Zugang zu einem Computer verschaffen konnten. Problematisch war auch, dass viele Unternehmen das Sicherheitsrisiko der Schwachstelle für ihre eigenen Produkte nicht genau oder erst nach geraumer Zeit abschätzen konnten.

Abb. 02 Revenera Log4Shell — *Abb. 02: Schwachstellen finden den Weg in die Unternehmens-IT über mehrere Wege (Quelle: Revenera)*

Risikofaktor Nummer Zwei: Compliance-Verstöße

Unkontrollierte und undokumentierte OSS-Nutzung stellt zudem ein Compliance-Risiko dar. Die freie Verfügbarkeit von Open Source entbindet den Nutzer nicht von jeglichen Verpflichtungen: Viele Autoren im OSS-Umfeld knüpfen die Wiederverwendung ihres Codes an Bedingungen, deren Auslegung manchmal unklar sein kann. Die Lizenzen können sich ändern und oft fehlen Angaben auch gänzlich. Trotzdem müssen Unternehmen die Compliance-Vorgaben erfüllen.

Ein gutes Beispiel ist die General Public License: Entwickler können GPL-lizenzierten Quellcode kostenfrei verwenden, alle darauf basierenden Weiterentwicklungen fallen jedoch automatisch unter die gleiche Lizenz und müssen frei verfügbar bleiben. Für Unternehmen ist diese Offenlegung problematisch. Der Autohersteller BMW musste in einem besonders unschönen Fall sogar Teile seiner Fahrzeugsoftware veröffentlichen, da der Quellcode der verwendeten OSS mit einer GPL-Lizenz versehen war [2].

Wachsende regulatorische Anforderungen

Der wachsende Einsatz von KI bzw. GenAI in der Softwareentwicklung verschärft das Problem. KI-Modelle greifen beim Training ebenfalls im großen Maße auf Open Source-Repositories zurück. Das treibt das Tempo in der Entwicklung zwar weiter voran, die Rückverfolgbarkeit der Komponenten über die gesamte Software Supply Chain verkompliziert sich jedoch weiter. Entwickler, die Tools wie Github Copilot nutzen, erhalten zwar „verbau fertige“ Codeschnipsel, allerdings oft ohne Nutzungsbedingungen.

Der Gesetzgeber sowie verschiedene Organisationen und Branchenverbände haben in den letzten Jahren nicht nur Best Practices und Empfehlungen, sondern auch konkrete Richtlinien und Mindestanforderungen aufgestellt (Abb. 4). Ein allgemein verpflichtendes Gesetz hinsichtlich OSS-Nutzung gibt es bis jetzt noch nicht.

Fünf Eckpunkte von Software Composition Analysis

Eine Methode, um Risiken im Zusammenhang mit OSS-Nutzung und Drittanbieter-Komponenten zu identifizieren und zu minimieren, ist Software Composition Analysis (SCA). Der präventive Ansatz ist Teil von einer Application-Security und umfasst diverse Ansätze und Best Practices. Ziel von SCA ist es, sowohl den Softwareentwicklungsprozess als auch die Software Supply Chain sicherer zu machen.

1. Software-Bill of Materials (SBOM)
Ein zentrales Element von SCA ist die Software Bill of Materials (SBOM). Die Stückliste liefert eine detaillierte Übersicht aller Top-Level- und Sub-Komponenten einer Anwendung, sowie deren direkte und transitive Abhängigkeiten. Dabei enthält die SBOM nicht nur Informationen aus der eigenen Entwicklungsarbeit, sondern auch Stücklisten von Upstream-Partnern und Drittanbietern sowie Daten aus SCA-Scans, Open Source Software-Libraries und anderen Data Services.

Aufgrund ihrer Komplexität lassen sich Stücklisten manuell kaum noch erstellen. Entsprechende Lösungen aggregieren die unterschiedlichen Daten automatisch und fassen sie in einem einheitlichen Format zusammen. Als Standards haben sich hier in den letzten Jahren SPDX (Software Package Data eXchange), sowie CycloneDX etabliert. Darüber hinaus finden sich konkrete SBOM-Mindestanforderungen, die unter anderem die auszufüllenden Datenfelder betreffen.

Abb. 03 Revenera SBOM 1 — Abb. 03: SBOMs müssen kontinuierlich überprüft, optimiert und überwacht werden. (Quelle: Revenera)

2. Software Vulnerability Management
SBOMs geben nur bedingt Auskunft über die Sicherheit einer Anwendung. Deshalb werden die Stücklisten häufig um Dokumentations-Ansätze wie Vulnerability Disclosure Report (VDR) und Vulnerability Exploitability eXchange (VEX) ergänzt, die eine Momentaufnahme der aktuellen Sicherheitslage liefern. Querverweise zur SBOM und den darin aufgelisteten Code-Komponenten helfen, eine zentrale Sicht auf alle Risiken zu gewinnen.

Der Abgleich mit einschlägigen Datenbanken (z. B. National Vulnerability Database, NVD) klärt, wie hoch das Risikolevel der Schwachstelle ist. Die bei OSS oft gestellte Frage, ob die eigene Anwendung überhaupt von einer Sicherheitslücke betroffen ist, lässt sich so deutlich schneller beantworten.

3. Security-by-Design & Shift-Left
SCA umfasst zwei grundsätzlichen Sicherheitsansätzen: Security by Design und Shift-Left. Security by Design verankert Sicherheit in der gesamten Architektur eines Systems. Verschlüsselung, Zugangskontrollen und Schwachstellenmanagement sind von Anfang an miteingeplant. Shift-Left bezieht sich auf die Verlagerung von Sicherheitsmaßnahmen und Tests zu Beginn des Software-Entwicklungszyklus (SDLC). Um Sicherheitslücken so früh wie möglich zu erkennen, wird der Code wiederholt getestet.

4. Open Source Tracking & Analyse
Die Analyse von Softwarekomponenten läuft kontinuierlich ab. Automatisierte Tracking- und Analysetools sind in der Lage, die Komponenten einer Anwendung zu identifizieren und aufzuschlüsseln – egal ob sie aus dem Unternehmen selbst oder aus externen Quellen stammen. Ziel ist eine lückenlose Nachverfolgung aller OSS-Komponenten. Dazu gehören auch am Code vorgenommene Änderungen. Die Analyse hilft Entwicklern, die Nutzung von OSS ordnungsgemäß zu dokumentieren und gemäß der Lizenzbestimmungen entlang der Software Supply Chain weiterzureichen.

5. Dedizierte OSPO-Teams
OSS-Compliance und -Sicherheit ist ein essenzieller Part, bei weitem aber nicht die Kernaufgabe von Entwicklern. Unternehmen sollten daher dedizierte Teams aufbauen: Das Open Source Program Office (OSPO) entwickelt eine unternehmensweite Open Source-Strategie und setzt diese durch. Zudem kümmert es sich um die kontinuierliche Optimierung der Richtlinien und Prozesse. Training und Fortbildungen sind ausschlaggebend, um das Bewusstsein der Mitarbeitenden zu schärfen. Die verantwortlichen Teams erhalten dabei Unterstützung durch die Open Source Community und Arbeitsgruppen wie SPDX, CISA und OpenChain.

Softwareentwicklung ohne Open Source Software ist heute kaum noch denkbar. Bei allen strategischen Vorteilen von OSS, braucht es ebenfalls automatisierte Prozesse und Lösungen, um die Nutzung nachvollziehen und das Compliance- und Sicherheitsrisiko minimieren zu können. Open Source Management gehört damit auf den Pflichtzettel für jedes Unternehmen.