CI/CD-Pipeline für Verteidigungssoftware: Automatisierte Tests und Deployment für militärische Systeme

Ein kommerzielles Softwareteam kann eine neue Funktion in wenigen Minuten in die Produktion bringen: Ein Pull Request besteht automatisierte Tests, ein Reviewer genehmigt, die CI-Pipeline baut und deployed. Für Teams, die Verteidigungssoftware entwickeln, muss derselbe Lieferpfad einen grundlegend anderen Einschränkungsraum navigieren: ITAR-Exportregelungen, die den Zugang zu Build-Artefakten einschränken, STIG-Compliance-Anforderungen, die die Konfiguration jeder Schicht des Stacks definieren, SBOM-Mandate, die ein maschinenlesbares Inventar jeder Abhängigkeit erfordern, sowie Deployment-Umgebungen, die möglicherweise überhaupt keine Internetverbindung haben. Das Ergebnis ist, dass viele Verteidigungsprogramme CI/CD entweder ganz zugunsten manueller, mehrstufiger Release-Prozesse aufgeben — oder kommerzielle CI/CD-Tools ohne die Compliance-Verkabelung einsetzen und damit Audit-Verbindlichkeiten schaffen.

Keines dieser Ergebnisse ist notwendig. Eine CI/CD-Pipeline für Verteidigungssoftware, die ITAR-Kontrollen erfüllt, STIG-konforme Artefakte produziert, signierte SBOMs generiert und in Air-Gap-Umgebungen deployed, ist mit verfügbaren Open-Source-Tools und einem klaren Architekturmuster erreichbar. Dieser Artikel beschreibt dieses Muster und behandelt Pipeline-Infrastrukturoptionen, automatisierte Testphasen, SBOM-Generierung, Container-Härtung, Air-Gap-Deployment, Rollback-Verfahren und Audit-Trail-Anforderungen.

Einschränkungen bei Verteidigungssoftware: ITAR, STIG und Klassifikationshandling in CI

Die International Traffic in Arms Regulations (ITAR) kontrollieren den Export von Verteidigungsartikeln und -diensten, einschließlich technischer Daten zu Verteidigungssystemen. Im CI/CD-Kontext können Quellcode, Build-Artefakte und Testergebnisse der Exportkontrolle unterliegen, und der Zugang muss auf US-Personen beschränkt sein. Build-Runner, die ITAR-kontrollierten Code verarbeiten, müssen auf Systemen laufen, wo der Zugang auf Infrastrukturebene durchgesetzt wird — selbstverwaltete Runner auf lokaler Hardware oder Runner in einer FedRAMP High oder DoD IL4/IL5 Cloud-Enklave mit dokumentierten Zugriffskontrollen.

Der Technology Control Plan (TCP) des Programms muss die CI/CD-Infrastruktur in seinem Geltungsbereich einschließen. Die Klassifikationsbehandlung fügt eine weitere Einschränkung hinzu: Die CI/CD-Pipeline selbst läuft auf dem höchsten Klassifikationsniveau aller von ihr produzierten Artefakte.

Pipeline-Architektur: On-Premises GitLab vs. SaaS, Air-Gap-Überlegungen

GitLab self-managed ist die dominante CI/CD-Plattformwahl für vertrauliche Verteidigungsprogramme. Es läuft vollständig auf der von Ihnen kontrollierten Infrastruktur, unterstützt vollständig Offline-Installation, integriert sich mit Active Directory und LDAP für die Zugriffskontrolle und hat eine große installierte Basis in DoD-Programmen. Das Artefakt-Registry muss ebenfalls auf von Ihnen kontrollierter Infrastruktur laufen — Harbor für Container, Artifactory oder Nexus für Sprachökosystem-Abhängigkeiten. Bei Air-Gap-Deployments bringt ein Mirror-Aktualisierungsprozess externe Inhalte über den Air Gap nach einem dokumentierten Zeitplan.

Automatisierte Testphasen: von Unit-Tests bis zur STIG-Compliance-Prüfung

Eine CI/CD-Pipeline für die Verteidigung erfordert: Unit- und Integrationstests bei jedem Commit; SAST (Semgrep oder SonarQube) bei jedem Pull Request; DAST (OWASP ZAP) gegen eine deployed Test-Instanz; Software-Kompositionsanalyse (Grype oder Trivy) gegen einen internen Schwachstellen-Mirror; STIG-Compliance-Scanning (InSpec mit DISA-Profilen oder OpenSCAP); Secrets-Erkennung; und Lizenz-Compliance. Jede Phase stoppt die Pipeline bei Policy-Verstößen ohne manuelle Umgehungsmöglichkeit.

SBOM-Generierung: CycloneDX/SPDX, Grype/Trivy, Lizenz-Compliance

NDAA Section 1655 (FY2023) verpflichtete das DoD, Leitlinien zu entwickeln, die SBOMs von Softwarelieferanten erfordern. SBOMs werden zur Build-Zeit mit Syft oder cdxgen im CycloneDX- oder SPDX-Format generiert, zusammen mit dem Build-Artefakt mit Cosign signiert und als erstklassige Artefakte im Artefakt-Registry gespeichert. Grype oder Trivy gleichen SBOM-Komponenten mit CVE-Datenbanken ab und produzieren VEX-Annotationen. Die Lizenz-Compliance wird als parallele Gate durchgesetzt.

Container-Härtung: Distroless-Basisimages, Non-Root-Ausführung, Seccomp, Image-Signierung

Verteidigungscontainer-Images verwenden Distroless- oder DISA STIG-gehärtete Basisimages, laufen als Nicht-Root-Benutzer, verwenden schreibgeschützte Root-Dateisysteme, wenden RuntimeDefault- oder benutzerdefinierte Seccomp-Profile an und werden mit Cosign oder Notary v2 signiert. Admission-Controller (OPA/Gatekeeper oder Kyverno) erzwingen diese Anforderungen beim Pod-Scheduling-Zeitpunkt in allen Clustern.

Deployment in klassifizierte Umgebungen: Sneakernet-Transfer, Hash-Verifizierung, Manifest-Signierung

Die Pipeline produziert ein signiertes Deployment-Paket, das enthält: signierte Binärdateien oder Container-Images, SBOM, Schwachstellen-Scan-Ergebnisse, SLSA-Provenienz-Attestierung, Deployment-Manifest und SHA-256-Hash-Datei. Der Transfer über den Air Gap erfolgt über eine akkreditierte Cross-Domain-Lösung oder dokumentierte Sneakernet-Verfahren. Auf der klassifizierten Seite verifiziert das Installationsskript Hash und Signatur vor dem Fortfahren.

Rollback-Verfahren: Blue-Green für Dienste, SQLite-Snapshots für eingebettete Systeme

Webdienste verwenden Blue-Green-Deployments — Rollback ist ein Traffic-Switch, keine erneute Deployment. Eingebettete Systeme und SQLite-basierte Anwendungen verwenden versionierte Vor-Upgrade-Snapshots. Die CI-Pipeline testet den Snapshot/Restore-Pfad in Integrationstests. Alle Rollback-Ereignisse werden im unveränderlichen Audit-Trail protokolliert.

Audit-Trail-Anforderungen: unveränderliche Logs, Änderungsgenehmigungen, Anforderungsverfolgbarkeit

Pipeline-Logs werden in einem Write-Once-SIEM oder Object-Storage-Sink mit Object-Locking gespeichert. Jedes Deployment referenziert ein genehmigtes Change-Ticket. Die Verfolgbarkeit verknüpft Entwicklungsarbeitselemente mit Anforderungselementen, wobei Testergebnisse an Arbeitselemente angehängt werden. Die Pipeline hängt Testergebnis-Zusammenfassungen und Artefakt-Hashes an das relevante Issue bei Deployment-Abschluss an.