Compliance und Risiko
Cyberresilienz in der Software-Lieferkette
Nahezu wöchentlich werden Sicherheitslücken in Programmkomponenten entdeckt und zeitnah auch Exploits veröffentlicht. Das Problem: Jede Komponente ist auch Teil einer Lieferkette. Wie lässt sich also Cyberresilienz in der Supply Chain gewährleisten?
Save to Folio
Die Gewährleistung von Cyberresilienz in der Software-Lieferkette ist nicht nur aus sicherheitstechnischer Sicht von großer Bedeutung, sondern auch eine wesentliche Forderung der aktuellen und zukünftigen Regularien und Gesetzen. Sicherheitslücken in bekannten Programmen werden nahezu wöchentlich entdeckt, und Exploits werden oft zeitnah veröffentlicht. Angriffe betreffen nahezu jede Programmiersprache und jedes Paket-Ökosystem, sowohl durch unbeabsichtigte als auch durch absichtliche Schwachstellen.
Softwarekomponenten sind stets Bestandteil einer Lieferkette. Eine Schwachstelle in einer Komponente kann die Funktionalität der gesamten Endanwendung beeinträchtigen. Ein Beispiel für eine solche Schwachstelle ist Log4J, welche eine Vielzahl von Anwendungen und Diensten betraf. Die Komplexität steigt insbesondere bei der Nutzung von Cloud-Diensten, wenn Abhängigkeiten verschachtelt sind. Eine Schwachstelle in einer Bibliothek oder einem Dienst kann zu einer Kompromittierung der eigenen Anwendung führen.
Fallbeispiel: XZ-Schwachstelle
Die kürzlich entdeckte Schwachstelle in der weit verbreiteten Kompressionsbibliothek XZ verdeutlicht die potenziellen Risiken, die mit der Existenz solcher Schwachstellen verbunden sind. Co-Maintainer hatten über einen längeren Zeitraum „Verbesserungen“ hinzugefügt, die letztlich eine Backdoor ermöglichten. Der ursprüngliche Entwickler wurde unter Druck gesetzt, die Verantwortung abzugeben, was jedoch nicht geschah. Die Schwachstelle wurde entdeckt, bevor die verwundbare Version veröffentlicht wurde. Dies verdeutlicht, welche Ressourcen Angreifer in die Ausnutzung einer solchen Schwachstelle investieren können.
Die jüngsten Ereignisse zeigen, dass nicht nur Bibliotheken, sondern auch Entwicklungswerkzeuge betroffen sind. Die Malware Keyzetsu wurde über kompromittierte Plugins für Visual Studio Code verbreitet. Die genannten Plugins werden direkt vom Entwickler bereitgestellt und ermöglichen das Einfügen oder Verändern beliebiger Funktionen in den Code. Dies macht die Komplexität der Software-Lieferkette deutlich.
Herausforderungen
Bei der Software-Lieferkette sind verschiedene Arten von Artefakten zu berücksichtigen. Beispiele sind die folgenden:
- Bei der Nutzung moderner Paketmanager zur Festlegung von Abhängigkeiten ist zu beachten, dass diese zwar eine einfache Möglichkeit dazu bieten, jedoch das Risiko bergen, die gesamte Software zu kompromittieren, falls eine Lücke übersehen wird. SBOMs (Software Bill of Materials) bieten eine optimale Möglichkeit, diese Abhängigkeiten zu dokumentieren und zu managen.
- Auch bei Container Images müssen wir mit zahlreichen Abhängigkeiten rechnen, ähnlich wie bei Bibliotheken. Ein kompromittiertes Basic Image kann unter Umständen dazu führen, dass das eigene Container Image verwundbar bzw. kompromittiert wird. Dies ist umso bedauerlicher, als Container Images standardmäßig keine Lock-Dateien mit exakten Versionen und Hashes enthalten.
- Unsere Erfahrung zeigt, dass die Firmware in vielen Fällen bereits „fertig gebaut“ vorhanden ist und nur schwer in SBOM-Prozesse eingebunden werden kann. Eine manuelle Risikoabschätzung ist häufig die beste, und auch leider einzige Lösung.
- Bei der Bewertung von Entwicklungsumgebungen wird oft nur unzureichend auf die einzelnen Aspekte eingegangen, was zu einer suboptimalen Bewertung führt. Es ist von entscheidender Bedeutung, Abhängigkeiten von Bibliotheken und Tools präzise zu definieren und zu dokumentieren. Dies gilt auch für jene Abhängigkeiten, die „nur“ während der Entwicklung und nicht zur Laufzeit genutzt werden. Dadurch lassen sich potenzielle Schwachstellen nachvollziehen und beheben.
- Bei KI-Training, KI-Modellen und Runtimes besteht die Möglichkeit, dass kompromittierte Trainingsdaten, -prozesse und Modelle beliebigen Code ausführen. Auch die Trainingsumgebung und die verwendeten Daten sind Bestandteile der Software-Lieferkette und müssen entsprechend dokumentiert und bewertet werden.
Die Gewährleistung von Cyberresilienz in der Software-Lieferkette stellt nicht nur eine technische Herausforderung dar. NIS2 fordert einen risikobasierten Sicherheitsansatz, der alle relevanten Risiken, einschließlich die Lieferkette, bewertet. Auch der Cyber Resilience Act (CRA) sowie weitere gesetzliche Vorgaben stellen Anforderungen an Hersteller und Betreiber.
Empfehlungen
Betreiber sollten Cybersicherheitsinformationen zur Risikobewertung direkt aus der Lieferkette abfragen, um eine fundierte Einschätzung des Cybersicherheitsrisikos zu ermöglichen. Dies beinhaltet auch die Einbindung von SBOMs, Serviceabhängigkeiten sowie Reporting- und Incident-Response-Prozessen.
Hersteller müssen Cybersicherheitsinformationen zeitnah und mit möglichst geringem Aufwand bereitstellen. Die Erstellung und Implementierung von SBOMs sollte in die eigenen CI/CD-Prozesse integriert werden. Die Dokumentation und Implementierung der Security-, Vulnerability Discovery- und Incident Response-Prozesse ist erforderlich.
Fazit
Die Gewährleistung von Cyberresilienz in der Software-Lieferkette stellt eine komplexe, jedoch unerlässliche Herausforderung dar. Aus Sicherheitsgründen ist es unerlässlich, die Dokumentation von Artefakten, Versionen und Schwachstellen uneingeschränkt zu nutzen. Sie gewährleistet die Übersichtlichkeit und ermöglicht ein schnelles und gezieltes Handeln bei Vorfällen. Die Ermittlung von Cybersicherheitsrisiken entlang der Lieferkette ist nicht nur wünschenswert, sondern in vielen Fällen inzwischen auch eine regulatorische bzw. gesetzliche Anforderung.