Image Signing und SBOM mit Cosign und Syft

1. Warum Image Signing und SBOM zusammengehören

Image Signing beantwortet die Frage, ob ein Container Image tatsächlich von einer vertrauenswürdigen Quelle stammt und seit dem Build unverändert geblieben ist. Eine SBOM, die Software Bill of Materials, beantwortet die andere Frage: aus welchen Paketen, Bibliotheken und Versionen besteht das Image überhaupt. Beide Konzepte adressieren unterschiedliche Risiken in der Supply Chain und ergänzen sich, statt sich zu ersetzen.

Ohne Image Signing kann ein Angreifer, der Zugriff auf eine Registry erlangt, ein manipuliertes Image unter demselben Tag unterschieben, ohne dass Deployment-Prozesse dies bemerken. Ohne SBOM weiß niemand im Team, welche Version von OpenSSL oder welche transitiven Composer-Abhängigkeiten tatsächlich im laufenden Produktions-Container stecken, wenn eine neue kritische CVE öffentlich wird. Vorfälle wie der SolarWinds-Angriff und die Log4Shell-Lücke haben beide Themen von einer Nische zur regulatorischen Anforderung gemacht, etwa im Rahmen der EU Cyber Resilience Act und von Executive Order 14028 in den USA.

Das Sigstore-Projekt, ursprünglich von Google, Red Hat und der Linux Foundation initiiert, liefert mit Cosign das Standardwerkzeug für Image Signing ohne eigene Public-Key-Infrastruktur, während Syft von Anchore als das verbreitetste Werkzeug zur SBOM-Generierung aus Container Images gilt. Zusammen bilden sie das Fundament moderner Supply-Chain-Sicherheit für Docker-Workflows.

2. Cosign: Grundlagen des Image Signing

Cosign signiert ein Container Image, indem es über den Image-Digest, nicht über den Tag, eine kryptografische Signatur erzeugt und diese als separates OCI-Artefakt neben dem Image in derselben Registry ablegt. Der Digest ist entscheidend, weil Tags veränderlich sind, ein Angreifer könnte denselben Tag auf einen anderen Digest umbiegen. Die Signatur bindet sich an den unveränderlichen SHA256-Digest des Manifests und macht jede nachträgliche Manipulation erkennbar.

Der klassische Ansatz mit einem privaten Schlüsselpaar erfordert, dass Teams den privaten Schlüssel sicher verwahren, etwa in einem Hardware Security Module oder einem Secrets-Manager wie HashiCorp Vault. Cosign unterstützt sowohl lokale Schlüsseldateien als auch Cloud-KMS-Integrationen bei AWS, GCP und Azure, was den Schlüssel selbst nie auf der Festplatte des CI-Runners im Klartext ablegt.

# Generate a local key pair for image signing (protected by a passphrase)
cosign generate-key-pair
# Produces cosign.key (private, encrypted) and cosign.pub (public)

# Sign an image by its digest, not by its mutable tag
cosign sign --key cosign.key \
  registry.mironsoft.de/shop-app@sha256:3f29a1c8b7...

# Verify the signature against the public key before deployment
cosign verify --key cosign.pub \
  registry.mironsoft.de/shop-app@sha256:3f29a1c8b7...

3. Keyless Signing mit Sigstore und OIDC

Das eigentliche Alleinstellungsmerkmal von Cosign ist Keyless Signing, das die klassische Schlüsselverwaltung durch kurzlebige Zertifikate ersetzt. Statt eines langlebigen privaten Schlüssels authentifiziert sich der CI-Runner per OIDC-Token, etwa über die native GitHub-Actions- oder GitLab-CI-Identität, bei Fulcio, der Sigstore-Zertifizierungsstelle. Fulcio stellt ein wenige Minuten gültiges Zertifikat aus, mit dem die Signatur erzeugt wird, und protokolliert den gesamten Vorgang unveränderlich im transparenten Rekor-Log.

Der Vorteil gegenüber klassischem Image Signing: Es gibt keinen langlebigen privaten Schlüssel mehr, den ein Angreifer stehlen könnte. Die Vertrauenskette basiert stattdessen auf der Identität des CI-Systems selbst, verifizierbar über den öffentlichen Rekor-Transparenz-Log, den jeder einsehen kann, ohne dass Mironsoft oder ein Kunde eigene Zertifikatsinfrastruktur betreiben muss.

# Keyless signing: authenticates via OIDC (e.g. GitHub Actions identity)
# No private key file needed, Fulcio issues a short-lived certificate
cosign sign registry.mironsoft.de/shop-app@sha256:3f29a1c8b7...

# Verify keyless signature, checking issuer and expected identity
cosign verify \
  --certificate-identity="https://github.com/mironsoft/shop-app/.github/workflows/build.yml@refs/heads/main" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  registry.mironsoft.de/shop-app@sha256:3f29a1c8b7...

4. Syft: eine SBOM aus einem Image erzeugen

Syft analysiert die Layer eines Container Images und erkennt darin installierte Betriebssystempakete, Composer-Abhängigkeiten, npm-Pakete, Python-Wheels und Dutzende weitere Paket-Ökosysteme, ganz ohne Zugriff auf den ursprünglichen Quellcode oder Build-Prozess. Das Ergebnis ist eine vollständige SBOM, die jede gefundene Komponente mit exakter Versionsnummer und Ursprungsschicht auflistet.

Für PHP-Projekte erkennt Syft sowohl composer.lock-Einträge als auch tatsächlich installierte Paketdateien im vendor-Verzeichnis, was Diskrepanzen zwischen deklarierten und tatsächlich ausgelieferten Abhängigkeiten aufdeckt. Diese Fähigkeit, direkt aus dem fertigen Image statt aus Quelldateien zu analysieren, macht Syft zum bevorzugten Werkzeug für nachträgliche SBOM-Generierung bei bereits gebauten Images.

# Generate an SBOM directly from a built image, in SPDX JSON format
syft registry.mironsoft.de/shop-app@sha256:3f29a1c8b7... \
  -o spdx-json > shop-app-sbom.spdx.json

# List detected package ecosystems in a human readable table
syft registry.mironsoft.de/shop-app:1.4.0 -o table

# Example output includes rows like:
#   NAME              VERSION   TYPE
#   symfony/console   7.1.0     php-composer
#   openssl           3.0.13    deb

5. SBOM-Formate: SPDX und CycloneDX im Vergleich

Für SBOM-Dokumente haben sich zwei konkurrierende, beide von großen Standardisierungsgremien getragene Formate durchgesetzt. SPDX, gepflegt von der Linux Foundation, stammt ursprünglich aus dem Lizenz-Compliance-Umfeld und ist inzwischen ISO-standardisiert unter ISO/IEC 5962. CycloneDX, entwickelt von OWASP, ist von Anfang an auf Sicherheitsanwendungsfälle wie Schwachstellenkorrelation zugeschnitten und enthält zusätzliche Felder für Vulnerability-Referenzen direkt im Dokument.

Syft unterstützt beide Formate nativ über einfache Ausgabe-Flags, sodass die Wahl meist von den Anforderungen nachgelagerter Werkzeuge abhängt, etwa ob ein Scanner oder eine Compliance-Plattform ein bestimmtes Format erwartet. Für regulatorische Anforderungen in der EU wird zunehmend SPDX referenziert, während viele Sicherheits-Tools wie Grype nativ CycloneDX bevorzugen.

6. Attestations: SBOM als signiertes Anhängsel am Image

Eine unsignierte SBOM-Datei allein ist wenig wert, weil sie nachträglich verändert werden könnte, ohne dass jemand es bemerkt. Cosign löst dieses Problem, indem es die SBOM als In-Toto-Attestation direkt mit dem Image-Digest verknüpft und signiert. Diese Attestation wird, wie die Signatur selbst, als OCI-Artefakt in der Registry neben dem Image gespeichert und lässt sich zusammen mit dem Image ziehen und verifizieren.

Der Vorteil dieser Verknüpfung: Wer das Image zieht, kann in einem einzigen Schritt sowohl die Herkunft über Image Signing als auch den exakten Inhalt über die signierte SBOM-Attestation überprüfen, ohne separate Dateien verwalten oder manuell zuordnen zu müssen.

# Attach a signed SBOM attestation to the image digest
cosign attest --predicate shop-app-sbom.spdx.json \
  --type spdxjson \
  --key cosign.key \
  registry.mironsoft.de/shop-app@sha256:3f29a1c8b7...

# Download and verify the attached SBOM attestation
cosign verify-attestation --key cosign.pub \
  --type spdxjson \
  registry.mironsoft.de/shop-app@sha256:3f29a1c8b7...

7. Verifikation erzwingen: Policy-Controller in Kubernetes

Signieren allein bringt keinen Sicherheitsgewinn, wenn niemand die Signatur beim Deployment tatsächlich prüft. In Kubernetes-Umgebungen übernimmt der Sigstore Policy Controller diese Aufgabe als Admission-Webhook, der jeden neuen Pod-Start abfängt und das referenzierte Image gegen eine hinterlegte Policy verifiziert, bevor der Scheduler den Pod überhaupt startet. Fehlt eine gültige Signatur oder stimmt die Identität nicht mit der erwarteten Pipeline überein, wird der Pod-Start abgelehnt.

Diese erzwungene Verifikation schließt die Lücke zwischen dem reinen Vorhandensein einer Signatur und ihrer tatsächlichen Durchsetzung. Ohne einen Policy-Controller bleibt Image Signing eine reine Dokumentationsmaßnahme, mit Policy-Controller wird es zu einer aktiven Kontrolle, die kompromittierte oder unautorisierte Images in der Produktion technisch verhindert.

8. CI-Pipeline: Bauen, Signieren, SBOM anhängen

In einer vollständigen CI-Pipeline laufen Build, Signierung und SBOM-Erzeugung als aufeinanderfolgende Schritte direkt nach dem Push in die Registry. Reihenfolge und Automatisierung sind hier entscheidend: Ein manueller Zwischenschritt, bei dem ein Entwickler das Image lokal signiert, widerspricht dem Grundgedanken von Keyless Signing, das gerade auf die verifizierbare Identität des automatisierten CI-Systems setzt.

Wichtig ist zudem, dass das Fail-Verhalten der Pipeline definiert wird: Ein Build ohne gültige Signatur oder ohne erzeugte SBOM sollte den Deployment-Schritt blockieren, statt nur eine Warnung zu protokollieren, sonst bleibt die Kontrolle rein kosmetisch.

# GitHub Actions: build, sign keyless, attach SBOM as attestation
build-sign-sbom:
  runs-on: ubuntu-latest
  permissions:
    id-token: write   # required for keyless OIDC signing
    contents: read
  steps:
    - uses: actions/checkout@v4
    - name: Build and push image
      run: |
        docker build -t registry.mironsoft.de/shop-app:${{ github.sha }} .
        docker push registry.mironsoft.de/shop-app:${{ github.sha }}
    - name: Sign image keyless
      run: cosign sign --yes registry.mironsoft.de/shop-app:${{ github.sha }}
    - name: Generate SBOM with Syft
      run: syft registry.mironsoft.de/shop-app:${{ github.sha }} -o spdx-json > sbom.json
    - name: Attach signed SBOM attestation
      run: cosign attest --yes --predicate sbom.json --type spdxjson \
        registry.mironsoft.de/shop-app:${{ github.sha }}

9. Signaturmethoden und SBOM-Formate im Vergleich

Die Wahl zwischen klassischem Schlüssel-basiertem Signing und Keyless Signing, sowie zwischen SPDX und CycloneDX für die SBOM, hängt von organisatorischen und regulatorischen Rahmenbedingungen ab. Die folgende Tabelle stellt die wichtigsten Optionen gegenüber.

Für die meisten neuen CI-Pipelines ist Keyless Signing der pragmatischere Standard, weil kein privater Schlüssel mehr rotiert, gesichert oder versehentlich geleakt werden kann. Air-gapped Umgebungen ohne Internetzugang zum öffentlichen Fulcio- und Rekor-Dienst benötigen jedoch weiterhin klassisches Schlüssel-basiertes Signing oder eine private Sigstore-Instanz.

10. Zusammenfassung

Image Signing und SBOM Grundlagen ergänzen sich als zwei Seiten derselben Supply-Chain-Sicherheit: Signing beweist Herkunft und Unversehrtheit eines Images über den unveränderlichen Digest, eine SBOM listet transparent jede enthaltene Komponente auf. Cosign aus dem Sigstore-Ökosystem ermöglicht sowohl klassisches Schlüssel-basiertes Signing als auch Keyless Signing über OIDC-Identität und das öffentliche Rekor-Transparenz-Log, ganz ohne eigene Public-Key-Infrastruktur.

Syft erzeugt aus einem fertigen Image eine vollständige SBOM in SPDX oder CycloneDX, die als signierte Attestation direkt am Image-Digest verankert werden kann. Erst ein Policy-Controller in Kubernetes macht aus der reinen Möglichkeit der Verifikation eine tatsächlich erzwungene Kontrolle, die unsignierte oder unbekannte Images vom produktiven Deployment ausschließt.

11. FAQ: Image Signing und SBOM mit Cosign und Syft