CI/CD-Pipelines für air-gapped Verteidigungsumgebungen

Standard-CI/CD-Pipelines basieren auf der Annahme einer allgegenwärtigen ausgehenden Internetverbindung. Jeder Runner lädt ein Basis-Image aus einer öffentlichen Registry, jeder Build löst Abhängigkeiten aus vorgelagerten Paket-Repositories auf, jedes Scan-Tool lädt beim Start aktuelle Signaturen für Schwachstellen herunter. In einer klassifizierten, air-gapped Verteidigungsumgebung gilt keine dieser Annahmen — und die technischen Konsequenzen reichen bis in jede Schicht der Toolchain. Dieser Leitfaden beschreibt die Architekturentscheidungen, Toolchain-Auswahl und betrieblichen Verfahren, die Continuous Integration und Delivery ohne Internetzugang auf STIG-gehärteter Infrastruktur innerhalb einer Akkreditierungsgrenze ermöglichen.

Warum Standard-CI/CD in air-gapped Verteidigungsumgebungen versagt

Der Fehlerfall ist kein einzelnes fehlendes Feature — es ist eine Kaskade von Annahmen, die in jedes moderne CI/CD-Tool eingebettet sind und beim Kontakt mit einer air-gapped Akkreditierungsgrenze zusammenbrechen. Das Verständnis dieser Fehlermodi im Voraus verhindert verschwendete Beschaffungszyklen und kurzfristige Architekturumkehrungen zu Beginn der ATO-Überprüfung.

Netzwerkisolierung. Ein klassifiziertes Netzwerksegment auf Secret-Ebene und darüber hinaus hat by Design keinen ausgehenden Internetzugang. Runner können keine Images von Docker Hub, Maven Central, npmjs.com oder PyPI abrufen. Build-Tools, die beim ersten Start Plugins oder Erweiterungen herunterladen, schlagen stumm oder mit kryptischen Fehlermeldungen über nicht erreichbare Hosts fehl. Update-Mechanismen in Jenkins, GitLab und den meisten kommerziellen CI-Tools kontaktieren beim Start einen entfernten Server — dieser Datenverkehr wird blockiert und erzeugt häufig Rauschen in der Netzwerküberwachungskonsole, das der ISSM dem AO erklären muss.

Software-Genehmigung und Akkreditierung. Jede innerhalb einer DoD-Akkreditierungsgrenze eingesetzte Softwarekomponente muss vom Authorizing Official (AO) als Teil des System Authorization Package genehmigt werden. Dies umfasst nicht nur den CI-Server, sondern jedes Plugin, jedes Build-Agent-Image und jede Bibliothek, von der die Pipeline selbst abhängt. „Wir verwenden die neueste Version aus der öffentlichen Registry" ist in einem ATO-Kontext keine akzeptable Antwort. Die genehmigte Software-Liste ist ein kontrolliertes Dokument; das Hinzufügen neuer Pakete erfordert eine formale Anfrage, einen Schwachstellen-Scan, eine Lizenzprüfung und — für Pakete ohne vorhandene STIG-Abdeckung — eine zusätzliche Dokumentationsbelastung für das Engineering-Team. Dieser Prozess dauert in der Regel Tage bis Wochen pro Paket, was Ad-hoc-Abhängigkeitsergänzungen mit dem Entwicklungstempo einer modernen CI-Pipeline unvereinbar macht. Die Lösung besteht darin, den Genehmigungsprozess vorzuziehen, indem jede Abhängigkeit vor der Pipeline-Bereitstellung identifiziert wird, nicht danach.

Tool-Beschaffung und Lizenzierung. Einige CI-Tools sind für Regierungsauftragnehmer unkompliziert verfügbar. Für andere sind spezifische Lizenzvereinbarungen für den Regierungseinsatz erforderlich. Wieder andere erfordern eine Exportkontrollprüfung (ITAR/EAR-Klassifizierung). Jenkins OSS und GitLab CE vermeiden die meisten dieser Probleme, was teilweise ihre Dominanz in klassifizierten Umgebungen erklärt. Kommerzielle CI-Plattformen, die proprietäre Runner, verwaltete Secrets-Dienste oder cloudbasierte Analysen bündeln, sind in einer air-gapped Umgebung ohne erhebliche Architekturmodifikation in der Regel nicht einsetzbar.

Das Nettoergebnis ist, dass air-gapped CI/CD von Grund auf neu konzipiert werden muss — nicht aus einem kommerziellen SaaS-Muster adaptiert. Die Bausteine sind verfügbar und bewährt — sie erfordern lediglich eine explizite Offline-Bereitstellung für jede Komponente, die eine Standard-Pipeline dynamisch auflösen würde. Für den übergeordneten DevSecOps-Rahmen, der diese Entscheidungen regelt, siehe unseren Leitfaden zu DevSecOps für Verteidigungspipelines.

Architektur der Offline-Artefakt-Registry

Die Artefakt-Registry ist der Lieferketten-Anker für eine air-gapped Build-Umgebung. Jede Abhängigkeit — JARs, npm-Pakete, Python-Wheels, Go-Module, RPMs — muss von innerhalb der Enklave bereitgestellt werden. Zwei Produkte dominieren diesen Bereich in klassifizierten Umgebungen: Sonatype Nexus Repository (OSS und Pro) und JFrog Artifactory (OSS und Pro). Beide sind auf RHEL ohne ausgehende Konnektivität für den Betrieb einsetzbar; beide unterstützen die Repository-Formate, die ein typisches Verteidigungssoftware-Projekt benötigt.

Die Topologie hat zwei Hälften. Auf der Low Side (internetverbunden, aber nicht klassifiziert) betreibt eine Kurator-Workstation dieselbe Nexus- oder Artifactory-Version wie die High-Side-Instanz. Der Kurator verwendet das integrierte Export-/Import-Tooling des Repository-Managers oder einen skriptgesteuerten Workflow, um genehmigte Artefakte abzurufen, ihre transitiven Abhängigkeiten aufzulösen, Prüfsummen gegen die veröffentlichten Hashes der vorgelagerten Registry zu verifizieren und ein signiertes Transferpaket zusammenzustellen. Der Signierschritt ist entscheidend: Das Transferpaket muss mit dem Programmtransferschlüssel signiert werden, damit das High-Side-System die Integrität vor dem Import überprüfen kann.

# Low-side Kurator: Transferpaket zusammenstellen und signieren
nexus-curator export \
  --format maven \
  --repos approved-central-proxy \
  --output /transfer/bundle-2026-06-24.tar.gz

# SHA-256-Manifest generieren
sha256sum /transfer/bundle-2026-06-24.tar.gz \
  > /transfer/bundle-2026-06-24.manifest

# Manifest mit dem Programm-Transferschlüssel GPG-signieren
gpg --detach-sign --armor \
  --local-user transfer@program.mil \
  /transfer/bundle-2026-06-24.manifest

# Physischer Transfer via verschlüsseltem Wechseldatenträger oder Data Diode
# ...

# High-side Import: vor dem Entpacken verifizieren
gpg --verify bundle-2026-06-24.manifest.asc \
              bundle-2026-06-24.manifest
sha256sum -c bundle-2026-06-24.manifest
nexus-curator import --file bundle-2026-06-24.tar.gz
            

Auf der High Side bedient die Nexus- oder Artifactory-Instanz ausschließlich gehostete Repositories — es gibt keine Proxy-Repositories, die auf externe URLs zeigen, da diese nicht erreichbar sind. Konfigurationsdateien der Build-Agent-Tools verweisen ausschließlich auf den internen Hostnamen. Eine Tabelle der Konfigurationsdateien, die geändert werden müssen:

Die Kurationskadenz ist eine politische Entscheidung: in der Regel monatlich für Sicherheits-Patches, vierteljährlich für neue Abhängigkeitsversionen und sofort für jede CVE mit einem CVSS-Score über 8,0. Das Configuration Control Board des Programms ist für jede Importentscheidung zuständig.

STIG-gehärteter CI-Server: Jenkins oder GitLab auf klassifizierter Infrastruktur

Die beiden häufigsten Optionen für die CI-Ausführung auf klassifizierter Infrastruktur sind Jenkins (die seit langem dominierende Option, weit verbreitet in DoD-Programmen seit Mitte der 2010er Jahre) und GitLab (zunehmend bevorzugt für neue Programme aufgrund des veröffentlichten DISA STIG und seiner integrierten DevSecOps-Funktionen). Beide können konform gemacht werden; der Aufwand und das verbleibende Risikoprofil unterscheiden sich.

Für Jenkins ist die Härtungsbaseline die DISA Application Server SRG kombiniert mit dem RHEL 9 STIG für das zugrunde liegende Betriebssystem. Die Jenkins-spezifische Härtungscheckliste umfasst folgende Bereiche:

• Jenkins CLI über Remoting deaktivieren (CVE-2024-23897-Klasse von Schwachstellen); CLI nur über SSH verwenden, falls erforderlich.
• Content Security Policy (CSP)-Header aktivieren, um XSS in der Build-Konsolenausgabe zu verhindern.
• Script-Console-Zugriff für Nicht-Admin-Benutzer deaktivieren; Groovy-Sandbox-Ausbrüche einschränken.
• Matrix-basierte Sicherheit mit Principle of Least Privilege konfigurieren: Entwickler können Builds auslösen, aber keine Agents oder Anmeldeinformationen verwalten.
• Audit-Log-Plugin aktivieren; Protokolle an das Enklave-SIEM weiterleiten.
• JENKINS_HOME auf einem Dateisystem mit Zugriffskontrollen einrichten; weltlesbare Berechtigungen für credentials.xml einschränken.
• Update-Site-Verbindungen deaktivieren (hudson.model.UpdateCenter.never=true in jenkins.properties).
• Jenkins als dediziertes Nicht-Root-Dienstkonto ausführen; SELinux-Kontexte anwenden.

GitLab CE/EE auf RHEL profitiert vom DISA GitLab Enterprise Edition STIG (V1R1, veröffentlicht 2022), der Steuerungen direkt GitLab-Konfigurationseinstellungen zuordnet. Schlüsselkontrollen umfassen die Durchsetzung von TLS 1.2 als Minimum, Deaktivierung von Registrierung und OAuth-Anbietern, Aktivierung von Audit-Ereignissen für Syslog, Einschränkung des Git-Protokolls auf SSH über einen bekannten Port und Deaktivierung von Auto-DevOps-Funktionen, die ausgehende Verbindungen herstellen. GitLabs integrierte Registry, Merge-Request-Workflow und Pipeline-YAML-Syntax reduzieren die Anzahl separat akkreditierter Komponenten im Vergleich zu einem Jenkins-zentrierten Stack, was oft der entscheidende Faktor in Programmen mit engen ATO-Zeitplänen ist.

In beiden Fällen müssen Build-Agents innerhalb derselben Klassifizierungsgrenze wie der Controller betrieben werden. Agent-Images werden aus genehmigten Basis-Images erstellt, die in der Container-Registry der Enklave gespeichert sind, und werden nach einem definierten Zeitplan (in der Regel monatlich) neu erstellt, um OS-Patch-Updates zu integrieren, die durch den Kurationsworkflow übertragen wurden.

Getrennte Container-Registry

Container-Images in einer air-gapped Pipeline müssen innerhalb der Enklave gespeichert, gescannt und signiert werden. Zwei Produkte sind am häufigsten anzutreffen: Harbor (CNCF-graduated, weit verbreitet in DoD Platform One-Umgebungen) und Red Hat Quay (unterstützt unter dem DoD-Unternehmens-Red-Hat-Abkommen, eng integriert mit OpenShift). Beide unterstützen OCI-Image-Signierung, rollenbasierte Zugriffssteuerung und Schwachstellen-Scanning mit Offline-Datenbanken.

Die anfängliche Befüllung der Registry folgt demselben Transferworkflow wie die Artefakt-Registry: genehmigte Basis-Images (RHEL UBI, gehärtete Iron Bank-Images, genehmigte Anwendungs-Basisebenen) werden von der Low Side als OCI-Tarballs exportiert, übertragen und mit skopeo copy in Harbor oder Quay importiert:

# Low Side: genehmigte Images als OCI-Tarballs exportieren
skopeo copy \
  docker://registry.access.redhat.com/ubi9/ubi:9.4 \
  oci-archive:/transfer/ubi9-9.4.tar \
  --override-os linux

# Manifest generieren und signieren
sha256sum /transfer/ubi9-9.4.tar >> /transfer/images.manifest
gpg --detach-sign --armor --local-user transfer@program.mil \
    /transfer/images.manifest

# High Side: verifizieren und importieren
gpg --verify images.manifest.asc images.manifest
sha256sum -c images.manifest
skopeo copy \
  oci-archive:/transfer/ubi9-9.4.tar \
  docker://harbor.enclave.mil/base/ubi9:9.4 \
  --dest-creds admin:${HARBOR_TOKEN}
            

Image-Signierung mit Cosign im Offline-Modus verwendet einen langlebigen Signierschlüssel, der im Vault Transit Engine der Enklave gespeichert ist, und umgeht das Sigstore-Transparenzprotokoll (das internetgehostet ist). Der Signierschlüssel wird innerhalb von Vault generiert und nie exportiert; die CI-Pipeline ruft die Vault Transit API auf, um den Image-Digest zu signieren, und hängt die resultierende Signatur als OCI-Artefakt neben dem Image-Manifest in Harbor an. Die Überprüfung zur Admission-Zeit wird durch eine Kyverno-Richtlinie gehandhabt, die den Cosign-Verifizierer gegen Harbor unter Verwendung des internen PKI-Vertrauenspakets der Enklave aufruft.

# Image mit Vault Transit Key signieren (kein Transparenzprotokoll)
cosign sign \
  --key hashivault://transit/keys/image-signing-key \
  --no-tlog-upload \
  harbor.enclave.mil/myapp/service:v1.4.2@sha256:abc123...

# Kyverno-Richtlinie: gültige Cosign-Signatur auf jedem Pod erforderlich
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-signature
    match:
      resources:
        kinds: [Pod]
    verifyImages:
    - imageReferences: ["harbor.enclave.mil/*"]
      attestors:
      - entries:
        - keys:
            publicKeys: |-
              -----BEGIN PUBLIC KEY-----
              ... (öffentlicher Signierschlüssel der Enklave) ...
              -----END PUBLIC KEY-----
            rekor:
              ignoreTlog: true
            

Schwachstellen-Scanning innerhalb der Registry verwendet Trivy oder Grype, konfiguriert mit einem Offline-Datenbankpaket. Die Schwachstellen-Datenbank (NVD, OSV, RedHat-Advisories) wird auf der Low Side heruntergeladen, auf die High Side übertragen und in den lokalen Datenbankpfad des Scanners geladen. Ein täglicher Pipeline-Job aktualisiert das Datenbankpaket durch den Kurationsworkflow, um das Wissen des Scanners innerhalb des Transferrhythmus aktuell zu halten.

Der Software-Transportworkflow: Sneakernet zum sicheren Update-Server

Der Begriff „Sneakernet" ist älter als CI/CD, aber das Konzept beschreibt genau, was air-gapped Software-Lieferung ermöglicht: physischer Datentransport zwischen Netzwerken unterschiedlicher Klassifizierungsstufen. In modernen klassifizierten Einrichtungen ist dieser Transport in einen dokumentierten Workflow mit obligatorischen Genehmigungsstufen, Prüfpfaden und Anforderungen an die Übergabekette systematisiert — vergleichbar mit dem, was automatisierte Lieferkettensicherheitskontrollen in einer verbundenen Umgebung bieten. Die Herausforderung für CI/CD-Pipelines besteht darin, dass die Transferzykluszeit — in der Regel in Tagen, nicht Millisekunden gemessen — in das Release-Planungsmodell eingebettet werden muss.

Der Workflow hat eine definierte Struktur:

Low-side Workstation (NICHT KLASSIFIZIERT)
    │
    ├─ [1] Kandidaten-Paketset zusammenstellen
    │      - herunterladen, transitive Abhängigkeiten auflösen
    │      - vorgelagerte Signaturen/Prüfsummen verifizieren
    │      - Malware-Scan (ClamAV / kommerzieller AV)
    │      - Schwachstellen-Scan (Grype Offline-DB)
    │      - Lizenzprüfung
    │
    ├─ [2] Signiertes Manifest generieren
    │      sha256sum * > manifest.txt
    │      gpg --detach-sign manifest.txt
    │
    ├─ [3] Transferanfrage einreichen (CMT/JIRA-Ticket)
    │      - Paketname, Version, Zweck, Lizenz
    │      - Ergebnisse des Schwachstellen-Scans beigefügt
    │
    ├─ [4] ISSO/AO-Überprüfung und -Genehmigung (Gate)
    │
    ├─ [5] Physischer Transfer
    │      - verschlüsselter USB (FIPS 140-2 validiert)
    │      - ODER Hardware-Data-Diode (Einwegverbindung)
    │      - Transferprotokolleintrag erstellt
    │
High-side sicherer Update-Server (KLASSIFIZIERT)
    │
    ├─ [6] Manifest-Signatur verifizieren
    │      gpg --verify manifest.txt.asc manifest.txt
    │      sha256sum -c manifest.txt
    │
    ├─ [7] In Nexus / Harbor importieren
    │
    └─ [8] Im Configuration-Management-Tool protokollieren
            

Paketsignierung erfolgt entweder mit GPG mit programmspezifischen Schlüsseln oder — in Programmen, die PKI-basiertes Tooling eingeführt haben — sigstore/cosign gegen die interne Rekor-Instanz des Programms. Der entscheidende Punkt ist, dass der für Transfermanifeste verwendete Signierschlüssel sich vom Schlüssel für die Build-Artefakt-Signierung unterscheidet. Der Transferschlüssel wird von der Kuratorrolle gehalten, nicht von automatisierten Build-Agents, da die Transfergenehmigung ein menschliches Gate ist, das nicht automatisierbar sein darf.

Für Programme mit hohem Patch-Tempo automatisieren Einweg-Hardware-Data-Dioden (wie von Owl Cyber Defense oder Waterfall Security) die physische Schicht des Transfers und bewahren dabei die Einweggarantie. Daten fließen nur von Low nach High; das High-Side-System kann keinen Datenverkehr zurücksenden. Dies eliminiert das Genehmigungsgate nicht, beseitigt aber den physischen Wechseldatenträgerschritt und kann verwendet werden, um nächtliche Patch-Pakete nach einem definierten Zeitplan zu übertragen. Siehe unsere umfassendere Behandlung der Lieferkettensicherheit für Verteidigungssoftware für den politischen Rahmen, der regelt, was in den Transferworkflow einfließt.

Automatisierung der STIG-Konformität in der Pipeline

Manuelle STIG-Checklisten sind mit einem Continuous-Delivery-Tempo unvereinbar. Ein Build, der täglich deployt wird, kann vor jeder Veröffentlichung nicht manuell gegen mehr als 300 STIG-Kontrollen überprüft werden. Die Lösung ist Compliance als Code: STIG-Kontrollen als maschinell prüfbare Richtlinien kodieren, die Richtlinie in der Pipeline als automatisiertes Gate ausführen und strukturierte Nachweise generieren, die die Anforderungen des AO an das kontinuierliche Monitoring erfüllen.

Die primäre Toolchain ist OpenSCAP mit dem SCAP Security Guide (SSG). SSG enthält XCCDF/OVAL-Inhalte für RHEL 8, RHEL 9 und verwandte Distributionen, die direkt auf DISA-STIGs abgebildet werden. In einer air-gapped Umgebung werden die SSG-Inhalte in das Build-Agent-Image gebündelt statt zur Laufzeit heruntergeladen:

# Pipeline-Stufe: STIG-Scan eines Lieferbaren Container-Images
stages:
  - build
  - stig-scan
  - sign
  - promote

stig-scan:
  stage: stig-scan
  image: harbor.enclave.mil/tools/openscap-runner:latest
  script:
    - |
      # Container-Image-Dateisystem zum Scannen einhängen
      skopeo copy \
        docker://harbor.enclave.mil/${CI_PROJECT_PATH}:${CI_COMMIT_SHA} \
        oci:./image-under-test

      # STIG-Profilauswertung ausführen
      oscap-chroot ./rootfs xccdf eval \
        --profile xccdf_org.ssgproject.content_profile_stig \
        --results stig-results.xml \
        --report stig-report.html \
        /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

      # Bei CAT I (hoher Schweregrad) Fehlern blockieren
      python3 /tools/parse-stig-results.py \
        --results stig-results.xml \
        --fail-on-severity high \
        --output stig-summary.json

  artifacts:
    paths:
      - stig-results.xml
      - stig-report.html
      - stig-summary.json
    expire_in: 90 days
            

Die DISA STIG Viewer-Anwendung kann die results.xml-Ausgabe von OpenSCAP aufnehmen und im vertrauten Checklistenformat anzeigen, das AOs und ISSOs bei Überprüfungen verwenden. Für Programme, die ein Continuous-Monitoring-Dashboard betreiben (das in der Regel ein SIEM oder ein GRC-Tool speist), wird die strukturierte JSON-Ausgabe des Parse-Skripts als Pipeline-Artefakt neben dem Build in das Nachweisrepository übertragen.

Ein häufiges Muster ist die Trennung von Host-Level-STIG-Scanning (vom Infrastructure-Team monatlich gegen die Build-Agent-Basis-Images ausgeführt) und Image-Level-STIG-Scanning (von der Anwendungspipeline bei jedem Build gegen das lieferbare Container-Image ausgeführt). Host-Level-Befunde betreffen das ATO der CI-Infrastruktur selbst und werden im POA&M des Systems verfolgt. Image-Level-Befunde werden auf Anwendungsebene verfolgt und liegen in der Verantwortung des Entwicklungsteams. Der Prüfpfad grenzt klar ab, welches Team für welchen Befund zuständig ist — was entscheidend ist, wenn ein Akkrediteur das Continuous-Monitoring-Nachweispaket prüft.

Für die SBOM-Durchsetzung in Verteidigungspipelines ergänzt die STIG-Scan-Ausgabe die SBOM, indem sie Nachweise liefert, dass auch die Laufzeitumgebung, in der das Artefakt ausgeführt wird, konform ist — nicht nur die Softwarekomponenten des Artefakts.

Secret-Management ohne Internet: HashiCorp Vault im Air-Gap-Modus

Secret-Management ist die Komponente, die in air-gapped Umgebungen am häufigsten schlecht improvisiert wird. Die häufige Improvisation — Anmeldedaten im integrierten Credential Store des CI-Servers, in einem gemeinsamen Passwort-Manager oder in Umgebungsvariablen, die in Agent-Images eingebettet sind, zu speichern — schlägt bei denselben Audit-Kontrollen fehl, die auch in einer verbundenen Umgebung versagen würden. Die genehmigte Lösung ist ein dediziertes Secret-Management-System, das innerhalb der Akkreditierungsgrenze eingesetzt wird.

HashiCorp Vault OSS (Open-Source, nicht Enterprise) erfordert keine Internetverbindung für den Betrieb. Es kann auf einem STIG-gehärteten RHEL-Host innerhalb der Enklave eingesetzt werden, initialisiert mit einem Shamir-Secret-Sharing-Schlüsselteilung, die auf autorisierte Schlüsselverwahrer verteilt wird:

# Vault mit 5 Schlüsselteilen initialisieren, Schwellenwert von 3
vault operator init \
  -key-shares=5 \
  -key-threshold=3

# Beispielausgabe (jeder Teil geht an einen separaten Verwahrer):
# Unseal Key 1: AbCdEf...
# Unseal Key 2: GhIjKl...
# Unseal Key 3: MnOpQr...
# Unseal Key 4: StUvWx...
# Unseal Key 5: YzAbCd...
# Initial Root Token: hvs.XXXXXX (einmal verwenden, dann widerrufen)

# Mit 3 von 5 Teilen entsperren (separate Operator-Zeremonie)
vault operator unseal  # Teil 1 eingeben
vault operator unseal  # Teil 2 eingeben
vault operator unseal  # Teil 3 eingeben
            

PKI-Bootstrapping in einer air-gapped Umgebung verwendet die integrierte PKI Secrets Engine von Vault zur Verwaltung der Zertifikatsinfrastruktur des Programms. Der Prozess: Root-CA-Schlüssel und -Zertifikat offline generieren (auf einer air-gapped Workstation, nicht innerhalb von Vault), den Root-CA-Schlüssel in einem Hardware-HSM oder einem verschlüsselten Offline-Backup gemäß dem Key-Management-Plan des Programms speichern. Das Root-CA-Zertifikat in Vault importieren. Innerhalb der PKI Engine von Vault ein Intermediate-CA-Schlüsselpaar und eine CSR generieren, die CSR mit der Root-CA signieren (Offline-Schritt), das signierte Intermediate-Zertifikat in Vault importieren. Von diesem Zeitpunkt an stellt Vault alle kurzlebigen TLS-Zertifikate für Enklave-Dienste aus — CI-Server, Artefakt-Registry, Container-Registry, den Secret-Manager selbst — ohne externe CA-Abhängigkeit.

CI-Agent-Authentifizierung verwendet die AppRole-Authentifizierungsmethode von Vault. Jeder Build-Agent wird mit einer role_id (nicht geheim, kann in der Agent-Konfiguration stehen) und einer secret_id (kurzlebig, beim Agent-Start durch den Infrastruktur-Provisioner injiziert) bereitgestellt. Der Agent tauscht diese gegen ein Vault-Token aus, das auf die für seine Builds erforderlichen Secrets beschränkt ist. Tokens sind kurzlebig (standardmäßig 1 Stunde, während des Builds erneuerbar) und laufen nach Abschluss des Builds automatisch ab. Dieses Muster bedeutet, dass ein kompromittierter Build-Agent keinen dauerhaften Zugriff auf Secrets hat — er hält nur ein ablaufendes Token, keine dauerhaft gültige Anmeldeinformation.

Secret-Rotation ohne Internetzugang folgt einer geplanten Zeremonie: vierteljährliche Rotation statischer Secrets (API-Schlüssel, Service-Account-Passwörter), jährliche Rotation von Signierschlüsseln. Vaults integrierte Rotationsrichtlinien übernehmen das Timing; die Ausgabe jeder Rotation wird im Audit-Log von Vault protokolliert, das an das Enklave-SIEM weitergeleitet wird. Für dynamische Secrets — Datenbankanmeldedaten, PKI-Zertifikate — generieren Vaults Dynamic-Secrets-Engines Pro-Build-Anmeldedaten mit kurzen TTLs, was die Rotation zu einem Nicht-Ereignis macht, da jede Anmeldeinformation bereits ephemer ist.

Die betriebliche Disziplin, die für den Betrieb dieses Stacks erforderlich ist, ist nicht trivial. Kuratorrollen, Transfergenehmigungsverfahren, Schlüsselverwahrer-Zeremonien und monatliche Scan-Kadenzen sind organisatorische Verpflichtungen, keine einmaligen Engineering-Entscheidungen. Programme, die diese Verfahren als Teil des System Security Plan (SSP) statt als informelles Stammwissen dokumentieren, sind deutlich widerstandsfähiger gegen Personalwechsel — was bei Sicherheitsanforderungen und dem Verteidigungsarbeitsmarkt ein realistisches operatives Risiko bei jedem langfristigen Programm ist.

Für die Lieferketten-Richtlinienschicht, die regelt, was überhaupt in die Pipeline eingeht, siehe unseren Artikel zur SBOM-Durchsetzung in Verteidigungspipelines. Der hier beschriebene air-gapped CI-Stack ist die Ausführungsschicht; SBOM-Durchsetzung und der übergeordnete DevSecOps-Rahmen für Verteidigungspipelines sind die Richtlinienschicht, die bestimmt, was die Pipeline baut, scannt und attestiert.