Glossar

Supply-Chain-Angriff (Lieferkettenangriff)

Bei einem Supply-Chain-Angriff kompromittieren Angreifer nicht ihr eigentliches Ziel direkt, sondern einen vertrauenswürdigen Zulieferer – etwa einen Software-Hersteller, eine Open-Source-Bibliothek oder einen IT-Dienstleister – und gelangen über dessen legitime Kanäle zu vielen Opfern gleichzeitig. Das macht diese Angriffsklasse so gefährlich: Ein einziger erfolgreicher Einbruch beim Lieferanten öffnet Türen bei tausenden Kunden, die dem Update, dem Paket oder dem Dienstleister vertrauen. Typische Varianten: manipulierte Software-Updates (der Angreifer schleust Schadcode in den Build- oder Update-Prozess ein), vergiftete Open-Source-Pakete (Typosquatting, übernommene Maintainer-Konten, bösartige Abhängigkeiten in npm/PyPI), kompromittierte CI/CD-Pipelines und Angriffe über Managed-Service-Provider mit weitreichenden Zugriffen auf Kundensysteme. Die Verteidigung beginnt mit Transparenz: Wissen, welche Software und welche Abhängigkeiten überhaupt im Einsatz sind (Software Bill of Materials, SBOM), Versionen exakt festschreiben statt „latest“ zu ziehen, Signaturen und Checksummen von Updates prüfen, Dependency- und Image-Scanning in die Pipeline einbauen und Zugriffe von Dienstleistern nach dem Least-Privilege-Prinzip beschränken. NIS2 macht die Sicherheit der Lieferkette ausdrücklich zur Pflicht. Ebenso wichtig ist Reaktionsfähigkeit: Wird eine kompromittierte Komponente bekannt, zählt die Zeit bis zur Antwort auf die Frage „Sind wir betroffen?“. Ein gepflegtes Inventar plus laufende Überwachung der Sicherheitsmeldungen – etwa über den SecFeed Risk Radar mit deinem hinterlegten Stack – verkürzt diese Zeit von Tagen auf Minuten. Bekannte Fälle zeigen die Bandbreite: kompromittierte Build-Systeme großer Softwarehersteller, über Update-Mechanismen verteilte Hintertüren, bösartige Versionen populärer Open-Source-Pakete mit Millionen wöchentlicher Downloads und Angriffe auf CI/CD-Systeme, die Signaturschlüssel entwendeten. Die Lehre daraus ist unbequem: Vertrauen in einen Lieferanten ist keine einmalige Entscheidung, sondern ein laufender Prozess. Konkrete erste Schritte für KMU: eine SBOM je Anwendung erzeugen (viele Build-Tools können das inzwischen nativ), automatisierte Dependency-Updates aktivieren, Container-Images aus vertrauenswürdigen Registries mit Digest-Pinning beziehen und Dienstleister-Zugänge mit MFA plus zeitlicher Begrenzung versehen. Wichtig ist auch der Blick nach vorn: Verträge mit Software-Lieferanten sollten Sicherheitsanforderungen, Meldepflichten bei Vorfällen und Support-Zeiträume ausdrücklich regeln – NIS2 erwartet genau diese Sorgfalt.

Aktuelle Meldungen dazu: security · ← zum Glossar