Wie schützen Artefakt-Signierung und Provenienz die Software-Lieferkette?
Kurzantwort
Die Signierung bindet ein Artefakt kryptografisch an seinen Hersteller, sodass Konsumenten überprüfen können, dass es nicht manipuliert oder ausgetauscht wurde. Die Provenienz sind signierte Metadaten, die beschreiben, wie, wo und aus welcher Quelle das Artefakt gebaut wurde. Zusammen — über Tools wie Sigstore für schlüssellose Signierung und das SLSA-Framework für Provenienzstufen — ermöglichen sie es einem Deployer zu überprüfen, dass ein Image aus der erwarteten Pipeline und Quelle stammt, und vereiteln so Manipulation und Angriffe durch Abhängigkeitssubstitution.
Lieferkettenangriffe funktionieren, indem sie Sie dazu bringen, etwas auszuführen, dem Sie vertrauen, aber nicht sollten — eine manipulierte Binärdatei, ein bösartiger Build, eine ausgetauschte Abhängigkeit. Signierung und Provenienz erlauben es Ihnen, Vertrauen zu überprüfen, statt es anzunehmen.
Signierung: Wer hat das gemacht?
Die Artefakt-Signierung erzeugt eine kryptografische Signatur über ein Artefakt (ein Container-Image, ein Paket, eine Binärdatei). Ein Konsument überprüft die Signatur, um zwei Dinge zu bestätigen: Das Artefakt stammt vom erwarteten Hersteller und es wurde seit der Signierung nicht verändert. Die traditionelle Signierung kämpft mit dem Schlüsselmanagement — langlebige private Schlüssel gehen verloren oder werden gestohlen. Sigstore begegnet dem mit schlüsselloser Signierung: Es verwendet kurzlebige Zertifikate, die an eine OIDC-Identität gebunden sind (z. B. die Identität eines CI-Workflows), und zeichnet Signaturen in einem öffentlichen Transparenz-Log (Rekor) auf, sodass es keinen langfristigen Schlüssel zu schützen gibt und jede Signatur prüfbar ist.
Provenienz: Wie wurde das gemacht?
Eine Signatur allein sagt nicht, wie ein Artefakt gebaut wurde. Die Provenienz sind signierte, manipulationssichere Metadaten, die den Build bezeugen: welcher Quell-Commit, welcher Builder, welche Eingaben und Parameter. Das SLSA-Framework definiert ansteigende Stufen von Provenienz und Build-Integrität, sodass Sie sagen können «dieses Artefakt hat eine überprüfbare Provenienz aus einer gehärteten, nicht fälschbaren Build-Pipeline».
In die Praxis umsetzen
Die beiden kombinieren sich zur Deploy-/Admission-Zeit: Eine Richtlinie überprüft, dass das Image von der erwarteten Identität signiert ist und eine Provenienz trägt, die auf das erwartete Quell-Repository und den erwarteten Builder verweist. Ein Angreifer, der ein bösartiges Image einschleust, kann das nicht fälschen, sodass das Deployment blockiert wird. Genau das vereitelt Vorfälle wie ein vergiftetes Build-Artefakt, das in die Produktion gelangt.
Worauf Interviewer achten
Sie wollen, dass Signierung (Integrität + Identität) und Provenienz (Build-Herkunft) klar getrennt werden, das Bewusstsein für das schlüssellose Modell von Sigstore und die SLSA-Stufen sowie den Durchsetzungspunkt «Überprüfung bei der Admission».
Wahrscheinliche Anschlussfragen
- Welches Problem löst die schlüssellose Signierung von Sigstore?
- Was stellen die SLSA-Stufen tatsächlich dar?
- An welcher Stelle im Deploy-Ablauf überprüft man Signaturen und Provenienz?