Eine SBOM beantwortet die Frage, was in einem Artefakt steckt. Sie beantwortet aber nicht die Frage, wie das Artefakt entstanden ist. Genau diese Lücke füllt Provenance. Eine Provenance-Attestierung ist ein signierter Nachweis darüber, aus welchem Quellcode, mit welchem Build-System und mit welcher Konfiguration ein Artefakt gebaut wurde. Wer ein Container-Image oder ein Release-Binary herunterlädt, kann damit prüfen, ob es wirklich aus dem behaupteten Repository stammt.

Was Provenance konkret bedeutet

Technisch ist Provenance ein JSON-Dokument im in-toto-Format. Es enthält den Digest des Artefakts, den Commit, aus dem gebaut wurde, den Builder (zum Beispiel GitHub Actions), den Workflow-Pfad und die Parameter des Builds. Dieses Dokument wird signiert und zusammen mit dem Artefakt veröffentlicht. Die Signatur stellt sicher, dass niemand die Angaben nachträglich verändern kann.

Der Unterschied zum reinen Signieren mit cosign, das ich hier vor zwei Wochen beschrieben habe: eine Signatur sagt nur, dass eine bestimmte Identität das Artefakt signiert hat. Provenance sagt zusätzlich, wie es entstanden ist. Beides zusammen ergibt eine belastbare Aussage.

SLSA in drei Stufen

SLSA (Supply-chain Levels for Software Artifacts, gesprochen wie Salsa) ist das Framework, das diese Nachweise in Stufen ordnet. In Version 1.0 gibt es für den Build-Track drei Level:

• Level 1: Der Build läuft über einen definierten, dokumentierten Prozess und erzeugt Provenance. Die Provenance darf noch unsigniert sein.
• Level 2: Der Build läuft auf einer gehosteten Build-Plattform, die die Provenance signiert. Nachträgliche Manipulation wird damit erkennbar.
• Level 3: Die Build-Plattform isoliert Builds gegeneinander und schützt das Signaturmaterial so, dass auch der Workflow selbst es nicht auslesen kann.

Für die meisten Teams ist Level 2 mit Bordmitteln erreichbar. Level 3 erreicht man bei GitHub Actions über die Reusable Workflows des SLSA-Generators oder über die Plattform-Attestierung in Kombination mit gehärteten Runnern.

Provenance mit GitHub Actions erzeugen

GitHub bringt die Attestierung inzwischen als Plattform-Feature mit. Ein minimales Beispiel für ein Container-Image:

permissions:
  id-token: write
  attestations: write
  packages: write
steps:
  - name: Build and push
    id: push
    uses: docker/build-push-action@v6
    with:
      push: true
      tags: ghcr.io/example/app:1.4.2
  - name: Attest provenance
    uses: actions/attest-build-provenance@v2
    with:
      subject-name: ghcr.io/example/app
      subject-digest: ${{ steps.push.outputs.digest }}
      push-to-registry: true

Die Berechtigung id-token: write ist der entscheidende Punkt. Sie erlaubt dem Workflow, über OIDC ein kurzlebiges Zertifikat von Sigstore zu beziehen. Dauerhafte Signaturschlüssel gibt es in diesem Setup nicht mehr, es kann also auch keiner geleakt werden.

Attestierung prüfen

Der Nachweis nützt nur, wenn ihn jemand prüft. Mit der GitHub CLI geht das in einer Zeile:

gh attestation verify oci://ghcr.io/example/app:1.4.2 --repo example/app

Der Befehl schlägt fehl, wenn das Image nicht aus dem angegebenen Repository stammt oder die Attestierung fehlt. In einem Kubernetes-Cluster lässt sich dieselbe Prüfung mit einer Admission Policy erzwingen, damit nur Images mit gültiger Provenance deployt werden.

Was Provenance nicht leistet

Provenance beweist den Weg, nicht die Qualität. Ein Artefakt kann lückenlos attestiert sein und trotzdem eine Schwachstelle enthalten. Code-Review, Branch Protection und Scans bleiben nötig. Provenance verhindert eine andere Klasse von Angriffen: untergeschobene Artefakte, manipulierte Builds und Releases, die nicht aus dem offiziellen Repository stammen. Der SolarWinds-Angriff lief genau über diesen Weg, kompromittiert wurde dort der Build-Prozess, nicht der Quellcode.

Wer Software an Kunden liefert, bekommt solche Nachweisfragen zunehmend im Vertrieb und in Audits gestellt. Die geschäftliche Seite dieser Nachweispflichten behandle ich drüben auf digital-business.blog.

Wer SBOM, Signatur und Provenance kombiniert, kann für jedes Release drei Fragen beantworten: was drin ist, wer es gebaut hat und wie es entstanden ist. Mehr braucht es für die meisten Lieferketten-Anforderungen erst einmal nicht.