Ein GPG-Key für Commit-Signing bringt ein eigenes Problem mit. Du musst ihn erzeugen, sichern, auf jeder Maschine verfügbar halten und irgendwann rotieren, bevor er abläuft oder kompromittiert wird. Sigstore gitsign ersetzt den langlebigen Key durch ein kurzlebiges Zertifikat, das du dir bei jedem Signiervorgang per OIDC-Login neu holst. Wie das Rekor-Transparenzlog im Hintergrund funktioniert, das dabei jeden Signiervorgang protokolliert, steht bereits ausführlich in „Merkle-Trees und Transparenz-Logs“ (digital-business.blog, 08.07.) und „Signierte Commits und Artefakte“ (digital-business.blog, 17.06.). Vom Artikel „Container-Images signieren mit cosign“ (24.06.) auf diesem Blog kennst du das Prinzip vielleicht schon. cosign signiert Artefakte und Images keyless über dieselbe Fulcio/Rekor-Infrastruktur, gitsign überträgt dasselbe Prinzip auf Git-Commits. Hier geht es nur um die Praxis, Git umstellen, ersten Commit signieren, Signatur lokal und in CI verifizieren.

Voraussetzungen

Du brauchst Git, einen Browser für den ersten interaktiven Login und einen Account bei einem der von Sigstore unterstützten OIDC-Provider (GitHub, Google oder Microsoft laufen über die öffentliche Sigstore-Instanz).

Schritt 1: gitsign installieren

Über Homebrew:

brew install gitsign

Oder über Go:

go install github.com/sigstore/gitsign@latest

Schritt 2: Git auf gitsign umstellen

Für ein einzelnes Repository:

git config --local gpg.x509.program gitsign
git config --local gpg.format x509
git config --local commit.gpgsign true
git config --local tag.gpgsign true

Für alle Repositories auf der Maschine ersetzt du –local durch –global. Die gitsign-Doku weist explizit darauf hin, dass commit.gpgsign true jeden git commit von einer bestehenden Internetverbindung abhängig macht, weil der Signiervorgang den OIDC-Flow und den Rekor-Eintrag braucht. Wenn du offline arbeitest, lässt du commit.gpgsign aus und signierst gezielt mit git commit -S.

Schritt 3: Ersten Commit keyless signieren

Ein normaler git commit reicht jetzt aus:

git commit --allow-empty --message="Signed commit"

Beim ersten Aufruf öffnet sich dein Browser mit einer URL unter oauth2.sigstore.dev. Du meldest dich mit deinem GitHub-, Google- oder Microsoft-Account an, Sigstore Fulcio stellt danach ein kurzlebiges Signing-Zertifikat aus. Im Beispiel der gitsign-Doku liegt die Gültigkeit zwischen notBefore und notAfter bei rund zehn Minuten, das Zertifikat ist also lange nach dem Signiervorgang nicht mehr gültig. Der Commit landet dabei automatisch im öffentlichen Rekor-Log, das ist der Teil, der in den oben verlinkten Artikeln erklärt ist.

Tags signierst du analog mit git tag -s beziehungsweise tag.gpgsign true.

Schritt 4: Signatur lokal verifizieren

Auf einer frischen Maschine oder einem CI-Runner lohnt sich zuerst ein einmaliges

gitsign initialize

Das lädt den Sigstore-Trust-Root für die Zertifikatsprüfung, statt ihn bei jedem einzelnen verify neu zu holen. Danach:

gitsign verify \
  --certificate-identity=deine@mailadresse.de \
  --certificate-oidc-issuer=https://accounts.google.com \
  HEAD

–certificate-identity und –certificate-oidc-issuer prüfen zusammen, dass der Commit nicht nur kryptografisch intakt ist, sondern von genau der erwarteten Identität über genau den erwarteten Provider signiert wurde. Die Ausgabe zeigt unter anderem Validated Git signature: true, Validated Rekor entry: true und Validated Certificate claims: true. Das ist der Grund, warum gitsign verify dem eingebauten git verify-commit vorzuziehen ist. Git selbst prüft nur die kryptografische Integrität und dass der Rekor-Eintrag existiert, nicht wer ihn erzeugt hat.

Für Tags gibt es den passenden Befehl gitsign verify-tag.

Schritt 5: gitsign verify in der CI-Pipeline

Die Pipeline soll bei jedem Pull Request prüfen, dass alle neuen Commits von erwarteten Identitäten signiert sind. Ein GitHub-Actions-Job dafür:

name: verify-commit-signatures
on:
  pull_request:
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: gitsign installieren
        run: go install github.com/sigstore/gitsign@latest
      - name: Trust-Root initialisieren
        run: gitsign initialize
      - name: Commit-Signaturen prüfen
        run: |
          for sha in $(git rev-list origin/${{ github.base_ref }}..HEAD); do
            gitsign verify \
              --certificate-identity-regexp="@deine-domain\.de$" \
              --certificate-oidc-issuer-regexp="https://(accounts\.google\.com|github\.com/login/oauth)" \
              "$sha"
          done

–certificate-identity-regexp und –certificate-oidc-issuer-regexp sind die Regex-Varianten der beiden Flags aus Schritt 4, damit du nicht für jede Person im Team einen eigenen Aufruf schreiben musst. Findet die Schleife einen Commit, der nicht passt, bricht gitsign verify mit Fehler ab und der Job wird rot.

Alternativ gibt es fertige Community-Actions wie gitsign-verify im GitHub Marketplace, die denselben Loop kapseln. Das sind keine offiziellen Sigstore-Projekte, prüf also selbst, was sie im Detail tun, bevor du sie in eine geschützte Pipeline einbaust.

Schritt 6: Wenn die Pipeline selbst committet

Manche Workflows lassen die CI automatisiert committen, zum Beispiel bei generierten Manifesten. Auch dieser Commit lässt sich keyless signieren, ohne dass ein Mensch im Browser einen Login bestätigt. gitsign erkennt in GitHub Actions automatisch die Ambient-OIDC-Credentials des Runners, wenn du das explizit machst mit:

export GITSIGN_TOKEN_PROVIDER=github-actions

Der Workflow braucht dafür die Berechtigung, sich selbst ein OIDC-Token auszustellen:

permissions:
  id-token: write

Weil es hier keinen menschlichen user.email gibt, verifizierst du automatisierte Commits über die URI-SAN im Zertifikat statt über die E-Mail-SAN. Aktivieren mit:

git config gitsign.matchCommitter true

Und die Git-Identität so setzen, dass sie zur Workflow-Identität im Fulcio-Zertifikat passt, zum Beispiel:

git config user.name "https://myorg/myrepo/path/to/workflow"
git config user.email "1234567890+github-actions@users.noreply.github.com"

Die erste Zeile ist die Identität, gegen die gitsign später verifiziert, die zweite sorgt dafür, dass GitHub den Commit in der Oberfläche als automatisiert erkennt.

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es richtet sich nach der Lage und läuft über drei Felder: Implementation (Delivery/Nachweis modulweise in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten), Maintenance (laufender Betrieb der Nachweise). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst.

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