Supply Chain Security für Docker-Basis-Images

1. Warum die Basis-Image-Lieferkette ein eigenes Risiko ist

Supply Chain Security für Docker-Basis-Images adressiert eine Angriffsfläche, die weit vor dem eigenen Code beginnt: Ein Basis-Image wie `node:20-alpine` wird von einer dritten Partei gebaut, gepflegt und in eine Registry veröffentlicht, der das eigene Team implizit vertraut, sobald es das Image per Tag referenziert. Wird dieses Basis-Image kompromittiert, etwa durch einen Angriff auf die Build-Pipeline des Maintainers, erbt jedes darauf aufbauende eigene Image die Kompromittierung automatisch.

Reale Vorfälle wie der Angriff auf `ua-parser-js` oder kompromittierte Docker-Hub-Accounts zeigen, dass diese Lieferkette kein theoretisches Risiko ist. Supply Chain Security in Docker-Umgebungen bedeutet konkret, jeden Schritt von der Auswahl des Basis-Images bis zur Auslieferung des fertigen Images überprüfbar zu machen, statt implizitem Vertrauen in Tags und Registry-Namen zu folgen. Die folgenden Abschnitte zeigen, wie sich diese Nachvollziehbarkeit mit konkreten, heute verfügbaren Werkzeugen umsetzen lässt.

2. Digests statt Tags: reproduzierbare Referenzen

Ein Tag wie `node:20-alpine` ist eine bewegliche Referenz, die der Maintainer jederzeit auf ein anderes, neues Image umbiegen kann, ohne dass sich der Tag-Name ändert. Für Supply Chain Security ist das ein Problem: Ein Build, der heute `node:20-alpine` zieht, kann morgen ein anderes Image bekommen, ohne dass die Dockerfile sich geändert hat. Ein Content-Digest wie `node@sha256:8f3c...` hingegen referenziert exakt einen unveränderlichen Inhalt, kryptographisch garantiert durch den SHA256-Hash der Image-Manifest-Datei.

Das Anheften an Digests statt Tags ist der einfachste und wirksamste Einzelschritt für Supply Chain Security, weil er keine zusätzliche Infrastruktur benötigt, nur eine Disziplin in der Dockerfile-Pflege. Der Nachteil ist offensichtlich: Digests sind für Menschen nicht lesbar und müssen bei jedem Basis-Image-Update explizit aktualisiert werden. Werkzeuge wie Dependabot oder Renovate automatisieren genau diesen Aktualisierungsschritt und öffnen einen Pull-Request, sobald ein neuer, überprüfter Digest verfügbar ist.

# Dockerfile: pin the base image to an immutable content digest, not a mutable tag
FROM node@sha256:8f3c1a9b2e77d4f6c0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3

# Resolve the current digest for a tag before pinning it
# docker pull node:20-alpine
# docker inspect node:20-alpine --format "{RepoDigests}" (see docs for output parsing)

3. Vertrauenswürdige Registries und Herkunft prüfen

Nicht jede Registry bietet dasselbe Sicherheitsniveau. Docker Hub erlaubt jedem registrierten Nutzer, Images unter eigenem Namensraum zu veröffentlichen, und Namensverwechslungen wie `libary/node` statt `library/node` sind ein bekanntes Angriffsmuster, das auf Tippfehler von Entwicklern setzt. Supply Chain Security beginnt daher mit der bewussten Wahl der Quelle: offizielle Docker-Official-Images, verifizierte Publisher-Images oder eine private, kuratierte Registry, statt beliebiger Community-Images ohne Herkunftsnachweis.

Für Unternehmen mit höheren Anforderungen lohnt sich eine interne Registry mit einer kuratierten Whitelist erlaubter Basis-Images, kombiniert mit einer Admission-Policy, die Pulls von nicht freigegebenen externen Quellen technisch verhindert. Dieser Ansatz verschiebt Supply Chain Security von einer Frage der individuellen Entwickler-Disziplin zu einer durchgesetzten Organisationsrichtlinie.

4. Image-Signierung mit Cosign einführen

Cosign, ein Projekt aus dem Sigstore-Ökosystem, signiert Docker-Images kryptographisch und speichert die Signatur direkt neben dem Image in der Registry. Anders als klassische PKI-basierte Signaturverfahren unterstützt Cosign auch keyless Signing über kurzlebige Zertifikate, die an eine OIDC-Identität wie einen GitHub-Actions-Workflow gebunden sind, statt einen langlebigen privaten Schlüssel manuell verwalten zu müssen. Für Supply Chain Security senkt das die operative Hürde erheblich, weil kein Schlüsselmanagement-Prozess für einzelne Entwickler nötig ist.

Die Signatur bestätigt zwei Dinge: dass das Image seit der Signierung nicht verändert wurde, und dass es von einer bestimmten, überprüfbaren Identität stammt. Beide Eigenschaften sind für Supply Chain Security entscheidend, weil sie eine nachträgliche Manipulation in der Registry, etwa durch einen kompromittierten Registry-Account, technisch erkennbar machen, statt sich auf reines Vertrauen zu verlassen.

#!/usr/bin/env bash
# Sign an image with Cosign using keyless (OIDC-based) signing
set -euo pipefail

cosign sign --yes \
  myregistry.example.com/shop-api@sha256:8f3c1a9b2e77d4f6c0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3

# Alternative: sign with a locally managed key pair
cosign generate-key-pair
cosign sign --key cosign.key \
  myregistry.example.com/shop-api@sha256:8f3c1a9b2e77d4f6c0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3

5. Signaturen bei Pull und Deployment verifizieren

Eine Signatur allein bringt keinen Sicherheitsgewinn, solange niemand sie prüft. Der zweite notwendige Schritt für Supply Chain Security ist, die Verifikation an dem Punkt zu erzwingen, an dem ein Image tatsächlich in Produktion läuft, sei es beim Pull im Build-Server oder als Admission-Policy im Orchestrator. Ohne diese erzwungene Prüfung bleibt die Signierung eine reine Formalität ohne technische Wirkung.

Cosign bietet einen Verifikationsbefehl, der bei fehlender oder ungültiger Signatur einen Nicht-Null-Exit-Code zurückgibt, was sich direkt in CI-Gates integrieren lässt. In Kubernetes-Umgebungen übernehmen Werkzeuge wie Kyverno oder Sigstore Policy Controller diese Durchsetzung als Admission-Webhook, sodass unsignierte Images gar nicht erst gestartet werden.

#!/usr/bin/env bash
# CI gate: refuse to deploy an image without a valid Cosign signature
set -euo pipefail

IMAGE="myregistry.example.com/shop-api@sha256:8f3c1a9b2e77d4f6c0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3"

if ! cosign verify --certificate-identity-regexp "https://github.com/mironsoft/.*" \
     --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
     "$IMAGE" > /dev/null 2>&1; then
  echo "[BLOCKED] Image signature verification failed, refusing to deploy" >&2
  exit 1
fi

echo "[OK] Signature verified, proceeding with deployment"

6. Provenance-Nachweise nach SLSA verstehen

Eine Signatur bestätigt, wer ein Image signiert hat, aber nicht, wie es gebaut wurde. Genau diese Lücke schließt SLSA (Supply-chain Levels for Software Artifacts) mit Provenance-Nachweisen: einer strukturierten Aussage darüber, welcher Build-Prozess, welches Source-Repository und welcher Commit ein Image erzeugt haben. Für Supply Chain Security ist das ein wichtiger zusätzlicher Baustein, weil er verhindert, dass ein Angreifer mit gestohlenen Signierungs-Credentials ein manipuliertes Image im Namen des richtigen Teams signiert.

SLSA definiert vier Reifegrade, von grundlegender Nachvollziehbarkeit bis zu vollständig isolierten, reproduzierbaren Builds. Für die meisten Docker-Projekte ist SLSA Level 2 oder 3 ein realistisches Ziel: signierte Provenance aus einer gehosteten CI-Plattform wie GitHub Actions, die den Build-Prozess selbst attestiert. GitHub Actions unterstützt native Provenance-Erzeugung über `actions/attest-build-provenance`, ohne dass ein Team eine eigene Attestierungs-Infrastruktur betreiben muss.

7. Eigene Images mit Provenance und Signatur ausliefern

Die eigenen Images eines Teams sind für die eigenen Kunden oder nachgelagerten Teams genau dieselbe Vertrauensfrage wie ein externes Basis-Image. Konsequente Supply Chain Security bedeutet daher, nicht nur eingehende Basis-Images zu prüfen, sondern auch die eigenen Images signiert und mit Provenance-Nachweis auszuliefern. Das ist besonders relevant, wenn Images an Kunden oder in eine größere Organisation mit mehreren Teams verteilt werden.

Ein vollständiger CI-Workflow für Supply Chain Security umfasst typischerweise: Build des Images mit gepinntem Basis-Image, SBOM-Erzeugung, Signierung mit Cosign, Attestierung der Provenance und Push in die Registry, alles als ein zusammenhängender, automatisierter Schritt ohne manuelle Zwischenschritte, die eine Angriffsfläche für Manipulation böten.

#!/usr/bin/env bash
# Full release workflow: build, SBOM, sign, attest provenance, push
set -euo pipefail

IMAGE="myregistry.example.com/shop-api"
TAG="1.5.0"

docker build -t "${IMAGE}:${TAG}" .
docker push "${IMAGE}:${TAG}"

DIGEST=$(docker inspect "${IMAGE}:${TAG}" | jq -r '.[0].RepoDigests[0]' | cut -d@ -f2)

syft "${IMAGE}@${DIGEST}" -o cyclonedx-json > "sbom-${TAG}.json"
cosign sign --yes "${IMAGE}@${DIGEST}"
cosign attest --yes --predicate "sbom-${TAG}.json" --type cyclonedx "${IMAGE}@${DIGEST}"

echo "[OK] Released ${IMAGE}@${DIGEST} with signature and SBOM attestation"

8. Basis-Images aktuell halten, ohne Kontrolle zu verlieren

Gepinnte Digests lösen das Problem unkontrollierter Änderungen, schaffen aber ein neues: Ohne aktiven Prozess bleibt ein einmal gepinntes Basis-Image für immer auf demselben, irgendwann veralteten Stand, mit allen zugehörigen unbehobenen Schwachstellen. Supply Chain Security braucht daher einen gesteuerten Update-Prozess, der neue Digests automatisiert vorschlägt, aber nicht automatisch und ungeprüft übernimmt.

Renovate und Dependabot unterstützen genau dieses Muster: Ein Bot erkennt, dass für ein gepinntes Basis-Image ein neuer, offiziell signierter Digest existiert, öffnet einen Pull-Request mit dem aktualisierten Digest, und die reguläre CI-Pipeline inklusive Image-Scanning und Signaturverifikation läuft wie bei jeder anderen Änderung. So bleibt Supply Chain Security gewahrt, während Updates trotzdem nicht manuell nachverfolgt werden müssen.

# renovate.json: automatically propose pinned digest updates for Dockerfiles
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "docker": {
    "pinDigests": true
  },
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["digest"],
      "automerge": false,
      "labels": ["supply-chain-security", "base-image-update"]
    }
  ]
}

9. Supply-Chain-Maßnahmen im Vergleich

Die einzelnen Bausteine von Supply Chain Security ergänzen sich, decken aber unterschiedliche Risiken ab. Die folgende Tabelle ordnet sie nach Aufwand und Wirkung ein.

Kein einzelner Baustein reicht für vollständige Supply Chain Security aus. Digest-Pinning ist der schnellste erste Schritt mit sofortiger Wirkung, Cosign-Signierung mit erzwungener Verifikation schließt die größte verbleibende Lücke, und SLSA-Provenance sowie eine kuratierte Registry sind die konsequente Erweiterung für Organisationen mit höheren Compliance-Anforderungen.

10. Zusammenfassung

Supply Chain Security für Docker-Basis-Images beginnt mit der Einsicht, dass Vertrauen in ein Tag keine Sicherheitsgarantie ist. Digest-Pinning macht Basis-Image-Referenzen unveränderlich, Cosign-Signierung mit erzwungener Verifikation erkennt nachträgliche Manipulation, und SLSA-Provenance-Nachweise bestätigen, unter welchen Bedingungen ein Image tatsächlich gebaut wurde. Zusammen ersetzen diese Bausteine implizites Vertrauen durch überprüfbare, kryptographisch abgesicherte Fakten.

Der praktische Einstieg sollte schrittweise erfolgen: Digest-Pinning zuerst, weil es ohne zusätzliche Infrastruktur sofort wirkt, danach Signierung mit erzwungener Verifikation, und erst danach vollständige SLSA-Provenance für Teams mit entsprechenden Compliance-Anforderungen. Jeder dieser Schritte reduziert die Angriffsfläche der eigenen Supply Chain Security, ohne dass alle Schritte gleichzeitig umgesetzt werden müssen.

11. FAQ: Supply Chain Security für Docker-Basis-Images