CI/CD-Pipeline für Behörden: Aufbau, Vergabe und Audit

Die CI/CD-Pipeline für Behörden entscheidet darüber, wie schnell, sicher und nachweisbar digitale Verwaltungsleistungen in den Betrieb gelangen. Vergabestellen, IT-Leitungen und Informationssicherheitsbeauftragte finden hier einen kompakten Praxisleitfaden, der Aufbau, EVB-IT-Klauseln und DevOps in der öffentlichen Verwaltung systematisch verbindet. Jeder Pipeline-Schritt muss vergaberechtlich greifen, in der souveränen Cloud stabil laufen und im BSI-Audit zweifelsfrei standhalten.
Geschäftsmann geht über eine aus vorwärts weisenden Pfeilen gebildete Brücke. Sinnbild für den durchgängigen, automatisierten Weg einer auditfähigen CI/CD-Pipeline in der öffentlichen Verwaltung – Schritt für Schritt von Build über Test bis zur Freigabe.
© Lerbank-bbk22

CI/CD-Pipeline für Behörden im praktischen Aufbau

Eine CI/CD-Pipeline für Behörden bündelt Quellcode-Verwaltung, Build, Sicherheits-Scan, Freigabe und Produktiv-Deployment in einer dokumentierten Auslieferungsstrecke. Laut INSM-Behörden-Digimeter 2026 stehen bundesweit nur elf Prozent der OZG-Einzelleistungen flächendeckend digital bereit. Wiederverwendbare Auslieferungspfade schließen diese Lücke verlässlicher als Einzelprojekte. Der übergeordnete Leitfaden zu Continuous Delivery ordnet das Konzept gesamthaft ein, das vorliegende Übersichts-Material verdichtet es für Vergabestellen, IT-Leitungen und Informationssicherheitsbeauftragte. Wer das Thema zunächst privatwirtschaftlich bewerten möchte, greift zur CI/CD-Checkliste für Unternehmen. Hier hingegen stehen Aufbau, Vergabe und Audit-Nachweis im Mittelpunkt — die drei Linien, die jede CI/CD-Pipeline in Behörden tragen.

Welche Stages braucht eine auditfähige CI/CD-Pipeline?

Eine auditfähige CI/CD-Pipeline trennt jede Stage logisch und protokolliert sie lückenlos. Build, statische Code-Analyse, Unit- und Integrationstests, SBOM-Erzeugung, Staging-Deployment, fachliche Freigabe sowie Produktiv-Deployment laufen in einer fest definierten Reihenfolge. Für Behörden zählt nicht das Werkzeug, sondern die revisionssichere Trennung von Zuständigkeit, Stage und Freigabeentscheid. Die SBOM-Pflege für KRITIS zeigt, wie eine signierte Stückliste als Pipeline-Artefakt in den Audit-Pfad einfließt. Damit bleibt die auditfähige CI/CD-Pipeline kein Versprechen, sondern eine prüffähige Datenspur.

Mindestbausteine in einer Behörden-Pipeline:

Build- und Test-Stages für Verwaltungen

Build- und Test-Stages laufen auf isolierten Runnern, getrennt nach Schutzbedarf. Deterministische Builds mit gepinnten Lock-Dateien verhindern, dass identische Eingaben unterschiedliche Artefakte erzeugen. Unit-, Integrations- und Vertragstests werden je Stage protokolliert, ihre Reports landen versioniert in einem Repository, das auch der Innenrevision zugänglich bleibt. So lässt sich später jede Auslieferung gegen das exakte Test-Ergebnis rückverfolgen. Ein zusätzlicher Lasttest hält den späteren OZG-Spitzen stand und verhindert Überraschungen im Echtbetrieb. Die Test-Pipeline lehnt ein fehlerhaftes Artefakt automatisiert ab und schützt die CI/CD-Pipeline für Behörden vor unbemerkten Regressionen.

Freigabe- und Produktiv-Stages

Die Freigabe-Stage trennt die fachliche Abnahme von der technischen Auslieferung. Mindestens zwei berechtigte Rollen unterzeichnen jedes Produktiv-Deployment digital, der Freigabe-Datensatz wird in einer fälschungssicheren Form abgelegt. Anschließend startet das Produktiv-Deployment automatisiert, gefolgt von Post-Deploy-Monitoring und Roll-back-Bereitschaft. So bleibt der gesamte Pfad nachvollziehbar — ein Kernbaustein jeder CI/CD-Pipeline in Behörden. Bei einem Roll-back greift dieselbe Pipeline rückwärts und rekonstruiert die vorherige Version aus signierten Artefakten in Minuten. Damit wird die CI/CD-Pipeline in Behörden zur einzigen autoritativen Auslieferungsquelle.

DevOps in der öffentlichen Verwaltung als Vergabe-Aufgabe

DevOps in der öffentlichen Verwaltung trifft auf ein strenges Vergaberecht. Anders als in der Privatwirtschaft müssen agile Liefermethoden über UVgO oder VgV ausgeschrieben, in EVB-IT-Verträge gegossen und im Rechnungshofs-Nachweis verteidigt werden. Ein dokumentierter Pipeline-Aufbau wird damit selbst zum Vergabegegenstand. Eine CI/CD-Pipeline für Behörden ist nicht nur DevOps-Werkzeug, sondern Bestandteil der Vergabeakte. Daran muss DevOps in der öffentlichen Verwaltung gemessen werden. Vergaberahmen und Wartungs-SLA gehören dabei in dieselbe Akte: EVB-IT-Vertragsmuster für Behörden regeln den Lieferweg, die Software-Wartung für Behörden sichert den späteren Betrieb. Beides muss zur Pipeline-Definition passen, sonst entsteht eine Lücke zwischen Auslieferung und Tagesbetrieb, die im Notfall jeden Patch verzögert und Aufsichtsfragen aufwirft.

Vergaberechtskonforme Ausschreibung von Pipeline-Leistungen

Was eine Vergabe mit DevOps-Anteil zwingend regelt:

Eine vergaberechtskonforme Formulierung trennt die agile Methode vom Werk: bestellt wird ein abgrenzbarer Werkbestandteil je Sprint, geprüft an einem Quality-Gate-Ergebnis. DevOps in der öffentlichen Verwaltung bleibt damit vergaberechtlich beherrschbar, ohne agile Liefermethoden zu blockieren. Erfahrene Auftragnehmer formulieren diese Schnittstelle als Anlage zur Leistungsbeschreibung — und ersparen so der Vergabestelle nachträgliche Streitigkeiten über Abnahme und Vergütung. Praxiserprobte DevOps in der öffentlichen Verwaltung verkürzen zudem die spätere Wartungszeit.

Welche Pipeline-Anforderungen ergeben sich aus der ITZBund-/Bundescloud-Nutzung?

Die ITZBund-Bundescloud verlangt eine Pipeline, die sich in ihre Plattformdienste sauber einbettet. Container-Registries, Identitäts-Service und Secret-Speicher müssen aus der Pipeline heraus standardkonform angesprochen werden, ohne eigene Workarounds. Verschlüsselung der Artefakte erfolgt mit von der Behörde verwalteten Schlüsseln, Telemetrie wird in das vorgesehene Monitoring der Cloud-Plattform überführt. Die Auslieferungs-Strecke beendet das Produktiv-Deployment nur, wenn alle plattformseitigen Quality Gates grün geben. So bleibt die Hosting-Plattform der zentrale Kontrollpunkt, nicht die Pipeline-Definition allein. Zusätzlich verankert die Bundescloud feste SLA für Wiederherstellung und Datenrückgabe, die in das Pipeline-Design unmittelbar einfließen — gerade bei mandantenfähigen Verfahren. So bleibt die CI/CD-Pipeline für Behörden konsistent.

EVB-IT-Klauseln für die CI/CD-Pipeline der Behörde

Eine CI/CD-Pipeline der Behörde wird über EVB-IT-Klauseln einklagbar. Die Leistungsbeschreibung benennt jede Stage, ihr Quality Gate, das erwartete Artefakt und die Bedingung für die Abnahme. Ohne präzise Klauseln verbleibt das Pipeline-Wissen beim Anbieter und gerät beim Wechsel verloren. Ein verbindliches IT-Service-Level-Agreement ergänzt die EVB-IT-Klauseln um Reaktions- und Wiederherstellungszeiten, die laufende Software-Wartung und Support-Betreuung verlängert die Pipeline-Disziplin in den Tagesbetrieb. So entsteht ein durchgehender Pfad von der Ausschreibung bis zum Produktiv-Deployment, ohne Bruchstellen. Vergaberechtskonform wird das Paket erst, wenn jede Pipeline-Klausel mit einer messbaren Kennzahl unterlegt ist — sonst bleiben Streitigkeiten über Abnahme programmiert. Dadurch lässt sich auch DevOps in der öffentlichen Verwaltung sauber kontrollieren.

Welche BSI-Grundschutz-Bausteine gelten für eine CI/CD-Pipeline in Behörden?

Für eine CI/CD-Pipeline in Behörden gelten vor allem CON.8 Software-Entwicklung, OPS.1.1.6 Software-Tests und Freigaben sowie APP.7 Anwendungsentwicklung. Im Lagebericht des Bundesamts für Sicherheit in der Informationstechnik werden täglich rund 119 neue Schwachstellen registriert — eine Pipeline ohne automatisierte Sicherheits-Scans wird im Audit nicht bestehen. Die Pipeline-Definition muss die Kontrollziele der Bausteine eins zu eins abbilden und im Audit als versionierte Datei vorgelegt werden, nicht als Folienvortrag. Eine auditfähige CI/CD-Pipeline in Behörden bindet beide Ebenen zusammen.

Bausteine im Pipeline-Bezug:

Auditfähige CI/CD-Pipeline im Rechnungshof-Nachweis

Eine auditfähige CI/CD-Pipeline liefert dem Rechnungshof drei Belege: dokumentierte Wirtschaftlichkeit, dokumentierte Sicherheit, dokumentierte Wiederholbarkeit. Die Pipeline-Definition liegt versioniert im Repository, die Build-Logs werden signiert archiviert, die Test- und Freigabeprotokolle bleiben mindestens zehn Jahre revisionssicher abrufbar. Auf dieser Basis lässt sich jede Auslieferung im Nachhinein rekonstruieren — vom auslösenden Commit über Test-Status bis zur Freigabesignatur. Damit wird die auditfähige CI/CD-Pipeline zum aktivsten Compliance-Werkzeug einer Behörde. Im Rechnungshofs-Bericht zählt nicht die Folie, sondern die abrufbare Datenspur — sie entscheidet darüber, ob Investitionen in eine Behörden-Pipeline als wirtschaftlich gelten und tragfähig dokumentiert sind. Die CI/CD-Pipeline für Behörden wird damit zur Beweislast in der Innenrevision. DevOps in der öffentlichen Verwaltung bleibt damit nachvollziehbar.

Souveräne Pipeline in der Deutschen Verwaltungscloud

Eine souveräne Pipeline in der Deutschen Verwaltungscloud liefert in eine Plattform aus, die seit 1. April 2025 produktiv betrieben wird. Pipeline endet nicht am Build, sondern erst am stabilen Lauf im Zielsystem. Damit fallen Container-Härtung, Confidential-Computing-Hosting und ein C5-konformer Betrieb in den Verantwortungsbereich der Auslieferungsstrecke. Die Plattform übernimmt Identität und Netzwerktrennung, die Pipeline liefert signierte Artefakte mit nachvollziehbarer Herkunft. So bleibt die digitale Souveränität auch im Tagesbetrieb gewahrt, und DevOps-Praxis in Verwaltungen verliert den Beigeschmack als Fremdkörper.

Säulen einer souveränen CI/CD-Pipeline für Behörden:

Welche Pipeline-Architektur erfüllt BSI C5 für Cloud-Hosting?

Die Pipeline-Architektur, die BSI C5 für Cloud-Hosting erfüllt, trennt strikt zwischen Build, Artefakt-Lager und Deployment-Pfad. Jeder Build-Runner läuft auf einer testierten Plattform, Artefakte werden in einer C5-bestätigten Registry abgelegt, das Deployment greift nur über getestete Service-Accounts auf die Produktiv-Umgebung zu. Geheimnisse verlassen die Pipeline ausschließlich verschlüsselt und werden in einem zentralen Schlüssel-Tresor verwaltet. Damit verbindet sich die Software-Auslieferung mit den Cloud-Kontrollen — geprüft durch ein gemeinsames C5-Testat des Plattformbetreibers und der Pipeline-Implementierung in der Behörde. So bleibt die Auslieferung souverän und in der Behörde prüfbar.

FAQs

Was muss in der EVB-IT-Leistungsbeschreibung für eine CI/CD-Pipeline stehen? keyboard_arrow_down keyboard_arrow_up
Die EVB-IT-Leistungsbeschreibung benennt jede Pipeline-Stage einzeln, definiert das zugehörige Quality Gate als Abnahmekriterium und verankert Datenstandort, Service-Account-Modell sowie Übergaberechte. Pipeline-Definition als Quellcode, signierte Build-Logs und Test-Berichte gelten als vertraglich übergebene Werke. Damit bleibt jede Auslieferung später vor Aufsicht und Innenrevision rekonstruierbar.
Wie kann eine Behörde Deployments unter NIS-2 nachweisbar dokumentieren? keyboard_arrow_down keyboard_arrow_up
Eine Behörde dokumentiert Deployments unter NIS-2 über einen versionierten Pipeline-Pfad: Commit-Spur, signierte Build- und Test-Logs, Freigabeprotokoll und Deployment-Record landen revisionssicher im Repository. Im Vorfallsfall greifen die 24-Stunden- und 72-Stunden-Meldefristen direkt auf diese Belege zurück, ohne nachträgliche Rekonstruktion oder Excel-Workarounds.
Wie unterstützt TenMedia Behörden beim Aufbau einer auditfähigen CI/CD-Pipeline? keyboard_arrow_down keyboard_arrow_up
TenMedia begleitet Behörden in vier Schritten beim Aufbau einer auditfähigen Auslieferungsstrecke: Pipeline-Vorprüfung mit Ist-Analyse der vorhandenen Build- und Test-Strecken, Co-Authoring der EVB-IT-Leistungsbeschreibung, technische Implementierung in der Deutschen Verwaltungscloud oder im Behörden-Rechenzentrum sowie Vorbereitung der Audit-Belege für BSI-Grundschutz, C5 und Rechnungshofs-Prüfung. Die ISO-9001-zertifizierte Projektorganisation, die laufende Wartung über EVB-IT-Pflege-S und eine 14-jährige Erfahrung mit Individualsoftware-Projekten in Berlin bilden den methodischen Rahmen. Auf Wunsch übernimmt das Team auch die Pipeline-Patchpflege im Bereitschaftsdienst und stellt Vorlagen für die Quality-Gate-Definition bereit. So entsteht eine belastbare CI/CD-Pipeline für Behörden, die vom Vergabevorgang bis zum Tagesbetrieb reicht.