Was sind Supply Chain Attacks?
Ein Supply Chain Attack umgeht die direkten Abwehrmechanismen eines Unternehmens vollständig. Statt das Ziel selbst anzugreifen, kompromittieren Angreifer eine vertrauenswürdige Komponente in der Lieferkette — ein Plugin, eine Bibliothek, ein Update, ein Build-Tool — und gelangen so auf indirektem Weg in Tausende von Systemen gleichzeitig.
Das Tückische: Das Opfer tut aus seiner Sicht alles richtig. Es installiert ein bekanntes Plugin, führt ein offizielles Update durch, bindet eine populäre Open-Source-Bibliothek ein. Genau das ist die Stärke dieser Angriffsmethode — und genau deshalb ist sie so gefährlich.
Aktuelle Vorfälle 2026: Kein theoretisches Risiko
Supply Chain Attacks sind kein abstraktes Zukunftsszenario — sie passieren gerade, und sie treffen Unternehmen jeder Größe. Die Vorfälle der letzten Monate zeigen die Breite des Angriffsfeldes:
Gemeinsamer Nenner aller Vorfälle: Die Opfer haben vertrauenswürdige, legitime Software eingesetzt. Perimeter-Sicherheit, Firewalls und Antivirenprogramme haben keinen dieser Angriffe verhindert — weil der Schadcode aus einer als sicher geltenden Quelle kam.
Angriffsvektor CI/CD-Pipelines und Dependencies
Moderne Softwareentwicklung ist hochgradig automatisiert — und genau das macht sie angreifbar. Eine typische Webanwendung bindet Hunderte von direkten und indirekten Abhängigkeiten ein. Jede davon ist ein potenzieller Einstiegspunkt.
- Typosquatting: Pakete mit ähnlichen Namen wie legitime Bibliotheken
- Dependency Confusion: interne Paketnamen öffentlich registrieren
- Kompromittierung von Maintainer-Accounts (npm, PyPI, WordPress.org)
- Einschleusen von Schadcode in Pull Requests open-source Projekte
- Manipulation von Build-Artefakten in CI/CD-Systemen
- Gestohlene Signing-Keys für legitim signierte Pakete
- Keine Versions-Pinning — immer die neueste Version wird geladen
- Transitive Dependencies nicht im Blick (Abhängigkeiten von Abhängigkeiten)
- Keine automatischen Vulnerability-Scans in der Pipeline
- Langlebige CI/CD-Secrets ohne Rotation
- Kein Monitoring auf unerwartete Netzwerkverbindungen aus Builds
- Plugins und CMS-Komponenten werden selten aktualisiert
Wichtig zu verstehen: Eine durchschnittliche Node.js-Anwendung hat ca. 1.000 transitive Abhängigkeiten. Wer jede davon manuell prüft, kann nicht gleichzeitig entwickeln. Automatisierung ist keine Komfortlösung — sie ist die einzige skalierbare Antwort.
SBOM: Software Bill of Materials — die Grundlage der Transparenz
Eine Software Bill of Materials (SBOM) ist eine maschinenlesbare Liste aller Komponenten, die in einem Softwareprodukt enthalten sind — mit Versionen, Lizenzen und bekannten Schwachstellen. Sie ist das Äquivalent zur Zutatenliste auf einem Lebensmittelprodukt: Transparenz darüber, was wirklich drinsteckt.
Die SBOM wird zunehmend zur Pflicht. Der EU Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen, eine SBOM zu erstellen (Verordnung (EU) 2024/2847, Anhang I Teil II Nr. 1, anwendbar ab dem 11. Dezember 2027). In den USA hat die Executive Order 14028 SBOM-Anforderungen für Software angestoßen, die an US-Bundesbehörden verkauft wird. Die NIS2-Richtlinie verlangt Maßnahmen zur Sicherheit der Lieferkette (Art. 21 Abs. 2 lit. d), schreibt aber keine SBOM vor. Auch im B2B-Bereich wird sie zunehmend von Großunternehmen als Voraussetzung in Lieferantenverträgen gefordert.
Im Ernstfall — etwa wenn ein neues kritisches CVE bekannt wird — kann ein Unternehmen mit einer aktuellen SBOM innerhalb von Minuten prüfen, ob und wo eine verwundbare Komponente eingesetzt wird. Ohne SBOM kann dieselbe Analyse Tage oder Wochen dauern.
Sichere CI/CD-Pipelines: Wo viele Unternehmen angreifbar sind
Die Build- und Deployment-Pipeline ist das Nervensystem moderner Softwareentwicklung — und eines der am häufigsten unterschätzten Angriffsziele. Ein Angreifer, der die Pipeline kontrolliert, kontrolliert alles, was darüber deployed wird.
API-Keys, Deployment-Tokens und Zugangsdaten dürfen niemals im Klartext in Pipeline-Konfigurationen oder im Code liegen. Stattdessen: Secrets Manager (GitHub Actions Secrets, HashiCorp Vault, Azure Key Vault) mit kurzlebigen, automatisch rotierenden Credentials.
Modern Deployments nutzen OpenID Connect (OIDC) für die Authentifizierung von CI/CD-Systemen gegen Cloud-Provider. Dabei werden kurzlebige Tokens ausgestellt, die nur für die Dauer des Builds gültig sind — kein dauerhafter API-Key, der gestohlen werden kann.
Jeder einzelne Schritt in einer Build-Pipeline sollte nur die Berechtigungen haben, die er tatsächlich benötigt. Ein Test-Step braucht keinen Schreibzugriff auf das Container Registry. Ein Build-Step braucht keinen Zugriff auf Produktionsdatenbanken.
Build-Artefakte (Container Images, Binaries, Pakete) sollten kryptografisch signiert werden — damit nachgewiesen werden kann, dass sie von einer vertrauenswürdigen Pipeline stammen und nach dem Build nicht verändert wurden. Standards: SLSA (Supply Chain Levels for Software Artifacts), Sigstore/Cosign.
Realitätscheck: Bei vielen Unternehmen sind GitHub Actions oder GitLab CI/CD mit weitreichenden Cloud-Berechtigungen konfiguriert — und jeder, der einen Pull Request öffnen kann, kann potenziell Code in die Pipeline einschleusen. Prüfen Sie, wer in Ihrer Pipeline Änderungen vornehmen darf.
Konkrete Maßnahmen — priorisiert und umsetzbar
Supply Chain Security ist kein einmaliges Projekt — es ist ein fortlaufender Prozess. Diese sechs Maßnahmen bilden eine solide Grundlage:
Software-Inventar und SBOM einführen
Wissen Sie, welche Bibliotheken, Plugins und Drittanbieter-Komponenten in Ihrer Software stecken? Ohne vollständiges Inventar können Sie bei einem Vorfall nicht schnell reagieren. Eine SBOM (Software Bill of Materials) ist die Grundlage jeder Supply-Chain-Sicherheitsstrategie.
Dependency-Pinning und Integrity Checks
Wer externe Pakete ohne Versions-Pinning einbindet, kann nicht sicher sein, was er bekommt. Eine gepinnte Version garantiert, dass immer exakt dasselbe Paket geladen wird — und ein Hash-Vergleich stellt sicher, dass der Inhalt unverändert ist.
Automatisches Schwachstellen-Scanning
Neue Schwachstellen in Abhängigkeiten werden täglich entdeckt. Manuelles Prüfen ist nicht skalierbar. Automatisierte Tools scannen kontinuierlich alle eingesetzten Komponenten gegen bekannte CVE-Datenbanken und alarmieren bei Treffern.
Sichere und gehärtete CI/CD-Pipelines
CI/CD-Systeme haben in modernen Unternehmen weitreichende Rechte: Sie deployen Code, schreiben in Repositories, interagieren mit Cloud-Infrastruktur. Gleichzeitig sind sie oft kaum abgesichert — ein attraktives Angriffsziel.
Vertrauenswürdige Quellen und Private Registries
Pakete aus unbekannten oder öffentlichen Quellen sind ein Risiko. Dependency Confusion Attacks nutzen aus, dass interne Paketnamen auch öffentlich registriert werden können — und das öffentliche Paket dann bevorzugt geladen wird.
Update-Zyklen und Patch-Prozesse für alle Komponenten
Plugins, Themes, CMS-Systeme und Libraries veralten schnell. Die meisten Supply-Chain-Angriffe auf WordPress-Seiten betreffen Plugins, die seit Monaten nicht mehr aktualisiert wurden. Regelmäßige Updates sind eine der wirksamsten Schutzmaßnahmen.
Quellen
- Software Bill of Materials (SBOM) — Cybersecurity and Infrastructure Security Agency (CISA)
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1 — National Institute of Standards and Technology (NIST)
- Verordnung (EU) 2024/2847 – Cyber Resilience Act (SBOM-Pflicht für Hersteller, Anhang I Teil II) — Amtsblatt der EU / EUR-Lex
- Executive Order 14028: Improving the Nation’s Cybersecurity (Sec. 4(e)(vii): SBOM) — Federal Register / The White House
- NIS-2-Pflichten (u. a. Sicherheit der Lieferkette) — Bundesamt für Sicherheit in der Informationstechnik (BSI)
- Reported Supply Chain Compromise Affecting XZ Utils (CVE-2024-3094) — CISA
- SLSA – Supply-chain Levels for Software Artifacts — Open Source Security Foundation (OpenSSF)
- Threat Landscape for Supply Chain Attacks — Agentur der Europäischen Union für Cybersicherheit (ENISA)
Wissen Sie, was in Ihrer Software steckt?
Die meisten Unternehmen haben keinen vollständigen Überblick über ihre eingesetzten Komponenten — und merken es erst, wenn ein Vorfall eintritt. Wir helfen Ihnen, Transparenz herzustellen und konkrete Schutzmaßnahmen zu implementieren.
Jetzt Supply-Chain-Analyse anfragenWeiterlesen
