Sicherer SDLC für Funktionsbausteine im Deutschland-Stackfeedback

Leitlinie zu DevSecOps und GitOps – Schutz vor Lieferketten-Angriffen, Schwachstellen-Prüfung im Betrieb. Adressaten: Bund, Länder, Kommunen und deren IT-Dienstleister.

Geltungsbereich	Rechtsgrundlage	Zielarchitektur
Alle Funktionsbausteine des D-Stacks – insb. der Plattformkern: Identität & Vertrauen, Datenaustausch, Nachweisdatenabruf, Ein- und Auszahlung, Postfach und Interaktion.	IT-PLR-Beschluss B-2026/03-IT v. 18.03.2026 inkl. Anlage Standards und Anlage Portfolio; Modernisierungsagenda Bund; D-Stack-Architekturprinzip „DevSecOps only"; NIS-2; EU-CRA.	CNCF-konformes Kubernetes mit gehärteten Container-Images. BSI APP.4.4 Kubernetes und SYS.1.6 Containerisierung; SBOM nach TR-03183-2; Advisories nach TR-03191 (CSAF); Open Source via Open CoDE/ZenDiS.

Betrieblicher Schwerpunkt

Für die Absicherung von Fachanwendungen im Betrieb (Zero-Trust-Anbindung, Netzwerksegmentierung, Detection as a Service) siehe die Referenzarchitektur Fachanwendungen absichern.

---

1. Worum geht es?feedback

• SDLC (Software Development Lifecycle): der gesamte Lebensweg eines Funktionsbausteins – von Anforderung, Quellcode, Build, Test, Auslieferung bis zum Betrieb und zur Stilllegung.

• DevSecOps: Sicherheit (Sec) ist in jeden Schritt von Entwicklung (Dev) und Betrieb (Ops) eingebaut – kein nachgelagertes Audit. Im D-Stack als Architekturprinzip festgeschrieben („DevSecOps only").

• GitOps: Der Soll-Zustand jedes Zielsystems (Konfiguration, Infrastruktur, Anwendung) liegt versioniert in Git. Änderungen erfolgen ausschließlich per Pull Request mit Reviews; ein Operator gleicht den Cluster automatisch ab. Vorteil für die Verwaltung: auditierbar, revisionssicher, prüfbar, rollbar.

• Funktionsbaustein: Ein modularer, wiederverwendbarer Service des D-Stacks mit dokumentierter API, der von Bund, Ländern und Kommunen nachgenutzt werden kann. → Übersicht aller Funktionsbausteine

2. Aktuelle Bedrohungslage: Lieferketten-Angriffefeedback

Eine Software-Lieferkette umfasst alle Bausteine eines Funktionsbausteins: Quellcode, Bibliotheken Dritter, Container-Images, Build-Werkzeuge, CI/CD-Pipelines, Signaturschlüssel. Aktuelle Vorfälle:

• npm-qix-Vorfall (2025): Phishing kompromittierte den Account eines Paket-Contributors. 18 Pakete mit ~2,6 Mrd. Downloads/Woche wurden manipuliert.

• Shai-Hulud-Wurm (2025): Selbst verbreitender Wurm im npm-Ökosystem; stahl CI/CD-Geheimnisse, betraf rund 25.000 GitHub-Repositories.

• tj-actions/changed-files (CVE-2025-30066): Manipulierte GitHub-Action-Tags (Tag Poisoning) saugten Geheimnisse aus CI-Umgebungen ab; betroffen waren ~23.000 Repositories.

• xz-utils (CVE-2024-3094): Langfristig über zwei Jahre eingeschleuster Hintertür-Code in einer Linux-Standard-Bibliothek (liblzma); ermöglichte Remote-Code-Execution via sshd. Nur per Zufall bei Performance-Tests entdeckt.

• Trivy-Kompromittierung (März 2026): Am 01.03.2026 wurde ein Personal Access Token (PAT) eines Trivy-Maintainers gestohlen. Am 19.03.2026 wurde ein manipuliertes Release v0.69.4 mit eingebettetem C2-Callback veröffentlicht, das Scanner-Ergebnisse unterdrückte. Erkennung durch Community-Audit nach unerklärter Binary-Größenänderung.

• Codecov Bash Uploader (2021): Angreifer modifizierten das Codecov Bash-Upload-Skript über einen kompromittierten Docker-Image-Build; CI-Umgebungsvariablen und Secrets von tausenden Repositories wurden über Wochen exfiltriert.

• SolarWinds Sunburst (2020): Kompromittierung des Build-Systems; signierte Updates mit Backdoor an ~18.000 Organisationen ausgeliefert – Referenzfall für Build-Integrität und Provenance-Anforderungen.

Konsequenz für DSI1-konforme Funktionsbausteine: Jede Lieferkette muss nachweisbar abgesichert sein – durch Provenance, SBOM und signierte Artefakte.

3. Schwachstellen-Datenbankenfeedback

• CVE (Common Vulnerabilities and Exposures): Weltweiter Katalog mit eindeutiger Nummer pro Lücke. Träger: MITRE/CVE.org.

• CVSS (Common Vulnerability Scoring System, FIRST.org): Schweregrad 0–10 (kritisch ≥ 9,0).

• NVD: nvd.nist.gov (NIST).

• In Deutschland: CERT-Bund / WID-Warndienst des BSI.

• CSAF 2.0 (BSI TR-03191, ISO-Standard seit 2025): Maschinenlesbares JSON-Format für Sicherheitsmeldungen. Lässt sich automatisch gegen die SBOM eines Funktionsbausteins abgleichen – Voraussetzung für 24/7-Betrieb auf föderaler Ebene.

4. DevSecOps + GitOps Anforderungen für Stack-konforme Funktionsbausteinefeedback

4.1 Quellcode-Veröffentlichungfeedback

Auf Open CoDE mit signierten Commits, Branch Protection, verpflichtenden Code Reviews und Secret Scanning.

4.2 Abhängigkeiten festschreiben (Pinning)feedback

Exakte Versionen, Lockfiles im Repository, keine offenen Versionsbereiche.

4.3 SBOM (Software Bill of Materials)feedback

Stückliste aller Komponenten – automatisch im Build erzeugen, im Format SPDX oder CycloneDX, gemäß BSI TR-03183-2. Pflichtartefakt für die Aufnahme in den D-Stack-Marktplatz.

4.4 Signierte Builds & Provenancefeedback

Container und Pakete digital signieren (Sigstore/Cosign) und Herkunftsnachweis nach SLSA mindestens Level 3.

4.5 Scans in der Pipelinefeedback

SAST (statische Codeanalyse), SCA (Abhängigkeitsanalyse), Container- und IaC-Scans (z. B. Trivy, Grype). Kritische Funde blockieren das Deployment.

4.6 Pipeline-Härtung gegen Lieferketten-Angriffefeedback

Scanner-Versionen, Base-Images und CI-Actions ausschließlich per SHA-256-Digest pinnen (keine mutable Tags); Container und CI-Actions vor Ausführung mit Cosign verifizieren; Mehrgleisigkeit durch Parallelbetrieb von Trivy + Grype, um Single-Tool-Risiken auszuschließen; GitHub-Actions-Runner mit Harden-Runner (Egress-Filter, Tamper-Detection) gegen Geheimnis-Exfiltration absichern.

Hintergrund: Trivy-Vorfälle März 2026 (PAT-Diebstahl 01.03., manipuliertes Release v0.69.4 am 19.03. mit C2-Callback).

4.7 Gehärtete Container-Imagesfeedback

Pflicht: minimale Distroless-Images mit Ziel „0 known CVEs"; non-root, read-only-rootfs, Pod Security Standard „restricted"; Compliance gegen CIS Kubernetes Benchmark. Souveräne Bezugsquellen: ZenDiS-/AA-Container-Härtung auf Open CoDE (DVS-/CRA-konform), SUSE Base Container Images (FIPS 140-3) oder eigene Hardening-Pipeline mit Sigstore/Cosign.

4.8 GitOps auf gehärteten Kubernetes-Zielsystemenfeedback

Cluster-Zustand ausschließlich aus Git, ausgerollt durch Argo CD oder Flux; Drift wird automatisch erkannt und korrigiert. Cluster-Härtung gemäß BSI-Baustein APP.4.4 (Identitäts- & Rechtekonzept, RBAC, Audit-Log, Secrets): verifiziert mit kube-bench/Kubescape.

4.9 Single Path to Productionfeedback

Code, Infrastruktur as Code und Patches durchlaufen denselben Git→CI/CD→GitOps-Pfad. Plattform-Varianten (ITZBund/BWI/Dataport/Komm.ONE/AKDB) als parametrisierte OpenTofu-Module (souveräner LF-Fork von Terraform, MPL); IaC-Scans mit Trivy/Checkov. CVE-Fixes via Express-Lane, kein Pipeline-Bypass.

4.10 Geheimnisse & Tokensfeedback

Keine langlebigen Tokens; OIDC „Trusted Publishing" für Paket-Releases; Vault/Sealed Secrets; sofortige Rotation nach jedem Vorfall.

4.11 Product Ownership der DevSecOps-Werkzeugkettefeedback

Für jede Komponente (Scanner, Registry, GitOps-Operator, Secrets-Backend, CI-Runner) ist eine zentrale Maßnahmenverantwortung samt DACI-Matrix verbindlich zu hinterlegen (Driver = operative Pflege, Approver = Freigabeinstanz, Contributors = mitwirkende IT-DLZ, Informed = nachgelagerte Stellen).

DACI-Matrix DevSecOps-Werkzeugkettefeedback

Beispielbelegung – ist im Rahmen der Governance final auszuhandeln:

Komponente	Driver (operativ)	Freigabe	Contributors	Informed
SBOM- & Scanner-Stack (Trivy/Grype, ISDuBA)	ZenDiS / BSI	BMDS DSI1	ITZBund, BWI, Dataport, Komm.ONE	CERT-Bund, FB-Teams
Container-Härtung & Signatur (ZenDiS-Images, Cosign)	ZenDiS	BMDS DSI1	AA, BWI, Open-CoDE-Community	CERT-Bund, FB-Teams
GitOps-Operator (Argo CD/Flux)	ITZBund	BMDS DSI1	BWI, Dataport, AKDB	FB-Teams, CERT-Bund
Secret-Management (OpenBao/Vault, Sealed Secrets)	ITZBund	BMDS DSI1, BSI	BWI, Dataport, AKDB	FB-Teams, CERT-Bund
CI-Runner-Härtung (Harden-Runner, OIDC Trusted Publishing)	ZenDiS	BMDS DSI1	BWI, ITZBund, FB-Teams	CERT-Bund

Lesart: Driver = einzige operativ pflegende Stelle (Patches, Releases, Eskalation), Approver = Freigabe-/Leitlinieninstanz (genau eine), Contributors = mitwirkende Betreiber, Informed = nachgelagerte Empfänger. Konkrete Belegung wird im DSI1-Architekturboard final festgelegt.

5. Betrieb der Zielsysteme: Schwachstellen-Prüfung in der föderalen Praxisfeedback

Verantwortlich sind die jeweiligen IT-Dienstleister – auf Bundesebene insb. ITZBund und BWI, auf Landesebene Dataport, Komm.ONE, auf kommunaler Ebene AKDB und kommunale RZ. Mindestmaß:

5.1 Inventur mit SBOMfeedback

Jeder Funktionsbaustein wird im BSI Schwachstellen-Tool ISDuBA oder gleichwertig als CSAF-fähiger Asset hinterlegt.

5.2 Authentifizierte Scans + CSAF-Feedsfeedback

Authentifizierte Schwachstellen-Scans aller Hosts und Container mit OpenVAS / Greenbone CE (BSI-gefördert) und Container-Registry-Scans; Hersteller-/Distro-Advisories als CSAF-Feeds automatisch gegen die SBOM abgleichen.

5.3 Risikobasiertes Patch-Managementfeedback

Patches durchlaufen die identische Pipeline, kein manueller Hotfix am Cluster (Drift würde sofort revertiert). Priorisierung über CVSS + Internet-Exposure + CISA KEV-Liste. SLA: kritisch (CVSS ≥ 9,0) zeitnah, hoch ≤ 14 Tage.

5.4 Härtung & Monitoringfeedback

BSI APP.4.4 Kubernetes + SYS.1.6 als Maßstab; Admission-Control, Network Policies, Endpoint Detection and Response; Zero-Trust-Segmentierung gemäß D-Stack-Architekturprinzip.

5.5 Open-Source-Hygiene & Meldepflichtfeedback

Auf gepflegte Upstream-Projekte achten (OpenSSF Scorecard); kritische Bibliotheken über die Sovereign Tech Agency mitfinanzieren. Schwachstellen über die CVD-Richtlinie des BSI an CERT-Bund melden.

---

6. IT-Grundschutz++ – Auswirkungen auf den SDLC-Prozessfeedback

Mit IT-Grundschutz++ modernisiert das BSI den IT-Grundschutz grundlegend. Die Fortentwicklung hat direkte Konsequenzen für den sicheren SDLC von D-Stack-Funktionsbausteinen:

6.1 Policy-as-Code aus maschinenlesbaren Regelnfeedback

IT-Grundschutz++ liefert Sicherheitsanforderungen erstmals als maschinenlesbares JSON-Format. Damit können Compliance-Prüfungen direkt in die CI/CD-Pipeline integriert werden – ohne manuelle Interpretation von PDF-Dokumenten. Konkret bedeutet das:

• Pipeline-Gate: IT-Grundschutz++-Regeln werden als OPA/Kyverno-Policies in die Build-Pipeline (Abschnitt 4.5) eingebunden. Ein Funktionsbaustein, der die geforderten Schwellwerte nicht erreicht, wird nicht deployt.
• Automatische Policy-Generierung: Aus dem JSON-Regelwerk können Admission-Controller-Policies für Kubernetes automatisiert abgeleitet werden (Abschnitt 4.8).
• Audit-Trail in Git: Da Policies als Code in Git liegen (GitOps-Prinzip), ist jede Regeländerung versioniert und nachvollziehbar.

6.2 Dynamische Schwellwerte statt starrer Absicherungsstufenfeedback

Die bisherigen Absicherungsstufen (Basis/Standard/Erhöhter Schutzbedarf) passen nicht zu elastischen Cloud-Umgebungen. IT-Grundschutz++ ersetzt sie durch dynamische Leistungszahlen, die kontextabhängig bewertet werden. Für den SDLC bedeutet das:

• Risikoadaptive Pipeline-Gates: Funktionsbausteine mit höherer Kritikalität (z. B. Authentifizierung, Datenaustausch) erhalten automatisch strengere Schwellwerte als interne Hilfs-Services.
• Kontinuierliche Bewertung: Der Sicherheitsstatus wird nicht einmal bei Zertifizierung gemessen, sondern bei jedem Deployment und im laufenden Betrieb (Abschnitt 5.4).

6.3 SBOM als Brücke zwischen Build und Grundschutz++feedback

Die in Abschnitt 4.3 geforderte SBOM wird zum zentralen Bindeglied: IT-Grundschutz++ referenziert SBOM-Anforderungen in der Säule „Anwendungen" (Leistungszahl ≥ 80). Die SBOM ermöglicht den automatisierten Abgleich mit CSAF-Advisories (Abschnitt 5.2) und erfüllt damit gleichzeitig die neuen Grundschutz++-Regeln.

6.4 Zero-Trust-Anforderungsprofile in der Pipelinefeedback

IT-Grundschutz++ definiert explizite Anforderungsprofile für die Zero-Trust-Säulen. Die Säule „Automatisierung" (OPS-Bausteine + Policy-as-Code-Regeln) adressiert direkt den DevSecOps-Prozess: Jede Pipeline muss nachweisen, dass Sicherheitskontrollen automatisiert und nicht manuell umgehbar sind.

Handlungsempfehlung

Teams sollten bereits jetzt ihre CI/CD-Pipelines so strukturieren, dass Policy-Gates als austauschbare Module implementiert sind. Sobald IT-Grundschutz++-Regeln als JSON verfügbar werden, können diese ohne Pipeline-Umbau eingebunden werden.

---

Beteiligte Funktionsbausteinefeedback

Funktionsbaustein	Bezug zum SDLC
Entwicklung und Bereitstellung	CI/CD-Pipeline, Build-Umgebung
Cloud-Infrastruktur	Kubernetes-Zielsysteme
Zero-Trust-Governance	Netzwerk-Segmentierung, Policy-Engine
Detektion und Reaktion	Detection as a Service (DaaS), SIEM/SOC
Authentifizierung	Identity & Access Management
Marktplatz	SBOM als Pflichtartefakt für Aufnahme

Zusammenspiel der Funktionsbausteine im SDLCfeedback

Die Funktionsbausteine sind keine isolierten Komponenten – sie greifen entlang des gesamten Lebenszyklus ineinander:

Durchlaufrichtung (links → rechts):

1. Entwicklung und Bereitstellung ist der Startpunkt: Hier entsteht der Code, wird gebaut, getestet und signiert. Dabei werden SBOM und Provenance-Metadaten erzeugt.

2. Authentifizierung sichert den Zugang zur Pipeline ab: Entwickler authentisieren sich per MFA, CI/CD-Pipelines nutzen OIDC Trusted Publishing (Abschnitt 4.10) statt langlebiger Tokens. Im Betrieb erhalten Workloads maschinengebundene Identitäten (Workload Identity).

3. Zero-Trust-Governance wirkt in zwei Richtungen:

   • In der Pipeline als Policy-Gate (Abschnitt 4.5/6.1): OPA/Kyverno-Policies prüfen, ob ein Artefakt die Schwellwerte erfüllt, bevor es deployt werden darf.
   • Im Cluster als Admission Controller: Nur signierte, policy-konforme Container werden zugelassen (Abschnitt 4.8).

4. Cloud-Infrastruktur nimmt das deployte Artefakt entgegen. Der GitOps-Operator (Argo CD/Flux) gleicht den Soll-Zustand aus Git gegen den Ist-Zustand im Kubernetes-Cluster ab. Drift wird automatisch erkannt und korrigiert – Änderungen außerhalb des Git-Pfades sind nicht möglich.

5. Detektion und Reaktion überwacht den laufenden Betrieb: Runtime-Scans erkennen neu bekannt gewordene CVEs in bereits deployten Containern und lösen über die Express-Lane (Abschnitt 4.9) automatisiert Patches aus. Anomalie-Erkennungen (z. B. unerwarteter Egress-Traffic) fließen als Feedback in die Zero-Trust-Governance zurück und verschärfen ggf. Policies.

6. Marktplatz ist das Ziel: Ein Funktionsbaustein wird erst dort aufgenommen, wenn er den gesamten SDLC-Prozess durchlaufen hat – inklusive gültiger SBOM, signierter Provenance und bestandener Policy-Checks. Der Marktplatz ist somit der Qualitätsnachweis für nachnutzende Verwaltungen.

Rückkopplungsschleifen:

• Runtime → Build: Neu entdeckte CVEs im Betrieb (Detektion) triggern automatisiert einen neuen Pipeline-Durchlauf mit Patch.
• Governance → Pipeline: Verschärfte Grundschutz++-Schwellwerte werden als Policy-Update in Git committed und wirken beim nächsten Build sofort.
• Marktplatz → Governance: Der Marktplatz-Reifegrad definiert, welche Policy-Level ein Baustein mindestens erfüllen muss.

---

Quellen und Referenzenfeedback

• IT-PLR-Beschluss B-2026/03-IT
• D-Stack Architekturprinzipien
• Reifegrad & Kriterien
• BMDS / Deutschland-Stack
• IT-Grundschutz und IT-Grundschutz++ – Maschinenlesbare Sicherheitsanforderungen, Policy-as-Code, Zero-Trust-Anforderungsprofile
• Fachanwendungen absichern – Betrieblicher Schwerpunkt (Zero Trust, DaaS, Netzwerksegmentierung)