Dein Blog zum Thema digitales Business

Signaturen klingen nach Aufwand, der sich nur für große Konzerne rechnet. Das stimmt so nicht. Ein signierter Commit oder ein signiertes Build-Artefakt beantwortet eine einfache Frage: Stammt dieser Code oder dieses Paket wirklich von dem, der behauptet es gebaut zu haben? Wer das nicht belegen kann, vertraut blind. Die eigentliche Frage ist nicht ob, sondern wo sich der Aufwand zuerst auszahlt.

Was eine Signatur technisch leistet

Eine Signatur bindet einen Inhalt an einen privaten Schlüssel. Bei Git signierst du einen Commit oder ein Tag mit GPG, SSH oder per Sigstore. Beim Build signierst du das fertige Artefakt, also das Container-Image, das Paket oder die Binary. In beiden Fällen entsteht ein kryptografischer Nachweis, den jeder mit dem passenden öffentlichen Schlüssel prüfen kann. Manipuliert jemand den Inhalt nachträglich, bricht die Prüfung. Das ist der ganze Mechanismus. Kein Tool-Zoo, kein Prozess-Overhead, sondern eine Ja-Nein-Antwort auf die Frage nach der Herkunft.

Wann sich signierte Commits lohnen

Signierte Commits zeigen, dass eine Änderung tatsächlich von einem bestimmten Entwickler kommt und nicht von jemandem, der sich seinen Namen in die Git-Konfiguration geschrieben hat. Das ist relevant, sobald mehrere Leute an einem Repo arbeiten und du wissen willst, wer was eingebracht hat. Besonders sinnvoll wird es bei externen Beiträgen, bei Open-Source-Projekten mit fremden Pull Requests und überall dort, wo eine Branch-Protection-Regel echte Autorenschaft erzwingen soll.

GitHub und GitLab zeigen signierte Commits mit einem Verified-Hinweis an. Das kostet einmalig Einrichtung pro Entwickler und danach fast nichts. Wenn dein Team größer als zwei Personen ist und du Code an Kunden oder in regulierte Umgebungen lieferst, ist das der erste Hebel.

Wann signierte Artefakte wichtiger sind

Commits sagen etwas über den Quellcode aus. Was am Ende läuft, ist aber das Build-Artefakt, und zwischen Code und Artefakt liegt die Pipeline. Genau dort setzen die meisten Lieferketten-Angriffe an. Ein signiertes Artefakt belegt, dass das Image oder Paket aus deinem Build-System stammt und nicht unterwegs ausgetauscht wurde.

Sobald du Software ausrollst, die jemand anderes betreibt, ob Kunde, Plattform oder interne Produktion, wird die Artefakt-Signatur zum entscheidenden Nachweis. Mit Sigstore und cosign signierst du ein Container-Image in wenigen Zeilen in der Pipeline, ohne eigene Schlüsselverwaltung. Der Empfänger prüft die Signatur vor dem Deployment. Wer ausliefert, sollte hier vor den Commits ansetzen.

Wann du es noch lassen kannst

Bei einem Solo-Projekt ohne externe Beiträge und ohne Auslieferung an Dritte bringt eine Signatur wenig zusätzliche Sicherheit. Auch ein Prototyp, der nie produktiv geht, braucht keinen kryptografischen Herkunftsnachweis. Signaturen sind kein Selbstzweck. Sie lohnen sich genau dann, wenn jemand außer dir dem Ergebnis vertrauen muss und du diesen Vertrauensvorschuss belegen können willst.

Der pragmatische Einstieg

Fang nicht mit einer großen Schlüssel-Infrastruktur an. Aktiviere signierte Commits für dein Kernteam, signiere die Artefakte deiner wichtigsten Pipeline mit cosign und prüfe die Signatur im Deployment-Schritt. Drei Schritte, ein paar Stunden Arbeit, danach hast du einen prüfbaren Herkunftsnachweis vom Commit bis zum laufenden Artefakt. Den Rest baust du aus, wenn der Bedarf da ist.

Du willst wissen, wo deine Pipeline beim Thema Herkunft und Integrität steht? Der GitSecOps QuickCheck prüft genau das: signierte Commits, Artefakt-Integrität, Pipeline-Härtung und mehr. Festpreis 1.990 Euro netto, Ergebnis in 3 Werktagen, klare Befunde statt Folienware. Kontakt: mm@crank.zone.