Am 11.12.2024 hatte ich die Ehre, eine Podiumsdiskussion im GovTech-Campus Berlin zum Thema geopolitische Resilienz zu moderieren. Mit mir auf der Bühne waren Jutta Horstmann vom Zendis, Michael Neuber von Google und der Autor und Geotechnik-Experte Ansgar Baums.
Technologie als Mittel der Geopolitik im 21. Jahrhundert
Der Begriff „Geotechnik“ war mir in dieser Form neu, er beschreibt die Schnittstelle von Geopolitik und Technologie. Die Forschungsfrage des Tages lautete entsprechend: Welche Möglichkeiten haben Staaten bei der Gestaltung von geopolitischer Resilienz?
Die Antwort schien einfach: Unternehmen müssen ihre Wertschöpfungskette besser verstehen, egal, ob es um Hardware oder Software geht. Welche Disruptionen auch nur ein fehlender Chip im Wert von 10ct haben kann, zeigten die Lieferkrisen im Jahr 2021: VW musste seine Fabriken drosseln, Toyota und Stellantis senkten ebenfalls die Produktionsprognosen.
Ursache dieser Krise war eine Melange aus Pandemie, Naturkatastrophen und dem Halbleiter-typischen Schweinezyklus. Was aber würde sich ändern, wenn es sich um gewollte Schocks politischer Akteure handelte? Wenn China oder die USA ihre technologische Macht gezielt für ihre eigenen Zwecke einsetzten? Und was wäre, wenn es nicht nur um Hardware, sondern auch um Software ginge?
Die Nachrichtenlage zeigt, dass auch die Software-Wertschöpfungskette nicht immun gegen Angriffe ist:
Die Attacke Israels auf die Kommunikationsgeräte der Hisbollah zeigte das wohl bisher realste Muster einer solchen Attacke. In der Pager-Hardware war nicht nur Sprengstoff versteckt, sondern auch eine fernsteuerbare Software installiert. Mittels einer verschlüsselten Nachricht und entsprechender Software auf dem Pager, konnten die Geräte zur Explosion gebracht werden. In der Software-Branche sind über Fernzugriff aktivierbare Features relativ üblich. Manchmal heißen sie „Feature Toggles“, manchmal makaberer Weise „Kill Switches“.
Die “Bill of Materials” als Basis
Ansgar Baums sprach über BOMs – die „Bills of Materials“. Sie sind eine Art Stückliste aller verwendeten Komponenten für die Produktion von Hard- oder Software. Große Digitalunternehmen mit Rechenzentren kommen auf etwa 50.000 unterschiedliche Teile. Dabei machte er in seinen Anforderungen keine größere Unterscheidung zwischen Hard- und Software: „Um deine geopolitische Resilienz zu verbessern, musst Du deine gesamte Wertschöpfungskette kennen.“
Auf der Bühne ging die Diskussion weiter, aber innerlich dachte ich: „Guter Punkt, wie sieht eine Software-BOM eigentlich aus?“. Nach dem Event befragte ich dazu meine Kollegen Sujay Joshy und Marcel Gocke.
Die eigene Software von Innen betrachten
Gehen wir einmal davon aus, dass wir als Unternehmen eine Anwendung entwickeln und betreiben wollen, die Röntgenbilder auf Anzeichen von Lungenkrebs analysiert. Die inneren Abhängigkeiten unserer Software könnten dann in etwa wie folgt aussehen:
Software besteht in der Regel aus einer Sammlung von Funktionen, Methoden oder Klassen, die sich gegenseitig aufrufen. Das Bild zeigt die Funktionen als Punkte, die Linien stellen deren Aufrufe untereinander dar.
Bei der Abbildung 3 handelt es sich um die reale Darstellung einer Software mit deren internen Abhängigkeiten. Allerdings zeigt sie lediglich den selbst entwickelten Anteil unserer Anwendung.
IT-Infrastruktur und Software-Komponenten wie Datenbanken
Damit eine Software zuverlässig funktioniert, benötigt sie aber IT-Infrastruktur, wie Speicherplatz, Rechenleistung und Netzwerk, sowie weitere Komponenten wie Datenbanken, Monitoring- und Logging-Tools oder Identity- und Access-Management-Services. Jedes dieser Elemente enthält selbst Software oder besteht aus Software.
SDKs und Libraries
Bei der Erstellung der Software verwenden die EntwicklerInnen sogenannte ‚Software Development Kits (SDKs)‘. Hierbei handelt es sich um Werkzeuge und -Ressourcen, die ihnen helfen, besser und einfacher für bestimmte Plattformen, Betriebssysteme oder Programmiersprachen zu entwickeln. So gibt es zum Beispiel für Android-Telefone das ‚Android SDK‘, für die Microsoft-Desktop-Version das ‚Windows SDK‘ und für die Nutzung von IT-Infrastruktur auf der Public Cloud das ‚AWS Cloud Development Kit‘.
Zudem nutzen EntwicklerInnen sogenannte ‚Libraries‘. Diese Bibliotheken sorgen bei unserer Lungenkrebs-Anwendung dafür, dass wir allgemeine Features nicht neu entwickeln müssen. Bekannte Beispiele für große Library-Frameworks sind:
- React: Eine JavaScript-Bibliothek zur Erstellung von Benutzeroberflächen, entwickelt von Facebook. Es ermöglicht EntwicklerInnen, wiederverwendbare User-Interface-Komponenten zu erstellen und effizient auszuspielen.
- TensorFlow: Eine Open-Source-Bibliothek für maschinelles Lernen und künstliche Intelligenz, entwickelt von Google. Sie wird häufig für die Entwicklung und das Training von neuronalen Netzen verwendet.
Libraries wiederum werden nicht nur von uns selbst eingebunden, auch SDKs und alle anderen Komponenten der ersten Linie unserer Software Bill-of-Materials (SBOM) verwenden sie. Ich habe keine genauen Zahlen zur Menge der Libraries und SDKs dieser Welt gefunden, mehrere 10.000 aber werden es sein. Viele davon sind Open-Source, einige davon sind aufgrund von Sicherheitsvorfällen berühmt geworden. Beispiele hierfür sind Log4j und XZ utils. Aufgrund ihrer Relevanz für die globale Software-Wirtschaft fördert die Sovereign Tech Agency etwa 30 dieser Libraries pro Jahr.
Tensorflow als Beispiel einer Library
Infrastruktur, Middleware-Komponenten, SDKs und Libraries sind im Wesentlichen Software. Wie auch unsere eigene Anwendungen in Abbildung 3, bringen diese eigene, innere Abhängigkeiten mit. Möchten wir also wirklich sicherstellen, dass unserer Software-Bill-of-Materials nicht gestört oder manipuliert wird, müssen wir diese inneren Zusammenhänge verstehen. Die Abbildung zeigt beispielhaft Tensorflow und dessen Abhängigkeitsnetzwerk.
Das Beispiel Tensorflow zeigt, dass jede eingebundene Bibliothek für sich eine hohe Komplexität mitbringen kann. Abbildung 7 zeigt einen größeren Ausschnitt der Software mit ihren 4183 Knoten (Klassen, Methoden, APIs, Funktionen) und 24370 Verbindungen.
Die Stückliste ist ein Universum
Die Stückliste unserer fertigen Anwendung zur Erkennung von Lungenkrebs können Sie sich also in etwa vorstellen wie die folgende Abbildung.
Nun hat unser Entwicklungsteam das AWS SDK verwendet, um die Software auch auf AWS zu betreiben. Wir haben uns für diesen Cloud-Betreiber entschieden, weil er eine umfassende Auswahl an IT-Services mitbringt und diese sehr ausfallsicher betreibt. Dort finden wir alle notwendigen Komponenten, die wir benötigen und können sie einfach einbinden: Rechenleistung, Netzwerk, Speicher und Datenbanken.
Allerdings: AWS selbst besteht im Wesentlichen aus Software. Zwar benötigt das Unternehmen auch Hardware (Rechenzentren, Server, Kabel und Kühlung), die Mehrzahl der Beschäftigen des Hyperscalers beschäftigen sich aber mit Entwicklung, Pflege und Verkauf von Software. Mit einer Entscheidung für einen bestimmten Cloud-Provider binden wir in unser eigenes Universum an Software auch noch die für den Betrieb des Cloud-Providers notwendige Software in unsere SBOM ein.
Cloud-Provider in diesem Sinne sind nicht nur die drei großen Hyperscaler AWS, Google und Microsoft. Cloud-Provider ist jeder einzelne externe Service, den irgendwer in meinem Universum entscheidet, einzubinden. Paypal beispielsweise ist mit wenigen Zeilen Code in jeden Bezahlprozess integrierbar. Aber Paypal ist ein Software-Service, der Komponenten und IT-Infrastruktur benötigt, Libraries und SDKs nutzt, Hyperscaler oder Private Clouds nutzt und bei seiner internen Leistungsverrechnung wahrscheinlich auf SAP-Services angewiesen ist.
Jedes Stück Code gibt es in vielen Versionen
Eine weitere Komplexitäts-Stufe habe ich noch nicht erwähnt: Wenn Software-EntwicklerInnen Libraries benutzen, werden diese im Build-Prozess gemeinsam mit dem eigenen Code zu einem lauffähigen Stück Software zusammengeführt. Dabei nutzen die EntwicklerInnen oft eine zu diesem Zeitpunkt aktuelle Version dieser Library. Wenn die finale lauffähige Software dann auf die IT-Infrastruktur aufgespielt und von den internen oder externen Kunden verwendet wird, sind die Bibliotheken häufig nicht mehr auf dem aktuellen Stand. Zudem werden die Libraries meist häufiger aktualisiert als die Softwares, welche sie verwenden. Entsprechend ist viel Software im Umlauf, die aktuell scheint, aber veraltete und unsichere Zulieferteile enthält.
Potentiell unsichere Varianten kann es viele geben. Github führt alleine für unsere Tensorflow-Library seit deren Entstehung insgesamt 174832 Commits. Jeder Commit bedeutet eine Änderung am Quellcode. Jeder dieser Änderungen könnte eine Schwachstelle beseitigt oder erzeugt haben.
Zusätzlich legen sich EntwickelrInnen sogenannte Branches an. Sie kopieren den Original-Softwarecode und führen diesen in einem eigenen Projekt weiter. Auf diese Weise können sie, unabhängig vom Original, die Software ohne viel Abstimmung mit der Community für eigene Zwecke anpassen. Bei Tensorflow gab es auf Github am 19.01.2025 insgesamt 5827 Branches.
Software-Wertschöpfung funktioniert irgendwie anders
Weder Sujay, Marcel noch ich sind Experten für Hardware-Wertschöpfungsketten. Bekannt aber sind jene Geschichten von VW-Vorständen, die sich wie Besessene für Spaltmaße interessieren. Spaltmaße, das sind die Abstände zwischen zwei Autotüren. Wenn diese am Dach den gleichen Abstand vorweisen wie in Bodennähe, dann ist das ein Zeichen dafür, dass die komplette Kette vom Zulieferer bis zum Monteur auf einen Nanometer genau gearbeitet hat. Wenn dies nicht gelingt, wird mit der Ishikawa-Methode akribisch die Kernursache gesucht. Sobald gefunden, werden zuverlässige Lösungen implementiert und das Problem wird an der Quelle beseitigt. Zulieferer erhalten Qualitätsziele, die bei 25 PPM liegen – also nur 25 Defekte auf 1.000.000 Teile (Parts per Million) erlauben. Auf Hardware-Ebene bewegt sich Audi engagiert auf die Zero PPM zu.
Die Geschichten aus der Software-Branche wiederum klingen anders:
- Solarwinds: Russische Hacker infizierten SolarWinds-Software-Updates mit Malware, die sich in Tausende von Unternehmen und Regierungsbehörden weltweit verbreitete.
- Log4j: Eine kritische Sicherheitslücke in der weit verbreiteten Java-Logging-Bibliothek Log4j ermöglichte Angreifern die Ausführung von Schadcode auf verwundbaren Systemen.
- XZ Utils: In der beliebten Linux-Kompressionsbibliothek XZ Utils wurde eine Hintertür entdeckt, die potenziell unbefugten Zugriff auf betroffene Systeme ermöglichte.
- Crowdstrike: Ein fehlerhaftes Software-Update für CrowdStrikes Falcon-Sicherheitssoftware verursachte weltweit Systemabstürze und Ausfälle bei Millionen von Windows-Computern
Unternehmen erhalten täglich tausende Meldungen über neue Sicherheitslücken. Im besten Fall versucht dann jemand herauszufinden, ob die eigene Software von genau diesem Problem in dieser Library in dieser Version betroffen ist. Wahrscheinlich aber passiert erst mal lange nichts.
Wer will das Universum kontrollieren?
Wer ernsthaft versucht, im Universum der Software-Ökonomie jede Kernursache zu finden und zu beseitigen, der wird seine Organisation paralysieren. Denn einzelne Unternehmen können nur einen sehr geringen Teil ihrer Software-Wertschöpfungskette selbst überblicken und beeinflussen. Ein noch geringerer Teil davon ist im eigenen Haus programmiert. Die SBOM zu kontrollieren, um Fehler zu vermeiden, ist (aus der Perspektive der Einzelorganisation) in etwa so erfolgversprechend, wie ein Versuch Catanias, den Ausbruch des Ätnas zu verhindern.
Wie die Sizilianer aber gelernt haben, mit dem ständigen Brodeln ihres Berges umzugehen, so können auch Unternehmen mit den immer wiederkehrenden Schocks in ihrer Software-Wertschöpfung umgehen. Wie so etwas ungefähr aussieht, hat die EU der Finanzwirtschaft mit Hilfe des Digital Operational Resilience Act (DORA) in ihr Pflichtenheft geschrieben:
- ICT-Risikomanagement: Unternehmen müssen einen umfassenden Rahmen für das Management von IT-Risiken etablieren.
- Vorfallmanagement und -meldung: Es müssen klare Prozesse für die Erkennung, Meldung und Bewältigung von IT-Vorfällen implementiert werden.
- Digitale Resilienz-Tests: Regelmäßige Tests zur Überprüfung der Widerstandsfähigkeit gegen Cyberangriffe und Systemausfälle sind vorgeschrieben.
- Management von Drittanbieter-Risiken: Risiken im Zusammenhang mit IT-Dienstleistern müssen identifiziert und gesteuert werden.
- Informations- und Erkenntnisaustausch: Förderung des Austauschs von Bedrohungsinformationen zwischen Finanzinstituten.
Auch können Unternehmen ihre Softwares automatisiert nach bekannten Fehlern und gefährlichen Abhängigkeiten durchsuchen. Zudem gibt es Wege, schnell und automatisiert Updates einzuspielen. Dennoch bleibt der Anteil der SBOM, den wir auf diese Weise kontrollieren können, sehr gering.
Im Grunde müssen Unternehmen ihre Haltung an die Realität anpassen, die ihnen das Software-Universum vorgibt. Weil echte Kontrolle nicht möglich ist, müssen sie einerseits lernen auf regelmäßige Störungen zu reagieren. Noch besser aber ist es, wenn sie am ständigen Stress und Chaos wachsen. Wenn sie es als einen olympischen Wettbewerb sehen, für den sie ihre Muskeln trainieren, Trainingsmethoden verbessern und neue Team-Taktiken entwickeln. Das aktuelle Buzzword dazu ist: Anti-Fragile. Aber das wiederum ist einen eigenen Artikel wert.
Können denn wenigstens Staaten Software kontrollieren?
Unternehmen also müssen dauerhaft mit den in der Einleitung genannten Gefahren von Hacks, Bugs und drohenden Software-Boykotten leben. Aber können nicht wenigsten Staaten oder Staatenverbünde wie die EU das Problem in den Griff bekommen?
Im Artikel „Macht Open Source souverän oder autark“ habe ich die Gesamtanzahl relevanter Softwares dieser Welt auf etwa 13 Millionen geschätzt. Darin stecken vermutlich ~350 Millionen kumulierte Personenjahre Entwicklungsleistung. In Europa könnten in etwa 7 Millionen Software-EntwicklerInnen an deren Absicherung arbeiten. Selbst diese es versuchten, kämen sie für ein Großteil der Anwendungen nicht an den Closed-Source-Quellcode heran. Bei etwa 1,5 Millionen dieser Softwares ginge es, diese sind Open-Source. Dieser Aufgabe hat sich die deutsche Sovereign Tech Agency angenommen, mit etwa 24 Millionen € Budget gelingt es ihr pro Jahr, etwa 30 davon zu fördern und abzusichern.
Wer die genannten Zahlen überschlägt, wird wohl zu dem Schluss kommen, dass selbst Deutschland und die EU unsere Software-Wertschöpfungskette nicht wirklich absichern, geschweige denn kontrollieren können. Dennoch glaube ich, wir können mehr tun, als es scheint. Was genau? Das versuchen wir in den nächsten Artikeln und Interviews herauszufinden.
