Software-Supply-Chain-Integrität

Reproduzierbare Builds

DevGuard OCI-Images werden mit Nix gebaut. Bei identischer Quell- und Abhängigkeitsmenge erzeugt Nix deterministisch bitgenaue Ausgaben und erfüllt damit die formale Definition von reproducible-builds.org.

Warum reproduzierbare Builds wichtig sind

GitHub Actions läuft auf Infrastruktur in den USA - openCode läuft auf souveräner deutscher Behördeninfrastruktur. Wenn beide unabhängigen Build-Umgebungen denselben SHA-256-Digest erzeugen, ist das ein kryptografischer Beweis, dass keine Manipulation während des Build-Prozesses stattgefunden hat — und adressiert direkt das SLSA Supply-Chain-Bedrohungsmodell für Kompromittierungen auf Build-Ebene.

Manipulationsnachweis

Jede Injektion während des Build-Prozesses — Compiler-Backdoor, kompromittierte Abhängigkeit oder manipulierter CI-Runner — würde das Ausgabe-Binary verändern und einen abweichenden SHA-256-Digest erzeugen. Übereinstimmende Digests über unabhängige Umgebungen sind ein kryptografischer Beweis für einen unveränderten Build.

Unabhängige Verifizierung

Zwei unabhängige Build-Umgebungen unter separater administrativer Kontrolle bilden ein N-of-M-Verifikationsmodell: Ein Supply-Chain-Angreifer müsste beide Infrastrukturanbieter gleichzeitig kompromittieren — über verschiedene Jurisdiktionen hinweg — um unentdeckt zu bleiben.

Nix-gestützt

Nix modelliert jeden Build-Prozess als reine Funktion über einem inhaltsadressierten Input-Closure. Jede Abhängigkeit ist im Nix-Store auf einen kryptografischen Hash festgelegt, was Nicht-Determinismus durch Timestamps, Locale-Einstellungen und variable Abhängigkeitsauflösung eliminiert.

Live-Digest-Verifizierung

OCI-Image-Digests werden live aus beiden Registries abgerufen und verglichen. Ein übereinstimmender SHA-256-Digest über unabhängige Build-Umgebungen hinweg ist eine notwendige Bedingung für die Build-Integrität.

Signaturen und Attestierungen

Jedes veröffentlichte Image wird über Sigstore/Cosign signiert. Jedes Release enthält zusätzlich SLSA-Provenance-Attestierungen im in-toto-Prädikat-Format, eine VEX-Attestierung und eine CycloneDX-SBOM-Attestierung — für eine unabhängige Verifizierung dessen, was gebaut wurde, aus welcher Quell-Revision, unter welcher Build-Umgebung und welche bekannten Schwachstellen enthalten sind.

Signierte Images

Jeder Image-Digest wird mit Cosign gegen einen statischen öffentlichen Schlüssel signiert. Die Signaturverifizierung bindet den Digest kryptografisch an den Schlüsselinhaber und macht unautorisierte Image-Substitutionen erkennbar.

Build-Provenance

SLSA-Provenance-Attestierungen im in-toto-Prädikat-Format zeichnen die exakte Quell-Revision, Build-Plattform und den Einstiegspunkt auf. Sie ermöglichen es einem Prüfer, die vollständige Build-Provenance-Kette nachzuvollziehen — vom Source-Commit bis zum veröffentlichten Digest.

VEX und SBOM

Jedes Image enthält eine CycloneDX-SBOM-Attestierung mit allen transitiven Abhängigkeiten und ihren kryptografischen Hashes sowie eine CycloneDX-VEX-Attestierung zur Ausnutzbarkeit bekannter CVEs — für eine präzise, maschinenlesbare Schwachstellen-Impact-Analyse.

Image-Signatur verifizieren
cosign verify \
  --key https://raw.githubusercontent.com/l3montree-dev/devguard/main/cosign.pub \
  ghcr.io/l3montree-dev/devguard:main-amd64

Manuell verifizieren

Beide Images unabhängig pullen und ihre SHA-256-Digests vergleichen. Digest-Gleichheit ist eine hinreichende Bedingung für bytegenaue Ausgabenidentität — kein externer Vertrauensanker erforderlich.

1

Beide Images pullen

Images aus beiden Registries unabhängig voneinander abrufen.

shell
docker pull ghcr.io/l3montree-dev/devguard:main-amd64
docker pull registry.opencode.de/oci-community/images/l3montree/devguard/devguard:main-amd64
2

Digests vergleichen

Den kryptografischen Digest jedes Images prüfen. Beide Digests müssen identisch sein.

shell
docker inspect --format='{{index .RepoDigests 0}}' \
  ghcr.io/l3montree-dev/devguard:main-amd64

docker inspect --format='{{index .RepoDigests 0}}' \
  registry.opencode.de/oci-community/images/l3montree/devguard/devguard:main-amd64
3

Alternativ: skopeo verwenden

skopeo erlaubt die Inspektion von Remote-Images ohne vorheriges Pullen.

shell
skopeo inspect \
  docker://ghcr.io/l3montree-dev/devguard:main-amd64 | jq '.Digest'

skopeo inspect \
  docker://registry.opencode.de/oci-community/images/l3montree/devguard/devguard:main-amd64 | jq '.Digest'

Wo Images gebaut werden

Beide Pipelines bauen aus derselben Git-Revision bei jedem Push auf main. Die Workflow-Definitionen sind öffentlich einsehbar — prüfe sie mit den folgenden Links, um sicherzustellen, dass Build-Inputs, Toolchain-Version und Push-Ziele identisch sind.

GitHubGitHub Actions

Baut und pusht alle Images bei jedem Commit auf main nach ghcr.io.

l3montree-dev/devguardView pipeline runs
openCodeopenCode CI

Spiegel-Pipeline auf openCode, deutscher Behördeninfrastruktur in Deutschland gehostet, baut und pusht nach registry.opencode.de.

oci-community/images/l3montree/devguard/devguardView pipeline runs