Souveränität beginnt im Build-System – Reproduzierbarkeit, Lieferketten und der Deutschland-Stack

Stellungnahme zum Beteiligungsprozess “Deutschland-Stack”

Das Bundesministerium für Digitales und Staatsmodernisierung hat zur Mitarbeit am Tech-Stack für Deutschland aufgerufen. Mit diesem Beitrag komme ich dieser Bitte gerne nach und steuere meine Erfahrungen aus der Praxis bei – insbesondere zu den Themen Reproduzierbarkeit, Lieferketten und digitale Souveränität.

Aus meiner Sicht sind diese Aspekte grundlegende Voraussetzungen dafür, dass der Deutschland-Stack langfristig robust, unabhängig und vertrauenswürdig wirken kann.

🚀 Warum das für politische Entscheidungsträger wichtig ist

Eine souveräne Verwaltung muss Software nicht nur nutzen können – sie muss sie unabhängig prüfen, bauen und betreiben können. Genau daraus leitet sich ab, dass Reproduzierbarkeit und Lieferkettentransparenz keine technischen Details sind, sondern staatliche Kernanforderungen. Nur wenn Build-Prozesse vollständig nachvollziehbar und deterministisch sind, behält der Staat die operative Kontrolle über seine digitalen Infrastrukturen. Das stärkt die Integrität, Auditierbarkeit und Cyber-Resilienz der öffentlichen IT – und verhindert, dass kritische Systeme faktisch von einzelnen Anbietern abhängig bleiben. Transparente Software-Lieferketten schaffen zudem eine belastbare Grundlage für Haushaltsstabilität, weil sie Lock-in vermeiden und Wettbewerb ermöglichen. Für den Deutschland-Stack bedeutet das: Neben offenen Standards braucht es verbindliche Kriterien für nachvollziehbare Builds, SBOM-Pflichten und prüfbare Lieferketten. Erst wenn Software unabhängig gebaut werden kann, wird sie langfristig steuerbar, austauschbar und verlässlich betreibbar.

Ein Moment, den viele Entwickler kennen

In der Kaffeeküche hörst du von einer neuen Produktivitätssoftware. Komplett Open Source, selbst betreibbar, erweiterbar. Alle Daten bleiben bei dir.

Du klonst das Repository. make build ERROR.

Dann häufen sich die Stolpersteine:

Prüfsummen passen nicht
npm lädt unsignierte Pakete
eine Dependency kommt im Schneckentempo
Skripte wollen Schreibrechte auf /usr/local
es fehlen Hinweise und Dokumentation

Und schnell stellt sich die Frage: Wie soll daraus nachhaltig vertrauenswürdige Software entstehen?

💬 Einordnende Perspektive

Nicht jedes Projekt, das offen wirkt, ist gleichermaßen darauf ausgelegt, vollständig selbst betrieben werden zu können. Manchmal entsteht unbeabsichtigt eine gewisse Abhängigkeit vom ursprünglichen Anbieter – sei es durch komplexe Toolchains, fehlende Rezepte oder unvollständige Dokumentation.

Das bedeutet nicht zwingend böse Absicht. Dennoch lohnt es sich, bewusst hinzuschauen, wo echte Selbstständigkeit möglich ist und wo eine stärkere Anbindung an Dienstleister bestehen bleibt.

Warum dieser Moment entscheidend für digitale Souveränität ist

Digitale Souveränität zeigt sich nicht allein durch Quelloffenheit, sondern durch die Fähigkeit, Software eigenständig, nachvollziehbar und ohne versteckte Abhängigkeiten zu bauen.

Wirkliche Offenheit erkennt man daran, ob man ein Projekt selbst:

herunterladen
prüfen
reproduzieren
offline bauen

kann.

💬 Kerngedanke

Quelloffenheit ist ein wichtiger Startpunkt — doch ohne reproduzierbare Builds bleibt sie aus meiner Sicht unvollständig. Erst Reproduzierbarkeit schafft die Grundlage für echte digitale Souveränität.

Was der Deutschland-Stack bietet – und was noch nicht adressiert ist

Der Deutschland-Stack bietet:

eine Technologielandkarte
Kriterien zur Orientierung
eine wertvolle Diskussionsbasis

Was er naturgemäß nicht leisten kann, ist eine Bewertung, wie reproduzierbar und unabhängig die jeweiligen Technologien in der Praxis gebaut werden können. Diese Einsicht entsteht erst im tatsächlichen Build-Prozess.

ℹ️ Offizielle Quellen zum Deutschland-Stack

Deutschland-Stack
Technologielandkarte

Der echte Prüfstein: Reproduzierbare Builds

Reproduzierbare Builds …

machen Abhängigkeiten sichtbar
schaffen Sicherheit in der Lieferkette
reduzieren operative Risiken
ermöglichen einen unabhängigen Betrieb
unterstützen eine revisionsfähige IT-Architektur

💡 Transparenz als Messlatte

Reproduzierbarkeit sorgt für Klarheit: Wo Open Source draufsteht, sollte nachvollziehbare Offenheit drin sein — ohne versteckte Downloads, proprietäre Hilfswerkzeuge oder unklare Build-Schritte.

Woran man mangelnde Reproduzierbarkeit erkennt

Typische Anzeichen:

unvollständige oder schwer verständliche Build-Skripte
proprietäre Toolchains
nachladende Binaries oder „magische“ CI/CD-Abhängigkeiten
fehlende Hashes und Freigabekriterien
intransparente Dependency-Management-Prozesse

Lieferkette: ein zentrales Thema für Sicherheit und Souveränität

Zwei Perspektiven sind besonders relevant:

1. Transparenz durch SBOM

Eine SBOM listet die enthaltenen Komponenten mitsamt Versionen, Prüfsummen und Herkunft auf — ein zentraler Baustein moderner Software-Sicherheit.

2. Reproduzierbarkeit durch deterministische Builds

Ein Build-Prozess muss lokal, deterministisch und idealerweise sogar offline funktionieren, damit er langfristig unabhängig, auditierbar und robust bleibt.

ℹ️ Weiterführende Inhalte aus meinem Blog

SBOM-Transparenz
Lieferkettenkontrolle in Go

Warum Reproduzierbarkeit auch wirtschaftlich relevant ist

Öffentliche IT wird maßgeblich aus Steuergeldern finanziert. Deshalb stellt sich die Frage: Wie nachhaltig sind unsere Investitionen?

Wenn Software zwar offen lizenziert ist, aber praktisch nur mit Unterstützung eines bestimmten Dienstleisters betreibbar bleibt, entstehen langfristige Kosten:

teure Service- oder Hosting-Abhängigkeiten
wiederkehrende Migrationsaufwände
zusätzliche Sicherheits- und Compliance-Aufgaben
operative Risiken durch schwer kontrollierbare Lieferketten

Aus meiner Sicht stärkt Reproduzierbarkeit die Verhandlungssituation, schafft mehr Anbieterwettbewerb und macht Investitionen dauerhaft tragfähig.

💬 Perspektive der öffentlichen Haushalte

Jeder Euro, der durch mangelnde Reproduzierbarkeit in langfristige Abhängigkeiten fließt, fehlt an anderer Stelle. Transparente und reproduzierbare Build-Prozesse tragen somit direkt zu einer verantwortungsvollen und nachhaltigen Digitalisierungspolitik bei.

Fazit: Souveränität beginnt im Build-System

Wenn Reproduzierbarkeit als fundamentales Architekturziel verstanden wird, verändert sich der Blick auf Technologien:

Abhängigkeiten werden kontrollierbar
Systeme werden auditierbar
Dienste werden austauschbarer
Betreiber gewinnen Unabhängigkeit

So entsteht digitale Souveränität, die nachhaltig, nachvollziehbar und robust ist.

Hinweis zur Einordnung dieser Veröffentlichung

Dieser Artikel dient als öffentliche Stellungnahme im Rahmen des Beteiligungsverfahrens zum Deutschland-Stack. Ich freue mich auf die weitere gemeinsame Arbeit an einem offenen, klar nachvollziehbaren und souveränen technologischen Fundament für Deutschland.