Begriff

Supply Chain Attack

Security Hacking S3

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Früher griffen Hacker dein Haus an (Firewall knacken). Heute ist dein Haus eine Festung. Also greifen sie den Klempner an, der einen Schlüssel zu deinem Haus hat. Oder sie vergiften das Wasserwerk, das dein Haus versorgt. In der IT: Hacker brechen nicht bei dir ein, sondern beim Hersteller deiner Software. Sie verstecken einen Virus im offiziellen Update. Du installierst das Update (weil du brav bist) und holst dir den Hacker selbst ins Haus. Das Vertrauen in den Hersteller wird zur Waffe.

Merksatz: Ein Cyberangriff, der darauf abzielt, Organisationen zu schädigen, indem weniger sichere Elemente in der Lieferkette (Zulieferer, Partner) kompromittiert werden.

1. Typosquatting (NPM/PyPI)

Angriff auf Entwickler. Du willst npm install react tippen. Vertippst dich: npm install raect. Ein Hacker hat das Paket "raect" hochgeladen. Es macht alles, was React macht, aber klaut nebenbei deine Passwörter.

2. Dependency Confusion

Du hast ein internes Paket my-secret-tool (Version 1.0). Hacker lädt auf dem öffentlichen NPM ein Paket my-secret-tool (Version 99.0) hoch. Dein Build-Server denkt: "Oh, Version 99 ist neuer!" und lädt den Schadcode aus dem Internet statt von deinem internen Server.

1. Build Pipeline Integrity (SLSA Framework)

Der Schutz gegen Supply Chain Attacks heißt heute SLSA (pronounced "Salsa" - Supply-chain Levels for Software Artifacts). Es ist ein Standard von Google, der definiert, wie man beweist, dass Code wirklich aus dem Quellcode-Repo kommt und nicht auf halbem Weg manipuliert wurde. Das Ziel: Hermetic Builds. Das bedeutet, der Build-Server darf während des Kompilierens keine Verbindung zum Internet haben! Er darf nur lokal vorliegende, vorher signierte Abhängigkeiten nutzen. Dadurch wird verhindert, dass bösartige Skripte während des Builds Schadcode von einem Hacker-Server nachladen.

2. Binary Provenance & Attestations

Früher hat man nur Dateien gehasht. Heute nutzt man Attestations. Ein Build-Server erzeugt nicht nur die .exe, sondern ein kryptografisches Dokument, das sagt: "Ich, Server X, habe diesen Code mit Compiler Y um 12:00 Uhr gebaut." Mit Tools wie Cosign (Teil des Sigstore-Projekts) können Firmen-Firewalls (Kubernetes Admission Controller) erzwingen, dass nur Container-Images gestartet werden, die eine gültige Attestation von der firmeneigenen Build-Pipeline haben. Alles andere wird gnadenlos blockiert, selbst wenn es ein offizielles Update vom Hersteller zu sein scheint.

3. VEX: Vulnerability Exploitability Exchange

Ein großes Problem ist die "Dependency-Panik". Eine SBOM listet 500 Bibliotheken auf. Davon haben 20 eine Sicherheitslücke (CVE). Firmen verbringen Wochen damit, festzustellen: "Nutzen wir den betroffenen Teil der Library überhaupt?". VEX ist ein maschinenlesbares Dokument, in dem der Hersteller deklariert: "CVE-2024-1234 ist vorhanden, aber in unserem Produkt nicht ausnutzbar, da wir die Funktion deaktiviert haben." Das spart tausende Stunden Analysezeit und hilft, echte Supply Chain Risiken von reinem "Rauschen" zu trennen.

Quick-Check

Wie schützt man sich?
Extrem schwer. Zero Trust ("Traue niemandem, auch nicht Updates"). Netzwerküberwachung (Warum funkt der Update-Server nach Russland?). SBOMs prüfen.
Was ist "Code Signing"?
Ein digitales Siegel. Es beweist: "Das Update kommt wirklich von Microsoft." Problem bei Supply Chain Attacks: Die Hacker klauen den Stempel (Private Key) oder sitzen in der Fabrik (Build Server), bevor gestempelt wird.
Betrifft das nur Software?
Nein. Hardware auch. Die NSA hat Cisco-Router auf dem Postweg abgefangen, Wanzen eingebaut und wieder verpackt ("Interdiction").