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.

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.

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.

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.

Das könnte Sie auch interessieren

Treffsichere Prozessanalysen in Zeiten des Wandels Wie kausales Process-Mining eine schnelle Anbindung ermöglicht

Die grundlegenden Techniken des Process-Mining wurden vor etwa 20 Jahren entwickelt. Ziel war es, mithilfe von Daten aus transaktionalen Systemen detaillierte Analyseergebnisse zu Prozessen zu erlangen [1]. Process-Mining stellte damit einen Gegenentwurf zu zeitaufwändigen, ungenauen Prozesserhebungen mit Interviews und Workshops dar. Um den Austausch von Prozessdaten für die Forschung zu erleichtern, entwickelten Forscher aus der Gruppe von Prof. Dr. Wil van der Aalst an der TU Eindhoven ein XML-Format für Event-Logs. Die Idee war, dass Process-Mining-Werkzeuge dieses Format als Importschnittstelle unterstützen. Nun konnten Unternehmen aus ihren Systemen Prozessdaten in eine Datei in diesem Format transformieren und diese Datei an Projektpartner weiterreichen, um Process-Mining-Techniken darauf anzuwenden. Einige anonymisierte Dateien wurden auch für Forschungszwecke veröffentlicht, was die Forschung in diesem Bereich beflügelte. So dienlich wie Dateiformate für Event-Logs ...

Etablierung von Low-Code/No-Code in Organisationen Technologie allein reicht nicht: Erfolg braucht mehr als die richtige Plattform

Low-Code/No-Code verspricht Entwicklung, Innovation und eine engere Zusammenarbeit zwischen Fachbereichen und IT. Doch warum scheitern viele Initiativen daran, sich dauerhaft im Unternehmen zu etablieren? Der Beitrag zeigt, welche organisatorischen, strategischen und operativen Voraussetzungen entscheidend sind, und stellt acht zentrale Handlungsbereiche mit Erfolgsfaktoren vor – als praxisnahen Leitfaden für eine nachhaltige LCNC-Einführung.

Datenmüll kostet Geld Warum Stammdatenqualität zur Führungsaufgabe wird

Datenqualität ist kein IT-Aufräumprojekt. Sie ist eine Führungsaufgabe. Wer ein ERP-System einführen oder KI produktiv nutzen will, muss zuerst klären, welche gemeinsame Wahrheit das Unternehmen verwendet. Schlechte Grunddaten bremsen ERP-Projekte, schwächen Entscheidungen und verhindern produktive KI-Nutzung. Dieser Beitrag erläutert, was Geschäftsführungen im Mittelstand jetzt tun müssen un warum Stammdatenqualität zur Führungsaufgabe wird.

Großhandel, Götter und Grundsätze der Buchführung Warum Pacioli, Zeus und ein ERP-Award besser zusammenpassen, als man denkt

Was verbindet Pacioli, Zeus und einen ERP-Wettbewerb und macht sie zu einer relevanten Quelle für strategische Führungsimpulse? Zwischen Renaissance, Antike und der modernen ERP-Welt gibt es überraschend klare Parallelen. Wer erkennt, warum Venedig, Triest, Kotor und Olympia mehr als nur historische Fußnoten sind, gewinnt neue Perspektiven auf Steuerung, Risiko und Timing unter Wettbewerbsdruck. Setzen Sie Akzente mit fundierten Perspektiven.

Die Zukunft der ERP-Systeme Strategisch statt operativ: ERP etabliert sich als Top-Management-Thema

ERP ist längst Chefsache. Wer es weiterhin als reines IT-Thema einordnet, unterschätzt seinen strategischen Hebel. Vorausschauende Unternehmen verankern ERP-Kompetenz in ihrer Governance und nutzen sie als Wettbewerbsvorteil. Moderne ERP-Systeme entwickeln sich zu intelligenten, offenen Architekturen –getrieben von Cloud, KI und Automatisierung. Das verlangt von der Unternehmensführung ein tiefes Verständnis von ERP.

Digitale Geschäftsprozesse im Mehrwegbehältermanagement Technologien und Applikationen für effiziente digitale Mehrwegkreisläufe

Mehrwegkreisläufe effizient zu steuern ist komplex – doch neue digitale Technologien eröffnen ganz neue Möglichkeiten. Der Artikel zeigt, wie No-Code-Development, Computer Vision und IoT-Architekturen das operative Mehrwegbehältermanagement automatisieren und manuelle Prozesse deutlich reduzieren. Praxisnahe Beispiele aus dem Projekt DIBCO geben spannende Einblicke, wie Unternehmen ihre Behälteraufbereitung effizienter und zukunftsfähig gestalten können.