KIberblick

Glossar-Eintrag

Supply-Chain-Angriff

Angriffsform, bei der nicht das Zielsystem selbst attackiert wird, sondern eine Komponente in der Lieferkette, die das Ziel vertrauensvoll einbindet.

Auch bekannt als: Supply Chain Attack, Lieferketten-Angriff

Ein Supply-Chain-Angriff zielt nicht direkt auf das Opfer, sondern auf eine Komponente in dessen Lieferkette: eine Software-Bibliothek, ein Build-Tool, ein Dienstleister. Wenn die Komponente kompromittiert ist, erben alle Nutzer den Schaden automatisch, weil sie ihr vertrauen.

Klassische Muster

Dependency-Angriffe: Ein Angreifer übernimmt ein NPM-, PyPI- oder RubyGems-Paket und schleust bösartigen Code ein. Jede Anwendung, die das Paket einbindet, zieht ihn sich. Event-stream (2018) und ctx (2022) waren prominente Fälle.

Typosquatting: Angreifer veröffentlichen Pakete mit tippfehler-ähnlichen Namen. Entwickler, die sich vertippen, installieren unbemerkt Malware.

Build-Chain-Kompromittierung: Ein Angreifer manipuliert nicht den Quellcode, sondern die Build-Infrastruktur. Die berühmten SolarWinds-Angriffe 2020 und xz-utils 2024 funktionierten so.

Dienstleister-Angriff: Der Angreifer kompromittiert einen IT-Dienstleister oder MSP. Über dessen Fernzugriff erreicht er viele Kunden auf einmal.

Protokoll-Schwachstellen: Eine Schwachstelle nicht in einer Bibliothek, sondern im Design eines verbreiteten Protokolls. Log4Shell 2021 und die MCP-Lücke 2026 sind Beispiele.

Warum Supply Chain besonders gefährlich ist

  • Hohes Vertrauen: Lieferkettenkomponenten werden in der Regel ohne tiefe Prüfung eingebunden.
  • Breite Reichweite: Ein erfolgreicher Angriff auf eine populäre Komponente erreicht tausende Organisationen gleichzeitig.
  • Schwer zu entdecken: Bösartiger Code in einer vertrauten Abhängigkeit sieht aus wie normaler Code.
  • Spätes Auffallen: Kompromittierungen bleiben oft Monate unbemerkt, weil der Angriff sich als legitime Software-Änderung tarnt.

Gegenmaßnahmen

  1. Software-Bill-of-Materials (SBOM): Eine vollständige Liste aller Abhängigkeiten pflegen.
  2. Lockfiles reviewen: Unerwartete Änderungen in package-lock.json oder pnpm-lock.yaml ernst nehmen.
  3. Dependency-Scanner einsetzen: Socket, Snyk, GitHub Dependabot erkennen verdächtige Pakete.
  4. Signierte Artefakte bevorzugen: Wo möglich signierte Container-Images, Git-Commits, Paket-Signaturen prüfen.
  5. Rechte minimieren: Selbst wenn eine Abhängigkeit kompromittiert ist, sollte sie nur das können, was sie wirklich braucht.
Quellen2