Eine praktische Docker-Image-Supply-Chain: signiert, gescannt, attestiert

„Mein Image besteht den Scan" ist keine Supply Chain. Eine Supply Chain ist belegbare Abstammung vom Quell-Commit bis zum laufenden Container. Hier ist das Minimum, das wir für jeden Kunden ausliefern.

Die vier Artefakte

Für jedes Image, das wir bauen, erzeugen wir:

1. Das Image selbst, unveränderlich getaggt (Commit-SHA, nicht latest)
2. Ein SBOM (Software Bill of Materials) im SPDX- oder CycloneDX-Format
3. Einen Vulnerability-Scan-Report (Trivy oder Grype)
4. Eine Signatur (Cosign) über das Digest + eine signierte Attestation, die Image, SBOM, Scan und Commit verknüpft

All das wird neben dem Image in die Registry gepusht, unter OCI-Standard-Relationen.

Build-Pipeline

In GitHub Actions:

- run: docker buildx build --output type=registry,name=${IMG} .
- run: syft ${IMG} -o cyclonedx-json > sbom.json
- run: trivy image --format json ${IMG} > scan.json
- run: cosign sign --yes ${IMG}
- run: cosign attest --predicate sbom.json --type cyclonedx --yes ${IMG}
- run: cosign attest --predicate scan.json --type vuln --yes ${IMG}

Keyless Signing via Fulcio + Rekor bedeutet, dass die signierende Identität das GitHub-Actions-OIDC-Token ist. Keine langlebigen Schlüssel zu rotieren.

Admission-Policy

Der Kubernetes-Cluster betreibt Kyverno (oder OPA Gatekeeper) mit einer Policy, die jeden Pod ablehnt, dessen Image:

• Nicht von einer erwarteten Identität signiert ist (die Workload-Identität der Build-Pipeline)
• Eine kritische CVE in seiner Scan-Attestation hat, die älter als 7 Tage ist
• Überhaupt keine SBOM-Attestation hat

Das bedeutet, ein Entwickler kann kein unsigniertes Image in Produktion pushen, selbst mit kubectl apply-Rechten. Der Cluster lehnt den Pod ab, bevor er gescheduled wird.

Was wir monitoren

• Neue CVEs, die bereits deployte Images betreffen (Trivy-DB wird täglich aktualisiert; wir re-scannen in-place)
• Images in Produktion, die seit N Tagen nicht neu gebaut wurden
• Signatur-Verifikationsfehler (Alerts an PagerDuty)
• Drift zwischen dem Build-Zeitpunkt-SBOM und dem tatsächlich laufenden Stand (meist ein hineingeschmuggeltes apt install)

Der vollständige Beitrag auf Medium enthält die Kyverno-Policies wortwörtlich, das Cosign-Keyless-Setup und das Dashboard, mit dem wir die Signatur-Abdeckung im gesamten Bestand verfolgen.