Software Supply Chain Security: Wie Unternehmen Abhängigkeiten und Build-Pipelines 2026 absichern

Digitale Sicherheits-Darstellung auf einem Computerbildschirm. Bildquelle: Pixabay / Pexels, CC0.

Was ist Software Supply Chain Security?

Moderne Softwareentwicklung baut auf einem Fundament aus Abhängigkeiten: Open-Source-Bibliotheken, Build-Tools, Container-Images, CI/CD-Pipelines, externe Registries. Jedes dieser Elemente ist ein potenzieller Angriffspunkt. Software Supply Chain Security bezeichnet alle Maßnahmen, die sicherstellen sollen, dass der Weg von Quellcode bis zum deploierten System nicht kompromittiert wird.

Die Bedrohungslage ist real. Der SolarWinds-Angriff 2020, bei dem Angreifer den Build-Prozess eines weit verbreiteten IT-Management-Tools manipulierten und so tausende Unternehmen und Behörden infiltrierten, hat das Thema auf die Agenda jedes Sicherheitsteams gebracht. 2024 erschütterte der XZ-Utils-Vorfall die Open-Source-Community: Über mehrere Monate hinweg hatte ein unbekannter Akteur unter falschem Namen an einem verbreiteten Komprimierungswerkzeug mitgearbeitet – und schließlich einen gezielten Backdoor eingebaut, der kurz vor der Entdeckung in Linux-Distributionen gelandet wäre.

Angriffsszenarien entlang der Lieferkette

Supply-Chain-Angriffe zielen auf verschiedene Punkte des Entwicklungs- und Deployment-Prozesses:

Kompromittierte Open-Source-Pakete: Angreifer übernehmen bestehende Pakete (durch Typosquatting, Kontoübernahme oder Social Engineering gegenüber Maintainern) oder veröffentlichen neue Pakete mit ähnlichen Namen, die bösartigen Code enthalten.
Manipulierte Build-Umgebungen: Wenn die CI/CD-Pipeline selbst kompromittiert ist, kann der Angreifer Binaries signieren, Testergebnisse fälschen oder Backdoors in den Output einbauen – ohne den Quellcode zu berühren.
Unsichere Container-Images: Basis-Images aus öffentlichen Registries können veraltete oder kompromittierte Pakete enthalten. Wer Base-Images unkritisch übernimmt, erbt alle bekannten Schwachstellen.
Dependency Confusion: Angreifer registrieren öffentliche Pakete mit demselben Namen wie interne, private Pakete – und nutzen die Tatsache aus, dass viele Package-Manager öffentliche Quellen bevorzugen.

SBOM: Software Bill of Materials

Eine der wichtigsten Gegenmaßnahmen ist das konsequente Führen eines Software Bill of Materials (SBOM) – einer strukturierten Liste aller Komponenten, die in einem Software-Produkt enthalten sind: Libraries, Frameworks, Transitive Abhängigkeiten, Lizenzen, Versionen.

Mit einem aktuellen SBOM kann ein Sicherheitsteam bei Bekanntwerden einer neuen Schwachstelle (CVE) sofort feststellen, ob die eigene Software betroffen ist – ohne mühsame manuelle Recherche. In den USA hat die Regierung per Executive Order die Bereitstellung von SBOMs für Software, die an Bundesbehörden geliefert wird, zur Pflicht gemacht. Ähnliche Anforderungen kommen durch den European Cyber Resilience Act auf europäische Unternehmen zu.

Werkzeuge zur SBOM-Generierung sind mittlerweile in die meisten Build-Prozesse integrierbar: Syft, CycloneDX und SPDX sind gängige Formate und Tools.

SLSA: Supply Chain Levels for Software Artifacts

Das von Google initiierte SLSA-Framework (ausgesprochen "Salsa") definiert vier Sicherheitsstufen für den Software-Lieferprozess. Jede Stufe stellt konkrete Anforderungen:

SLSA 1: Build-Prozess ist automatisiert und dokumentiert; Provenance-Informationen (Herkunftsnachweise) werden generiert.
SLSA 2: Builds laufen in einem vertrauenswürdigen, kontrollierten Build-Service; Provenance ist durch den Build-Service signiert.
SLSA 3: Build-Umgebung ist gehärtet; Quellcode und Build-Steps sind vollständig isoliert; keine Möglichkeit, den Build manuell zu beeinflussen.
SLSA 4: Zwei-Personen-Kontrolle für alle Änderungen; hermetic und reproduzierbarer Build (gleicher Input erzeugt stets identischen Output).

Die meisten Teams beginnen mit SLSA 1 und 2 – das ist bereits eine erhebliche Verbesserung gegenüber keiner Provenance-Infrastruktur.

Sigstore: Signieren ohne Schlüsselverwaltungsproblem

Software-Artefakte zu signieren ist kein neues Konzept – aber die praktische Schlüsselverwaltung war lange eine Hürde. Sigstore vereinfacht das radikal: Entwickler können ihre Artifacts signieren, ohne langlebige private Schlüssel speichern zu müssen. Stattdessen wird die Identität über OIDC-Tokens (zum Beispiel von GitHub Actions oder Google Workload Identity) nachgewiesen, und Signaturen werden in einem öffentlichen, unveränderlichen Transparenz-Log (Rekor) gespeichert.

Der Verifizierungsprozess läuft komplementär: Wer ein Artifact aus einer Registry zieht, kann prüfen, ob es von dem erwarteten Build-System signiert wurde – ohne vorab einen öffentlichen Schlüssel konfigurieren zu müssen.

Dependency Scanning und Vulnerability Management

Selbst ohne aktiven Angriff sind bekannte Schwachstellen in Abhängigkeiten ein erhebliches Risiko. Regelmäßiges Dependency Scanning sollte Pflichtbestandteil jeder CI/CD-Pipeline sein:

OWASP Dependency-Check und Trivy scannen Bibliotheken und Container-Images auf bekannte CVEs.
Dependabot (GitHub) und Renovate automatisieren die Erstellung von Pull Requests für Dependency-Updates.
Socket.dev analysiert npm-Pakete zusätzlich auf Verhaltensanomalien – etwa unerwartete Netzwerkzugriffe oder Filesystem-Operationen.

Wichtig: Dependency Scanning ist keine einmalige Maßnahme. Schwachstellen entstehen täglich neu, und eine Library, die heute sicher ist, kann morgen eine kritische CVE erhalten.

Build-Pipelines härten

Die CI/CD-Pipeline selbst ist ein hochprivilegiertes System: Sie hat typischerweise Zugriff auf Secrets, Produktions-Credentials und Deployment-Systeme. Entsprechend müssen die Pipelines selbst gehärtet werden:

Minimale Berechtigungen für Pipeline-Tokens (Principle of Least Privilege)
Keine hartkodierten Secrets im Pipeline-Code; stattdessen Secret-Manager wie Vault oder Cloud-eigene Dienste
Pinning von Actions und Drittanbieter-Tools auf spezifische Commit-Hashes statt auf Tags (Tags sind mutable)
Auditierung aller Pipeline-Änderungen; keine direkten Pushes auf geschützte Branches
Netzwerk-Isolation für Build-Jobs, soweit das Build-System das unterstützt

KI und Supply Chain Security

KI-gestützte Werkzeuge verbessern die Supply Chain Security in mehreren Bereichen. Static Analysis Tools nutzen Machine Learning, um bösartige Code-Muster in Open-Source-Paketen zu erkennen – auch wenn keine bekannte CVE vorliegt. LLMs helfen Entwicklern, Sicherheitsanforderungen beim Code-Review zu benennen und verdächtige Abhängigkeiten zu bewerten.

Gleichzeitig bringt KI neue Risiken: KI-generierter Code kann unbekannte Abhängigkeiten einschleppen oder unsichere Muster erzeugen. Sogenanntes "Slopsquatting" – die Erfindung nicht-existierender Paketnamen durch Sprachmodelle – kann dazu führen, dass Entwickler ohne Prüfung tatsächlich existierende bösartige Pakete mit ähnlichem Namen installieren.

Fazit

Software Supply Chain Security ist kein Randthema mehr. Die Angriffsfläche wächst mit jeder zusätzlichen Abhängigkeit, und die Konsequenzen einer erfolgreichen Lieferketten-Kompromittierung sind weitreichend. SBOMs, SLSA-konforme Build-Prozesse, Artefakt-Signierung mit Sigstore und kontinuierliches Dependency Scanning sind die Bausteine einer widerstandsfähigen Lieferkette. Teams, die diese Maßnahmen systematisch einsetzen, reduzieren nicht nur ihre Angriffsfläche – sie schaffen auch die Transparenz, die im Ernstfall schnelles Handeln ermöglicht.

Bildquelle: Pixabay / Pexels, CC0. Das Bild zeigt eine digitale Sicherheits-Darstellung auf einem Computerbildschirm.