Check it out
awards
WiWo Award TRUSTEQ
BrandEins Berater 2026 Award
TRUSTEQ kununu awards
TRUSTEQ | Corporative Excellence

Trojanisches Pferd neu gedacht

Software Supply Chain Security

Wer sich abhängig macht, ist verwundbar: Lieferkettensicherheit gilt auch für Software. Über die Bedeutung von Software Supply Chain Security.

Die Software-Lieferkette ist als Angriffsvektor schon lange kein Nischenthema mehr. Mit der zunehmenden Nutzung von Open-Source-Komponenten, automatisierten Build-Prozessen und global verteilten Entwicklungsumgebungen sind Code-Dependencies zu einem der kritischsten Bestandteile moderner IT-Infrastrukturen geworden.

Spätestens seit Angriffen wie s1ngularity oder Shai-Hulud ist klar, wie verwundbar eine moderne Software Supply Chain ist. Beide verwenden infizierte npm-Pakete, um Schadcode zu verbreiten und so Tokens und Credentials zu stehlen. Angreifer nutzen dabei gezielt das Vertrauen, das Entwickler in etablierte Paket-Repositories und automatisierte Installationsprozesse setzen. Ein besonders prominentes Beispiel außerhalb des npm-Ökosystems ist die sogenannte XZ-Utils-Backdoor, die aufzeigt, wie tief verankerte Systembibliotheken kompromittiert werden können. 

Solche Bedrohungen zeigen: Nicht nur der eigene Code ist kritisch, sondern jede verwendete Dependency und dahinterstehende CI/CD-Pipeline. Ein kompromittiertes Paket oder geleaktes Secret reicht, um ganze Systeme zu gefährden. Gerade in komplexen Projekten mit hunderten oder tausenden indirekten Abhängigkeiten entsteht so eine enorme Angriffsfläche, die ohne geeignete Sicherheitsmechanismen kaum noch vollständig überblickt werden kann.

Symbol Lieferkette

Was bedeutet das für Unternehmen?

Software Supply Chain Security (SSCS) muss ganzheitlich gedacht werden, von der Prävention bis zur Mitigation. Ein Überblick.

AI

Version Pinning

Reproduzierbare, geprüfte Versionen statt „latest“ verwenden. Dadurch wird verhindert, dass unkontrolliert neue Versionen mit potenziell unsicherem Code automatisch eingebunden werden.

Dependency Scanning & Auditing

Kompromittierte Pakete automatisiert erkennen und anzeigen. Regelmäßige Scans identifizieren bekannte Sicherheitslücken (CVEs) und warnen frühzeitig vor kompromittierten oder manipulierten Abhängigkeiten.

Secret Scanning & Rotation

Keine Zugangsdaten im Code oder Repository; Automatisierte Tools erkennen versehentlich veröffentlichte Tokens oder API-Schlüssel und ermöglichen eine schnelle Rotation.

Least Privilege & Zero Trust

Jede Komponente bekommt nur die nötigsten Rechte und es gibt kein zwischenseitiges Vertrauen ohne vorherige Prüfung. Selbst wenn einzelne Komponenten kompromittiert werden, lässt sich so der potenzielle Schaden deutlich begrenzen.

Im operativen Prozess sollte die Sicherheitsarchitektur nicht in Vergessenheit geraten...

AI

CI/CD-Isolation

Strikte Trennung von Build-, Test- und Produktivumgebungen. Isolierte Pipeline-Stufen verhindern, dass kompromittierte Build-Prozesse direkten Zugriff auf produktive Systeme oder sensible Daten erhalten.

SBOMs & Reproducible Builds

Transparenz darüber, was wirklich in der Software steckt. Eine “Software Bill of Materials” ermöglicht es, jede enthaltene Komponente und deren Herkunft nachvollziehbar zu dokumentieren.

Incident-Response-Mechanismen

Klare Prozesse und schnelle Isolation. Definierte Playbooks und automatisierte Reaktionen können die Ausbreitung eines Angriffs deutlich eindämmen.

Drei Schritte für mehr Lieferketten-Sicherheit

Die Konsequenzen: Beispielfall s1ngularity

Wenn die Gefahr nicht rechtzeitig erkannt wird und ein Angreifer erfolgreich Schadsoftware ausführt, ist das Schadenspotenzial enorm. Bei einem ausgeklügelten Angriff kann das Resultat von System- und Datenverlust bis hin zu extrahierten Informationen und Ransomware reichen.

Quelle: GitGuardian

Die XZ-Utils-Backdoor

Es war auch eine Schwäche in der Software Supply Chain, die Anfang 2024 nahezu zu einem der größten Sicherheitszwischenfälle des modernen Internets geführt hätte: Angreifer etablierten eine Backdoor in der Bibliothek “OpenSSH” und damit potenziell Zugang zu kritischer Infrastruktur weltweit.

Der Ansatz

Die Methode des Angriffs war die Übernahme der Abhängigkeit XZ-Utils, einer von der Zielsoftware genutzten Bibliothek zur Dateikompression. Der Angreifer mit dem Pseudonym “Jia Tan” schaffte es, hochgradig verschleierte Schadsoftware einzuschleusen, die den Schlüsselaustausch zwischen zwei Systemen modifizierte. 

Das Ausmaß

Die Hintertür ermöglicht dem Angreifer, diesen Mechanismus mit seinem eigenen Schlüssel auszuhebeln und somit unbemerkt Zugriff auf betroffene Systeme zu erhalten. Da die “Secure Shell” (SSH) auf nahezu jedem Linux-Server weltweit benutzt wird, ist das Schadenspotenzial enorm. 

Die Rettung

Die Tatsache, dass dieser Angriff öffentlich geworden ist, ist dem Entwickler Andreas Freund zu verdanken, der Performanceprobleme bei Tests zum Verbindungsaufbau mittels SSH feststellte. Weitere Analysen führten schließlich zu den komplex verschleierten Mechanismen der XZ-Utils-Backdoor. 

Somit konnte eine globale Bedrohung über die Software Supply Chain im letzten Moment gestoppt werden. Der über mehrere Jahre vorbereitete Angriff kam schließlich nur durch Performance-Abweichungen im Endsystem ans Licht. Das zeugt von der mangelnden Resilienz, die in diesem Bereich noch vorliegt.


Fazit: Die Betrachtung möglicher Gefahrenquellen darf nicht beim eigenen Code enden, sondern muss darüber hinausgehen. Wer die Software-Lieferkette aus den Augen verliert, öffnet Angreifern unbemerkt ein Einfallstor, denn neue Abhängigkeiten, Updates und Änderungen in der Infrastruktur führen ständig zu neuen potenziellen Risiken. Wer hier investiert, schützt nicht nur Code, sondern auch Ansehen und Kundendaten

Robert Haimerl

Cybersecurity Consultant