GitHub Attestations und cosign erzeugen beide Sigstore-Signaturen. Die Frage ist deshalb nicht, ob du signierst, sondern wer die Vertrauensinfrastruktur betreibt und wer am Ende prüft. Warum Herkunftsnachweise überhaupt nötig sind, steht in Provenance und SLSA, in Provenance und Attestation und in der Kyverno-Durchsetzung im Cluster. Das cosign-Handwerk steht im cosign-Beitrag vom 24.06.. Wie sich Sigstore ohne Schlüsselverwaltung bei Commits anfühlt, zeigt gitsign in der Praxis. Dieser Beitrag klärt nur die Entscheidung dazwischen.

Was GitHub Attestations übernimmt

Der Workflow holt per OIDC ein kurzlebiges Zertifikat, Signatur und Ablage übernimmt die Action. Welche Sigstore-Instanz dahinter steht, hängt laut GitHub-Doku von der Sichtbarkeit des Repositories ab. Öffentliche Repositories nutzen die Sigstore Public Good Instance. Eine Kopie des Bundles liegt bei GitHub, zusätzlich landet es in einem öffentlich lesbaren Transparency Log. Private Repositories nutzen GitHubs eigene Sigstore-Instanz: gleiche Codebasis, aber ohne Transparency Log und nur für GitHub Actions föderiert.

Ein Image attestierst du so:

permissions:
  id-token: write
  contents: read
  attestations: write
  packages: write
steps:
  # im Beispiel zur Lesbarkeit als Tag, in echten Workflows auf den Commit-SHA pinnen
  - uses: actions/attest@v4
    with:
      subject-name: ghcr.io/ORG/IMAGE
      subject-digest: ${{ steps.push.outputs.digest }}
      push-to-registry: true

actions/attest-build-provenance erzeugt dasselbe. Ab Version 4 ist es laut README nur noch ein Wrapper auf actions/attest, neue Implementierungen sollen actions/attest verwenden. Wie du Actions per SHA pinnst, steht in GitHub Actions absichern.

Die Voraussetzung, die vor der Technik kommt

Attestations gibt es für öffentliche Repositories in allen aktuellen Plänen. Wer GitHub Free, Pro oder Team nutzt, bekommt sie nur dort. Für private und interne Repositories verlangt die Doku GitHub Enterprise Cloud. Bevor du Verfahren vergleichst, prüfst du also den Plan.

Prüfen mit gh attestation verify

gh attestation verify oci://ghcr.io/ORG/IMAGE:TAG \
  --repo ORG/REPO \
  --signer-workflow ORG/REPO/.github/workflows/release.yml

Für oci:// musst du an der Registry angemeldet sein. Laut CLI-Handbuch verlangt der Befehl mindestens --owner oder --repo. Präziser wird die Prüfung mit --signer-workflow. Standardmäßig erzwingt er den Predicate-Typ https://slsa.dev/provenance/v1. --deny-self-hosted-runners lässt Attestierungen von selbst betriebenen Runnern durchfallen. Bei cosign legst du die erwartete Identität mit --certificate-identity und --certificate-oidc-issuer fest (Doku).

Offline-Prüfung ist bei GitHub dokumentiert. Dafür gibt es gh attestation download, gh attestation trusted-root und --bundle mit --custom-trusted-root (Doku). Ein abgeschottetes Netz allein ist damit für sich genommen kein Grund für einen eigenen Stack. Die Trusted-Root-Datei hat kein eingebautes Ablaufdatum. Was danach signiert wird, prüfst du nur bis zur nächsten Schlüsselrotation der Instanz (laut Doku einige Male pro Jahr), und Widerrufe siehst du offline nicht.

Wann du bei GitHub bleibst

• Der Build läuft in GitHub Actions, die Repositories sind öffentlich oder du hast Enterprise Cloud.
• Du lieferst Binaries oder Container-Images, deren Konsumenten gh einsetzen können.
• Du willst keine Signatur-Infrastruktur betreiben.

Attestations liefern für sich genommen SLSA v1.0 Build Level 2. Für Level 3 nennt GitHub einen wiederverwendbaren Workflow, den viele Repositories teilen (Doku). Dann ist die Signatur-Identität dieser Workflow, und --signer-workflow oder --signer-repo wird Pflicht. Gehärtete Runner nennt die GitHub-Doku für Level 3 nicht; maßgeblich ist der wiederverwendbare Workflow.

Wann cosign die bessere Wahl ist

1. Privates Repository ohne Enterprise Cloud. Attestations entfallen. cosign keyless nutzt die öffentliche Sigstore-Instanz, die laut Sigstore-Doku allen Entwicklern offensteht. Beachte die Kehrseite: Digest, Signatur und Zertifikat landen in einem öffentlich auditierbaren Log (Doku), und laut Fulcio-Doku enthält das OIDC-Token Angaben zu Workflow und Quell-Repository, die ins Zertifikat übernommen werden. Daraus folgt, dass bei privatem Code die Workflow-Identität öffentlich sichtbar wird. Das ist eine Schlussfolgerung aus diesen Angaben, keine ausdrückliche Aussage der Doku. Ob du das akzeptierst, klärst du vorher.
2. CI außerhalb von GitHub Actions. GitHubs private Instanz föderiert nur mit GitHub Actions. Die öffentliche Sigstore-Instanz führt dagegen unter den unterstützten OIDC-Issuern auch GitLab CI/CD auf (siehe Fulcio-Doku).
3. Eigene Kontrolle über Fulcio, Rekor und Trust Root. Das geht, ist aber Betrieb. cosign verifiziert dann gegen eine eigene TUF-Wurzel oder eine Trusted-Root-Datei, ab cosign v3 mit Signing-Config (Doku). Als Ausgangspunkt nennt die Doku das scaffolding-Projekt.

Zum dritten Punkt gehört die ehrliche Rechnung. Laut Sicherheitsmodell kann Fehlverhalten von Rekor oder Fulcio unentdeckt bleiben, wenn niemand die Logs überwacht, und Fulcio überwacht sein Zertifikatslog nicht selbst. Die öffentliche Rekor-Instanz nennt einen SLO von 99,5 % Verfügbarkeit (Doku). Als Vergleichsmaßstab für deinen eigenen Betrieb taugt das.

Was beide nicht lösen

GitHub warnt selbst: Eine Attestierung garantiert keine sichere Software, sie verknüpft das Artefakt mit Quellcode und Build-Anweisung. Sie nützt außerdem erst, wenn jemand sie prüft. Laut CLI-Handbuch kann der erzeugende Workflow nur signature.certificate und verifiedTimestamps nicht manipulieren. Der Inhalt von statement.predicate lässt sich fälschen, wenn ein Angreifer den Ausführungskontext des Workflows kontrolliert. Als Gegenmittel nennt das Handbuch einen vertrauenswürdigen Builder, also Build und Signatur in einem wiederverwendbaren Workflow, dessen Ausführung sich nicht durch Eingaben des aufrufenden Workflows beeinflussen lässt.

Im Cluster erzwingst du GitHub-Attestierungen mit dem Sigstore Policy Controller und dem Helm-Chart trust-policies (Doku). Attestierungen zu Artefakten, denen Konsumenten nicht mehr vertrauen sollen, kannst du löschen. Wer eine Prüfung eingerichtet hat, kann das Artefakt danach nicht mehr verwenden (Doku).

Einordnung

Der Wechsel zu cosign lohnt sich, wenn dir der Plan fehlt, wenn du nicht auf GitHub Actions baust oder wenn du die Trust Root selbst halten musst. In allen anderen Fällen übernimmst du mit einem eigenen Stack Betrieb und Log-Überwachung selbst. Fang mit Attestations an und wechsle, wenn eines dieser drei Kriterien konkret zutrifft.

Diesen Beitrag gibt es auch auf Englisch: GitHub Attestations or Cosign: When the Switch Pays Off.

Fragen oder Anmerkungen zu diesem Setup: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.