Lieferketten-Risiken : Handlungsbedarf für Organisationen und Politik

Genau wie die meisten nicht-digitalen Produkte haben auch Softwareprodukte eine Lieferkette – sie sind also das Ergebnis komplexer, arbeitsteiliger Prozesse, an denen verschiedene Personen und Organisationen beteiligt sind. Dazu zählen Software-Hersteller, das Open-Source-Software-Ökosystem und Dienstleister, aber auch bestehende Softwarekomponenten, die in neue Produkte integriert werden. Außerdem sind verschiedene Stellen daran beteiligt, das Produkt zu den Nutzer:innen zu bringen, wie Distributoren, Systemintegratoren oder auch Hardware-Hersteller, die Software in ihre Produkte einbetten.

Im Unterschied zu nicht-digitalen Produkten kann sich Software auch nach dem Kaufzeitpunkt noch verändern, etwa durch Sicherheitsupdates, funktionale Upgrades oder veränderte Softwarekomponenten. Dritte, etwa Dienstleister, haben häufig Zugangsrechte zu den Systemen der Hersteller. Daher ist die Software-Lieferkette die Achillesferse digitalisierter Organisationen. Sie ist ein Einfallstor für Angreifer:innen und Quelle weiterer Risiken wie Unterbrechungen im Betriebsablauf. Deshalb sollten sich nicht nur Beschaffungsteams mit dem Lieferketten-Management von Software-Produkten befassen. Vielmehr sollte es eine zentrale Rolle im Risikomanagement jeder Organisation einnehmen.

Vier Arten von Risiken

Bei Risiken, die ihren Ursprung in der Software-Lieferkette nehmen können, unterscheide ich zwischen vier Arten: Lieferketten-Angriffe von Dritten, Innentäter:innen, unabsichtliche Fehler und mangelnder Software-Support. Entscheidend dabei ist: Nur die ersten beiden Risikotypen gehen auf Bedrohungsakteur:innen zurück. In den anderen beiden Fällen birgt die Lieferkette von Software-Produkten auch ohne Angriffsszenario Risiken.

Bei einem Angriff auf die Software-Lieferkette durch Dritte verschaffen sich Akteur:innen, die nicht Teil der Lieferkette sind, Zugang zu einer Stelle in der Lieferkette, beispielsweise zu einem Software-Hersteller oder Dienstleister. Diesen Zugang nutzen die Bedrohungsakteur:innen dann, um eine Wirkung an der Stelle zu erzielen, auf die sie es eigentlich abgesehen haben – häufig bei den Nutzer:innen. Im Unterschied dazu sind Innentäter:innen bereits Teil der Lieferkette, beispielsweise als Angestellte oder Subunternehmer eines Software-Herstellers oder Dienstleisters. Das Ergebnis solcher Kompromittierungen kann Spionage, Sabotage oder finanzieller Schaden durch Kriminelle sein.

Es gibt zwei Hauptgründe, warum Angreifer:innen ihr Ziel nicht direkt kompromittieren, sondern den Umweg über die Software-Lieferkette nehmen: Erstens haben sie es möglicherweise auf gut abgesicherte Ziele abgesehen. Ein mittelständischer IT-Dienstleister ist mutmaßlich ein leichteres Ziel als die Bundeswehr, die öffentliche Verwaltung oder ein DAX-Konzern. Zweitens können mit einem Angriff auf die Lieferkette viele Ziele gleichzeitig getroffen werden. Indem Kriminelle beispielsweise den Update-Mechanismus eines Softwareherstellers kapern, können sie Schadsoftware an alle Kund:innen des Unternehmens verschicken.

Auch ohne böse Absicht ist es ein Problem für Software-Nutzer:innen, wenn Stellen in der Software-Lieferkette unabsichtliche Fehler machen. So machte beispielsweise eine schadhafte Update-Datei des Cybersicherheitsunternehmens Crowdstrike im Jahr 2024 die Systeme all seiner Kund:innen weltweit vorübergehend unbrauchbar.

Die vierte Art von Risiken geht schließlich von mangelndem Software-Support aus, wenn also Nutzer:innen keine Sicherheitsupdates oder funktionalen Upgrades mehr erhalten.

Sowohl im Fall von unabsichtlichen Fehlern als auch von mangelndem Software-Support können Organisationen Unterbrechungen im Betriebsablauf drohen. Wenn Schwachstellen nicht mehr geschlossen werden, steigt außerdem das Risiko für Angriffe durch Dritte.

Software-Lieferketten zeigen technologische Abhängigkeiten

Gerade weil die Beziehung von Nutzer:innen zu Software-Herstellern nicht mit dem Kaufzeitpunkt endet, sondern während des Lebenszyklus des Produkts immer wieder Sicherheitsupdates bereitgestellt werden müssen, bleiben Nutzer:innen von ihren Lieferanten abhängig.

Mangelnder Software-Support kann viele Gründe haben, etwa Firmeninsolvenzen oder Maintainer:innen von Open-Source-Software, die keine Zeit mehr für ihr Hobby-Projekt finden, bis zu Sanktionen. Außerdem sind weitere politische Szenarien denkbar, in denen solche Abhängigkeiten zum Problem oder als politische Waffe eingesetzt werden können.

Gerade große Organisationen mit fest etablierten Prozessen tun sich schwer, kurzfristig auf Alternativen umzustellen, wenn Anwendungen keinen Support mehr erhalten.

Angemessenes Schutzniveau erfordert Güterabwägungen

Angesichts dieser Risiken wird in der Studie ein zweigleisiger Ansatz empfohlen, der zwar auf die Bundeswehr gemünzt ist, aber auch auf zivile Stellen wie Behörden oder Unternehmen übertragbar ist: Erstens müssen Organisationen Software-Lieferketten in ihr Risikomanagement aufnehmen, und zweitens muss die Politik Software-Hersteller stärker in die Pflicht nehmen.

Dabei gilt: Digitalisierte Organisationen können die Risiken der Software-Lieferkette nicht vollständig vermeiden. Stattdessen sollten sie ein je nach Anwendungsbereich angemessenes Schutzniveau definieren. Auf dieser Grundlage können die notwendigen Güterabwägungen getroffen werden, denn erhöhte Sicherheitsmaßnahmen bedeuten häufig höhere Kosten, eine spätere Bereitstellung und den Verzicht auf bestimmte Funktionalitäten.

Software-Lieferketten in Risikomanagement aufnehmen

Um sich vor diesen Risiken zu schützen, sollten Organisationen eine Reihe von Maßnahmen aufsetzen, um sie besser im Blick zu behalten und entsprechend reagieren zu können. Dafür müssen sie überhaupt handlungsfähig werden, also Fachexpertise zum Thema aufbauen und eine:n Zuständige:n benennen. Diese Person sollte sowohl gegenüber der Software-Beschaffung als auch dem Software-Betrieb weisungsbefugt sein. Gerade in größeren Organisationen, in denen diese Aufgaben auf viele Mitarbeitende verteilt sind, können Leitlinien zum Thema helfen. Darin sollte auch der sichere Einsatz von Open-Source-Software thematisiert werden.

Außerdem sollte sich die verantwortliche Person einen Überblick über die Risiken verschaffen. Dazu muss sie in der gesamten Organisation Prozesse aufsetzen, um verschiedene Informationen zu sammeln, etwa über die Zusammensetzung von Software und ihren Support-Status.

Anschließend sollten die Verantwortlichen Schritte zur Risikobegrenzung unternehmen. Hierzu zählt zunächst die Frage, welche Hersteller als vertrauenswürdig gelten. Organisationen, die nicht an die Beschaffungsvorgaben der öffentlichen Hand gebunden sind, haben hier mehr Freiraum. Doch auch die öffentliche Verwaltung kann Schritte unternehmen, um nicht vertrauenswürdige Hersteller von der Vergabe auszuschließen. Zudem sollten Beschaffungsverträge für Software regeln, dass Hersteller die oben genannten Informationen – idealerweise standardisiert und maschinenlesbar – bereitstellen. Darüber hinaus sollten Organisationen auch auf “Red-Teaming” setzen.

Politik muss Softwarehersteller stärker in die Pflicht nehmen

Allerdings können Anwender:innen dieses Problem nicht allein lösen und sind auf die Mitwirkung von Herstellern angewiesen. Nur sie können dafür sorgen, dass die Risiken der Software-Lieferkette bereits während der Produktentwicklung berücksichtigt und reduziert werden. Neben der Bereitstellung der oben genannten Informationen sind hier unter anderem das Schließen bekannter, ausnutzbarer Schwachstellen, die Verwendung speichersicherer Programmiersprachen, ein sicherer Build-Prozess und das Signieren von Programmcode entscheidend. Außerdem sollten Hersteller dafür sorgen, dass Open-Source-Software-Komponenten, die sie nutzen, aktiv gewartet werden.

Die seit Jahren desaströse Cybersicherheitslage zeigt jedoch, dass freiwillige Selbstverpflichtungen der Softwarebranche hier wenig Fortschritt gebracht haben. Daher ist nun die Politik gefragt: Sie muss die Anbieter von Software-Produkten stärker in die Pflicht nehmen.

Die öffentliche Verwaltung kann hier zunächst die öffentliche Beschaffung als strategischen Hebel einsetzen und entsprechende Vorgaben für den Umgang von Herstellern mit den Risiken der Software-Lieferkette machen.

Darüber hinaus sollten gesetzliche Vorgaben für Softwarehersteller entwickelt werden. Der EU Cyber Resilience Act ist ein wichtiger Schritt in diese Richtung, da er als Produktsicherheitsgesetz viele Sicherheitsvorgaben für Anbieter von „Produkten mit digitalen Elementen“ wie Software enthält. Zusätzlich braucht es jedoch ein Produkthaftungsrecht für Software, mit dem Nutzer:innen Hersteller für Schäden, die aus fehlerhaften Produkten resultieren, haftbar machen können. Eine aktuelle europäische Initiative in diesem Bereich ist ein wichtiger erster Schritt, aber unzureichend.

Kurzum: Die Risiken der Software-Lieferkette sind ein komplexes Problem, für das es keine einfache Lösung gibt. Trotzdem müssen sich Organisationen und Politik heute mit dem Thema auseinandersetzen, wenn sie nicht morgen die potenziell verheerenden Konsequenzen tragen möchten.

Alexandra Paulus ist Wissenschaftlerin für Cybersicherheit und neue Technologien bei der Stiftung Wissenschaft und Politik (SWP) und leitet dort außerdem das Forschungscluster Cybersicherheit und Digitalpolitik. Sie beschäftigt sich mit Fragen an der Schnittstelle von Technologie-, Außen- und Sicherheitspolitik.