Im weitesten Sinne gehört zu einer Lieferkette alles, was zur Herstellung und Lieferung eines Produkts an den Endverbraucher erforderlich ist. Bei einer Softwarelieferkette verhält es sich nicht anders – der einzige Unterschied besteht darin, dass sie sich auf Code und Anwendungen sowie auf alles bezieht, was mit deren Entwicklung und Bereitstellung zu tun hat.
Genauso wie ein Automobilhersteller über ein breites Netzwerk von Zulieferern und Teilen verfügt, kann ein Softwarehersteller auf eine komplexe Vielfalt von Code, Tools und Ressourcen angewiesen sein, um sein Produkt zu entwickeln. Das zentrale Problem: Ein Fehler oder eine Schwachstelle irgendwo in der Lieferkette wirken sich potenziell auf jede Einheit weiter unten in der Kette aus (oft als „nachgelagert“ beziehungsweise „downstream“ bezeichnet).
Kein neues Problem innerhalb der Lieferkette. Warum aber ist es gerade für die Softwarebranche so brennend aktuell?
Zusammensetzen statt aufbauen
Im Zuge der digitalen Transformation sind wir mehr denn je auf Technologie angewiesen, geschäftlich wie privat. Das hat unter den Technologieunternehmen zu einem harten Wettbewerb geführt, was die Markteinführung neuer Produkte anbelangt.
Folglich konzentrieren sich diese Firmen mehr auf Innovationen , die ihre Produkte von anderen abheben, und weniger darauf, „das Rad neu zu erfinden“. Mit anderen Worten: Software wird nicht mehr gebaut, sondern zusammengesetzt – jedes Teil stammt aus unterschiedlichen Quellen. Ressourcen, die sich auf die Herstellung genau dieses Teils spezialisiert haben.
Ein E-Commerce-Unternehmen verschwendet zum Beispiel keine Zeit mehr mit dem Aufbau einer Datenbank, ein Online-Bankinstitut keine Zeit mit dem Aufbau von Tools für die Benutzeroberfläche und ein IoT-Unternehmen wird kein eigenes Betriebssystem entwickeln. Stattdessen wenden sich alle an Dritte, an Open Source-Projekte und Anbieter.
Tatsächlich bestätigt der jüngste Open-Source-Security-&-Risk-Analysis-Bericht (OSSRA-Bericht), dass durchschnittlich 97 Prozent aller Software zumindest teilweise Open-Source-Code enthält. In 4 der 17 im Bericht vertretenen Branchen (Computerhardware und Halbleiter, Cybersicherheit, Energie und Clean Tech sowie Internet der Dinge) sind sogar 100 Prozent der geprüften Codebasen Open-Source-basiert.
In den übrigen Branchen beläuft sich der Anteil an Open Source auf 93 Prozent bis 99 Prozent aller geprüften Codebasen. Selbst in den Bereichen mit dem niedrigsten Prozentanteil (das sind Gesundheitswesen, Health Tech und die Biowissenschaften), ist der Anteil mit 93 Prozent immer noch sehr hoch. Open Source ist schlicht omnipräsent.
Problem beginnt innerhalb der Open-Source-Komponente
Aber was passiert, wenn eine Open-Source-Komponente eine Schwachstelle aufweist? Oder wurde vielleicht das Konto eines Community-Mitglieds gehackt und möglicherweise Schad-Code eingefügt? Das würde etwa bedeuten, dass IoT-Unternehmen ein Betriebssystem mit einer kritischen Schwachstelle verwenden – man denke an gehackte intelligente Thermostate oder WiFi-Kameras.
Das Problem beginnt innerhalb der Open-Source-Komponente. Die wurde von einer IoT-Firma in das betreffende Produkt implementiert, das Produkt an den Endbenutzer verkauft, und der schließlich angegriffen. Hier liegt das eigentliche Problem innerhalb der Softwarelieferkette.
Laut den Ergebnissen des OSSRA-Berichtes von 2022 enthalten 100 Prozent der Codebasen im IoT-Sektor Open Source, und erstaunliche 92 Prozent des geprüften Codes in diesem Sektor sind Open Source. Nicht weniger beunruhigend: Auch 64 Prozent der IoT-Codebasen weisen Schwachstellen auf.
Auch in den Branchen Luft- und Raumfahrt, Automobilbau, Transport und Logistik sind 97 Prozent der Codebasen Open Source, und 60 Prozent des gesamten Codes besteht aus Open Source, und ebenfalls sechzig Prozent der Codebasen enthalten Open Source-Schwachstellen.
Zwei der jüngsten Beispiele für schwerwiegende Probleme in der Softwarelieferkette:
SolarWinds
Vielleicht einer der, wenn nicht sogar der bemerkenswerteste, Angriff auf die Softwarelieferkette. Ein internes Passwort wurde online geleakt, und von Angreifern verwendet, um sich Zugang zu den Build-Systemen von SolarWinds zu verschaffen. An dieser Stelle startete die Attacke. Die Angreifer fügten bösartigen Code in eine kommende Version von Orion ein, dem Flaggschiffprodukt von SolarWinds.
Dieser bösartige Code blieb unentdeckt, wurde in die Artefakte der Produktversion eingebaut und vielfach an Kunden ausgeliefert. Mit dieser Version diente Orion den Angreifern als Portal, um SolarWinds-Kunden zu infiltrieren. Zu diesen Kunden zählten unter anderem mehrere US-Bundesbehörden. Die Tatsache, dass der ursprüngliche Angriff mehrere Stufen vom beabsichtigten Ziel entfernt stattfand, macht ihn zu einem Paradebeispiel für einen Lieferkettenangriff. Dieser und weitere ähnlich gelagerte Angriffe auf kritische Infrastrukturen, trugen erheblich dazu bei, dass US-Präsident Biden seine Cybersecurity Executive Order veröffentlichte.
Log4Shell
Es gab zwar keine [bestätigten] erfolgreichen Angriffe, bei die Schwachstelle ausgenutzt wurde, aber sie ist dennoch ein gutes Beispiel für die möglichen Auswirkungen einer solchen Sicherheitslücke auf die gesamte Lieferkette. Apache Log4J ist ein äußerst beliebtes Java-Protokollierungsframework. Es arbeitet im Hintergrund von Anwendungen, mit denen unzählige Unternehmen und Endverbraucher täglich interagieren. Im Dezember 2021 wurde eine schwerwiegende Zero-Day-Schwachstelle in mehreren Versionen bekannt. Alle geeignet, sich für Remote-Angriffe ausnutzen zu lassen, und um sich als Angreifer Zugang zu betrieblichen Servern zu verschaffen.
Hätten die Angreifer diese Schwachstelle zuerst entdeckt, wären die Auswirkungen so verheerend wie weitreichend. Dies zeigt, wie sich ein einfaches Problem bei der Datenbereinigung in einer simplen (aber beliebten) Komponente lawinenartig in einer Lieferkette ausbreiten und alle von ihr abhängigen Anwendungen in Mitleidenschaft ziehen kann. Der OSSRA Report 2022 konstatiert zusätzlich, dass 15 Prozent der geprüften Java-Codebasen eine anfällige Log4J-Komponente enthalten.
Gesamten Zyklus absichern
Es gibt zwei Arten von Unternehmen, die sich über das Risiko in der Softwarelieferkette Gedanken machen sollten: Softwarehersteller und Softwarebetreiber. Häufig stellen wir fest, dass Firmen beides sind: Sie nutzen Software, die von anderen entwickelt wurde, und erstellen daraus Software, die sie selbst verkaufen/vertreiben oder nutzen.
Um das Risiko für die Lieferkette zu minimieren, muss man zwingend wissen, was in einer Software enthalten ist, und sie gegen bekannte Angriffe absichern. Noch einfacher ausgedrückt: Unternehmen und Organisationen kommen nicht umhin, den kompletten Softwareentwicklungslebenszyklus (SDLC) absichern.
Die Sicherheit des SDLC lässt sich anhand dreier Bereiche beschreiben und angehen:
Sicherer Code
Open-Source-Abhängigkeiten. Identifizieren Sie den kompletten Open Source Code, der in Ihren Anwendungen enthalten ist. Erst dann können Sie ihn überwachen und auf Sicherheits- und Lizenz-/Compliance-Probleme hin überprüfen.
Kommerzieller Code/Fremdcode. Verfolgen Sie jeglichen Fremdcode nach, damit sie die Inhalte auf mögliche Risiken hin überprüfen können.
Benutzerdefinierter Code. Achten Sie darauf, dass jeder benutzerdefinierte oder proprietäre Code, den Ihre Organisation schreibt, frei von Fehlern oder Sicherheitslücken ist.
Sichere Bereitstellung
Container. Vergewissern Sie sich über den Inhalt eines Containers, bevor Sie ihn ausliefern. Schwachstellen in Basis-Images, bei der Erstellung eingebrachte Abhängigkeiten und Hardcoded Secrets sind allesamt bedenkliche Bereiche.
Infrastructure as Code (IaC). Was früher in der Verantwortung eines erfahrenen IT-/Ops-Experten lag, ist heute Aufgabe der Entwickler: die Infrastruktur zu konfigurieren, auf der die jeweiligen Apps laufen sollen. Bekannte Sicherheitslücken und Open Source Templates öffnen Angriffen Tür und Tor.
Software-Stückliste (SBOM)
Erstellen Sie eine SBOM, und fordern Sie sie selbst ein. Wenn Sie eine Software für Ihren Betrieb anschaffen, fordern Sie von Ihren Lieferanten eine SBOM vorzulegen. Wenn Sie Software anbieten, sollten Sie auch selbst bereit sein, Ihren Kunden eine solche Stückliste zur Verfügung zu stellen. Insbesondere, aber nicht nur, wenn Sie im öffentlichen Sektor oder bei US-Behörden tätig sind. An dieser Stelle ist es am besten, den Richtlinien der NTIA hinsichtlich der Anforderungen an eine SBOM zu folgen. Die Dokumente bieten Einblick, was in der Software enthalten ist, mit der Sie Ihre Firma betreiben – so lässt sich schnell auf etwaige Bedrohungen reagieren.
