build Funktionsbaustein: Entwicklung und Bereitstellungfeedback
| Eigenschaft | Wert |
|---|---|
| Kennung | DArch-FBS-ENT |
| Hauptfähigkeit | Produkte und Services |
| Geschäftsfähigkeit | Entwicklung |
| Kategorie | Entwicklung |
| Version | 0.1 (06.05.2026) |
| GovStack-Mapping | Cross-Functional Requirements: Development |
| Referenzstandards | SLSA v1.0, BSI TR-03183-2 (SBOM), CycloneDX, SPDX, OCI Image Spec, GitOps Principles |
| Open-Source-Referenz | Open CoDE, Argo CD, Flux, Tekton, Sigstore |
summarize 1 Management Summaryfeedback
Der Baustein „Entwicklung und Bereitstellung" (ENT) umfasst die Plattformfunktionalitäten für die Erstellung, das Testen und das Ausliefern von Basis- und Fachanwendungen im Deutschland-Stack. Er stellt die DevSecOps- und GitOps-Werkzeugkette bereit, über die alle anderen Funktionsbausteine ihren gesamten Software-Lebenszyklus – von der Anforderung über Build, Test und Signierung bis zum Deployment auf gehärteten Kubernetes-Zielsystemen – nachweisbar und revisionssicher durchlaufen.
Die übergreifende Sicherheitsarchitektur für den SDLC (Bedrohungsmodell, Pipeline-Härtung, SBOM-Pflicht, Provenance) ist in der Leitlinie Sicherer SDLC für Funktionsbausteine beschrieben. Der vorliegende Baustein definiert die konkreten Plattformfähigkeiten, die diese Leitlinie implementiert.
description 2 Beschreibungfeedback
Der Baustein modelliert eine zentrale Entwicklungs- und Bereitstellungsplattform, die Teams in Bund, Ländern und Kommunen als Self-Service nutzen. Er bildet die Brücke zwischen Quellcode auf Open CoDE und dem produktiven Betrieb auf souveränen Cloud-Infrastrukturen. Die Plattform setzt die D-Stack-Prinzipien „DevSecOps only" und „GitOps" technisch um.
Annahmen zum Geltungsbereich:
- Der Baustein adressiert die Plattform-Schicht (Developer Platform), nicht die Fachanwendungen selbst.
- Teams behalten die Verantwortung für eigene Pipelines; der Baustein stellt Templates, Compliance-Guardrails und Shared Services bereit.
- Der Betrieb der Plattform erfolgt auf BSI-konformer Infrastruktur (vgl. IT-Grundschutz).
menu_book 3 Terminologiefeedback
Die folgende Tabelle enthält in dieser Spezifikation verwendete Fachbegriffe, die über die allgemeine Terminologie der D-Stack-Architekturspezifikationen hinausgehen. Sie dient als Referenz für alle am Baustein beteiligten Stakeholder und vermeidet Missverständnisse bei der Umsetzung.
| Begriff | Definition |
|---|---|
| CI/CD | Continuous Integration / Continuous Delivery – automatisierte Build-, Test- und Auslieferungskette. |
| DevSecOps | Integration von Sicherheitsmaßnahmen in jeden Schritt des Entwicklungs- und Betriebsprozesses. |
| GitOps | Deklarativer Soll-Zustand in Git; Änderungen ausschließlich per Pull/Merge Request; automatischer Abgleich durch Operator. |
| SBOM | Software Bill of Materials – maschinenlesbare Stückliste aller Abhängigkeiten eines Artefakts. |
| SLSA | Supply-chain Levels for Software Artifacts – Framework zur Absicherung der Build-Integrität. |
| Provenance | Herkunftsnachweis eines Build-Artefakts (Quelle, Builder, Parameter). |
| OCI | Open Container Initiative – Spezifikation für Container-Image-Formate und -Registries. |
| Distroless | Minimale Container-Images ohne Paketmanager oder Shell – reduziert Angriffsfläche. |
hub 4 Kernfunktionalitätenfeedback
Die Kernfunktionalitäten bündeln mehrere funktionale Anforderungen (Kapitel 6) zu logischen Fähigkeitsgruppen. Sie beschreiben, was der Baustein leistet – nicht, wie eine konkrete Implementierung aussehen muss. Die folgende Mindmap gibt eine Übersicht; die detaillierte Beschreibung folgt darunter.
Der Baustein „Entwicklung und Bereitstellung" umfasst fünf Kernfunktionalitäten:
-
Quellcode-Management – Bereitstellung und Governance von Git-Repositories auf Open CoDE mit signierten Commits, Branch Protection und automatisiertem Secret Scanning.
-
Build & Packaging – Wiederverwendbare CI-Pipeline-Templates für Container-Builds, automatische SBOM-Erzeugung (CycloneDX/SPDX) und Signierung mit Sigstore/Cosign (SLSA Level 3).
-
Qualitätssicherung – Integrierte Security-Scans (SAST, SCA, Container-Scan), automatisierte Tests und Compliance-Gates, die Deployments bei kritischen Befunden blockieren.
-
Bereitstellung (Deployment) – GitOps-basiertes Deployment via Argo CD oder Flux auf gehärtete Kubernetes-Cluster mit Canary-, Blue-Green- und Rollback-Strategien.
-
Plattform-Services – Developer Portal (Backstage-basiert), zentrales Secrets Management und Integration in die Observability-Infrastruktur des D-Stacks.
swap_horiz 5 Querschnittsanforderungenfeedback
Die folgenden Querschnittsanforderungen orientieren sich an den GovStack Cross-Functional Requirements: Development und den Vorgaben der Leitlinie Sicherer SDLC.
| ID | Anforderung | Verbindlichkeit | Quelle |
|---|---|---|---|
| ENT-QA-01 | Alle Quellcodes verwenden Versionskontrolle (Git) mit vollständiger Commit-Historie. | Erforderlich | GovStack CFR #1 |
| ENT-QA-02 | Quellcode und Kommentare sind klar, wartbar und in Englisch verfasst. | Erforderlich | GovStack CFR #2 |
| ENT-QA-03 | Software wird unter einer anerkannten Open-Source-Lizenz veröffentlicht. | Empfohlen | GovStack CFR #3 |
| ENT-QA-04 | Datenbankschema-Änderungen werden über versionierte Migrationsskripte verwaltet. | Empfohlen | GovStack CFR #4 |
| ENT-QA-05 | Unit- und Integrationstests mit definierter Mindestabdeckung sind vorhanden. | Empfohlen | GovStack CFR #5 |
| ENT-QA-06 | Regelmäßige Security- und Code-Quality-Audits mit Peer Review. | Empfohlen | GovStack CFR #6 |
| ENT-QA-07 | Verwendete Komponenten haben eine End-of-Life-Prognose von mindestens 5 Jahren. | Empfohlen | GovStack CFR #7 |
| ENT-QA-08 | Bevorzugung von Top-25-Programmiersprachen (TIOBE / IEEE Spectrum). | Empfohlen | GovStack CFR #8 |
| ENT-QA-09 | Best Practices des Standard for Public Code werden eingehalten. | Empfohlen | GovStack CFR #9 |
| ENT-QA-10 | SBOM-Erzeugung nach BSI TR-03183-2 für jedes Release-Artefakt. | Erforderlich | SDLC-Leitlinie §4.3 |
| ENT-QA-11 | Signierte Builds und Provenance nach SLSA ≥ Level 3. | Erforderlich | SDLC-Leitlinie §4.4 |
| ENT-QA-12 | Pipeline-Härtung: Digest-Pinning, Cosign-Verifikation, Multi-Scanner. | Erforderlich | SDLC-Leitlinie §4.6 |
checklist 6 Funktionale Anforderungenfeedback
Die technischen Fähigkeiten, über die dieser Baustein verfügen muss und sollte. Diese Anforderungen bilden die Grundlage, um alle im Abschnitt „Kernfunktionalitäten" aufgeführten Funktionen bereitzustellen. Jede Anforderung ist nach Verbindlichkeit klassifiziert: Erforderlich (MUST) oder Empfohlen (SHOULD).
6.1 Quellcode-Verwaltungfeedback
Anforderungen an die sichere Verwaltung von Quellcode auf der zentralen Plattform Open CoDE. Sie stellen sicher, dass jede Codeänderung authentifiziert, überprüft und nachvollziehbar ist.
| ID | Anforderung | Verbindlichkeit |
|---|---|---|
| ENT-FA-01 | Git-Hosting auf Open CoDE mit SSO-Integration (BundID / föderales IdP). | Erforderlich |
| ENT-FA-02 | Signierte Commits (GPG/SSH) mit automatischer Verifikation. | Erforderlich |
| ENT-FA-03 | Branch-Protection-Regeln mit verpflichtendem Peer Review (≥ 1 Reviewer). | Erforderlich |
| ENT-FA-04 | Automatisiertes Secret Scanning mit Blocking-Push bei Fund. | Erforderlich |
6.2 Build & Packagingfeedback
Anforderungen an den automatisierten Build-Prozess und die Paketierung von Artefakten. Der Fokus liegt auf Reproduzierbarkeit, Transparenz (SBOM) und kryptographischer Integrität (Signierung).
| ID | Anforderung | Verbindlichkeit |
|---|---|---|
| ENT-FA-10 | Bereitstellung wiederverwendbarer CI-Pipeline-Templates (Tekton Tasks / GitLab CI Templates). | Erforderlich |
| ENT-FA-11 | Hermetic Builds in ephemeren, netzwerkisolierten Containern. | Empfohlen |
| ENT-FA-12 | Automatische SBOM-Generierung im CycloneDX- oder SPDX-Format. | Erforderlich |
| ENT-FA-13 | Signierung aller OCI-Artefakte mit Cosign und Provenance-Attestation. | Erforderlich |
| ENT-FA-14 | Gehärtete Container-Images (Distroless, non-root, read-only rootfs). | Erforderlich |
6.3 Qualitätssicherung in der Pipelinefeedback
Anforderungen an die automatisierten Sicherheits- und Qualitätsprüfungen, die bei jedem Merge Request und vor jedem Release durchlaufen werden. Kritische Befunde blockieren das Deployment automatisch.
| ID | Anforderung | Verbindlichkeit |
|---|---|---|
| ENT-FA-20 | SAST-Scan (statische Codeanalyse) bei jedem Merge Request. | Erforderlich |
| ENT-FA-21 | SCA-Scan (Abhängigkeitsanalyse) mit CVE-Blocking ab CVSS ≥ 7.0. | Erforderlich |
| ENT-FA-22 | Container-Image-Scan vor Signierung (Trivy + Grype, Multi-Scanner). | Erforderlich |
| ENT-FA-23 | IaC-Scan (Terraform, Helm Charts) auf Fehlkonfigurationen. | Empfohlen |
| ENT-FA-24 | Automatisierte Unit- und Integrationstests mit Mindestabdeckung ≥ 80 %. | Empfohlen |
6.4 Deployment & GitOpsfeedback
Anforderungen an die deklarative, Git-gesteuerte Auslieferung von Artefakten auf Kubernetes-Zielsysteme. Der gewünschte Zustand liegt ausschließlich in Git; Abweichungen werden automatisch erkannt und korrigiert.
| ID | Anforderung | Verbindlichkeit |
|---|---|---|
| ENT-FA-30 | Deklarativer Deployment-Zustand in Git (Single Source of Truth). | Erforderlich |
| ENT-FA-31 | GitOps-Operator (Argo CD / Flux) mit automatischer Drift-Erkennung und -Korrektur. | Erforderlich |
| ENT-FA-32 | Unterstützung von Canary-, Blue-Green- und Rolling-Update-Strategien. | Empfohlen |
| ENT-FA-33 | Automatisiertes Rollback bei fehlgeschlagenen Health Checks. | Erforderlich |
| ENT-FA-34 | Image-Verifikation (Cosign) vor Deployment im Cluster (Admission Controller). | Erforderlich |
6.5 Plattform-Servicesfeedback
Anforderungen an die übergreifenden Dienste, die der Baustein allen Entwicklungsteams als Shared Services bereitstellt. Diese umfassen Self-Service-Onboarding, Secrets Management und Observability-Integration.
| ID | Anforderung | Verbindlichkeit |
|---|---|---|
| ENT-FA-40 | Developer Portal mit Self-Service-Onboarding für neue Teams/Projekte. | Empfohlen |
| ENT-FA-41 | Zentrales Secrets Management (HashiCorp Vault / Sealed Secrets) mit Rotation. | Erforderlich |
| ENT-FA-42 | Integration in zentrale Observability (Logs, Metriken, Traces). | Empfohlen |
database 7 Datenstrukturenfeedback
Dieser Abschnitt beschreibt die zentralen Datenstrukturen und Datenmodelle, die vom Baustein „Entwicklung und Bereitstellung" genutzt werden. Er umfasst Ressourcenmodell, Datenelemente und Schema, die von den Kernfunktionalitäten benötigt werden, um die Plattformdienste in einem MVP-Stadium zu orchestrieren.
7.1 Ressourcenmodellfeedback
Das Ressourcenmodell zeigt die Beziehungen zwischen den Datenobjekten, die von diesem Baustein verwaltet werden. Ein Repository löst Pipeline Runs aus, die Build-Artefakte mit zugehöriger SBOM und Signatur erzeugen. Artefakte werden über Deployments in Ziel-Environments ausgerollt.
7.2 Zentrale Datenobjektefeedback
Die folgende Tabelle beschreibt die wesentlichen Fachobjekte des Bausteins. Jedes Objekt entspricht einer Entität im Ressourcenmodell und wird über die Service-Schnittstellen exponiert.
| Objekt | Beschreibung |
|---|---|
| Repository | Git-Repository auf Open CoDE mit Metadaten zu Branch Protection und Signing-Policy. |
| Pipeline Run | Einzelne Ausführung einer CI-Pipeline mit Referenz auf Commit, Status und Dauer. |
| Build Artifact | OCI-Image oder Paket mit SHA-256-Digest und SLSA-Level. |
| SBOM | Maschinenlesbare Stückliste im CycloneDX- oder SPDX-Format. |
| Signature | Cosign-Signatur und Provenance-Attestation für ein Build-Artefakt. |
| Deployment | Ausrollung eines Artefakts in ein Ziel-Environment mit Strategie und Status. |
| Environment | Kubernetes-Namespace in einem Zielcluster (dev, staging, prod). |
api 8 Service-Schnittstellenfeedback
Dieser Abschnitt enthält eine Referenz für die APIs, die von diesem Baustein implementiert werden. Die hier definierten APIs bilden die Grundlage für die Interaktion mit anderen Bausteinen und Konsumenten. Der Baustein kann zusätzliche APIs implementieren; die aufgeführten definieren jedoch den minimalen Funktionsumfang jeder Implementierung.
| API | Beschreibung | Protokoll |
|---|---|---|
| Repository API | CRUD für Repositories, Branch-Protection-Regeln, Webhook-Konfiguration. | REST / OpenAPI 3.1 |
| Pipeline API | Trigger, Status, Logs von Pipeline Runs. | REST / gRPC (Tekton) |
| Artifact API | Abfrage von Build-Artefakten, SBOMs und Signaturen. | OCI Distribution Spec |
| Deployment API | Deployment-Trigger, Status, Rollback, Environment-Management. | REST / GitOps (Git Push) |
| Portal API | Self-Service-Onboarding, Team-Verwaltung, Template-Katalog. | REST / OpenAPI 3.1 |
account_tree 9 Interne Workflowsfeedback
Dieser Abschnitt bietet einen detaillierten Überblick darüber, wie dieser Baustein intern arbeitet und mit anderen Bausteinen interagiert, um gängige Anwendungsfälle zu unterstützen. Die Workflows zeigen den Datenfluss von der Codeänderung bis zum produktiven Deployment sowie die automatisierte Reaktion auf neu veröffentlichte Schwachstellen.
9.1 Workflow: Secure Build & Deployfeedback
Der zentrale End-to-End-Workflow beschreibt den Weg eines signierten Commits über die CI-Pipeline bis zum GitOps-gesteuerten Deployment. Jeder Schritt enthält automatische Security-Gates; bei kritischen Befunden wird die Pipeline blockiert, bei fehlgeschlagenen Health Checks erfolgt ein automatisches Rollback.
9.2 Workflow: Schwachstellen-Reaktionfeedback
Dieser Workflow beschreibt die automatisierte Reaktion auf neu veröffentlichte CVEs oder CSAF-Advisories. Ein Continuous Scanner gleicht neue Schwachstellen gegen die SBOM-Datenbank aller deployten Artefakte ab und alarmiert die verantwortlichen Teams, die dann einen Patch-Zyklus über die reguläre Pipeline anstoßen.
link 10 Weiterführende Informationen und Quellenfeedback
Die folgende Tabelle verweist auf Spezifikationen, Standards und Werkzeuge, die für die Umsetzung dieses Bausteins relevant sind. Sie ergänzt die normativen Anforderungen um weiterführende Ressourcen für Architekten und Implementierer.
| Quelle | Beschreibung |
|---|---|
| Sicherer SDLC für Funktionsbausteine | D-Stack-Leitlinie zu DevSecOps, GitOps und Pipeline-Härtung. |
| GovStack CFR: Development | GovStack Cross-Functional Requirements für Softwareentwicklung. |
| Standard for Public Code | Leitfaden für öffentlichen Code – Wiederverwendbarkeit, Offenheit, Qualität. |
| SLSA Framework | Supply-chain Levels for Software Artifacts. |
| BSI TR-03183-2 | Technische Richtlinie für Software Bill of Materials (SBOM). |
| Sigstore / Cosign | Keyless Signing für Container und Artefakte. |
| Argo CD | GitOps Continuous Delivery für Kubernetes. |
| Open CoDE | Zentrale Code-Hosting-Plattform der öffentlichen Verwaltung. |
| CIS Kubernetes Benchmark | Härtungsrichtlinie für Kubernetes-Cluster. |
| BSI APP.4.4 Kubernetes | IT-Grundschutz-Baustein für Kubernetes. |