Trusted Builder Architektur

Eine Trusted Builder Architektur ist ein Designprinzip für Software-Lieferketten, bei dem kryptographische Signaturen und Attestierungen ausschließlich innerhalb einer kontrollierten, vertrauenswürdigen Ausführungsumgebung erzeugt werden — nicht in der Pipeline des nutzenden Projekts. Der private Signing-Key verlässt diese Umgebung niemals.

Dadurch wird sichergestellt, dass die Attestierung nicht durch das attestierte Projekt manipuliert werden kann — eine wesentliche Eigenschaft für aussagekräftige Source Provenance Nachweise.

Warum ist das wichtig?

Würde der Signing-Key direkt in der Pipeline des Nutzerprojekts verwendet, könnte jeder mit Schreibzugriff auf das Repository die Pipeline so modifizieren, dass beliebige Attestierungen signiert werden — unabhängig vom tatsächlichen Zustand des Codes. Die Aussagekraft der Attestierung wäre damit wertlos.

Durch die Auslagerung der Signierung in einen unabhängigen, kontrollierten Dienst gilt:

Der Nutzer kann den Inhalt der Attestierung nicht beeinflussen (nur Repository-URL und Commit-Referenz werden übergeben)
Der Nutzer hat keinen Zugriff auf den privaten Schlüssel
Die Attestierung ist unabhängig verifizierbar — jeder kann sie mit dem öffentlichen Schlüssel prüfen

Architektur des openCode Attestierungsservices

Die aufrufende Pipeline erhält lediglich das fertige DSSE-Artefakt und lädt es in die OCI Registry. Kein privater Schlüssel wird dabei benötigt oder übertragen.

Warum ein Downstream-Pipeline-Ansatz?

Einige GitLab APIs, die für die Erfassung der Source Provenance Daten benötigt werden (z.B. Merge Request Informationen, Protected Branch Status), erfordern eine Autorisierung. Der Attestierungsservice enthält die notwendigen Zugriffsrechte (Project Access Token) — die aufrufende Pipeline benötigt diese Berechtigungen nicht und erhält sie auch nicht.

Da bei GitLab Multi-Project-Pipelines immer die .gitlab-ci.yml des Zielprojekts verwendet wird, ist ein Downstream-Trigger die einzige Möglichkeit, die kontrollierte Ausführungsumgebung des Attestierungsservices zu nutzen. Die CI Komponente richtet diesen Trigger automatisch ein.

Verifikation

Die Attestierung kann von jedem mit dem öffentlichen Schlüssel des Attestierungsservice-Betreibers verifiziert werden — unabhängig von der aufrufenden Pipeline und ohne Vertrauen in das Nutzerprojekt voraussetzen zu müssen.

Eine Anleitung zur Einbindung des Attestierungsservices finden Sie in der How-to-Anleitung zur Source Provenance Attestierung.

Umsetzung und Ausblick

Aktuell ist die Trusted Builder Architektur im openCode Badge-System für den Source Track implementiert: Die Source Provenance Attestierung wird ausschließlich innerhalb des kontrollierten Attestierungsservices erzeugt und signiert. Dies schafft unverfälschbare Provenance Attestierungen, da weder der Inhalt noch die Signatur durch das attestierte Projekt beeinflusst werden können.

Diese Architektur ist keine Anforderung des SLSA Source Tracks — der Source Track setzt auf technische Kontrollen durch das Versionskontrollsystem selbst. Die Trusted Builder Architektur ist eine darüber hinausgehende Maßnahme, die die Vertrauenswürdigkeit der Attestierungen erheblich stärkt: Selbst wenn ein Projekt kompromittiert wird, können die bereits ausgestellten Attestierungen nicht nachträglich manipuliert werden.

Es ist geplant, die Build Provenance in Zukunft ebenfalls auf diese Architektur zu migrieren, um die gleichen Sicherheitsgarantien auch für den Build Track zu erreichen.

Mehr zur technischen Umsetzung und dem Hintergrund der Trusted Builder Architektur finden Sie in der DevGuard Dokumentation.