Container-Image-Sicherheit für Verteidigungsumgebungen: Härtung, Scanning und Supply-Chain-Integrität

Von Corvus Intelligence Engineering Team · Über das Team →

25. Juni 2026 11 Min. Lesezeit

Container-Images sind die atomare Einheit moderner Softwareauslieferung im Verteidigungsbereich. Jeder Workload, der auf Kubernetes-Verteidigungsclustern betrieben wird — Missionsanwendungen, Datenpipelines, KI-Inferenzdienste — kommt als unveränderliches Image an, das irgendwo, aus irgendetwas gebaut wurde. Die Sicherheit aller nachgelagerten Komponenten hängt von der Integrität dieser Build-Chain ab. In Unternehmensumgebungen ist ein kompromittiertes Container-Image ein schwerwiegender Vorfall. In einer klassifizierten Verteidigungsumgebung ist es ein potenzieller Vektor zur Geheimdiensterfassung, ein Persistenzmechanismus für einen staatlichen Akteur oder der Einstiegspunkt für destruktive Fähigkeiten, die auf waffenbezogene Infrastruktur abzielen.

Dieser Artikel behandelt den vollständigen Container-Image-Sicherheitslebenszyklus für Verteidigungsumgebungen: Auswahl und Validierung STIG-konformer Basis-Images, Härtung von Builds mit mehrstufigen Dockerfiles, Durchführung von Schwachstellen-Scans in luftgespaltenen CI/CD-Pipelines, Signierung von Images mit Cosign/Sigstore in getrennten Umgebungen, Generierung von SBOMs für ATO-Pakete sowie Durchsetzung von Registry-Integritätskontrollen in Harbor. Die Zielgruppe sind Plattformingenieure und Sicherheitsarchitekten, die an klassifizierten oder sicherheitsrelevanten Verteidigungssystemen arbeiten.

Warum Container-Image-Sicherheit im Verteidigungsbereich wichtiger ist als im Unternehmensumfeld

In einem kommerziellen Unternehmen stellt ein anfälliges oder kompromittiertes Container-Image ein Datenverletzungsrisiko, eine Betriebsstörung und eine regulatorische Haftung dar. In einer klassifizierten Verteidigungsumgebung reichen die Konsequenzen bis zur Offenlegung von Quellen und Methoden, zur Gefährdung von Missionen und zu kinetischen Auswirkungen auf Systeme, die ein Software-Schwachstelle einem Gegner zu kontrollieren oder zu deaktivieren erlauben könnte. Das Bedrohungsmodell ist qualitativ anders: Der Gegner ist keine finanziell motivierte kriminelle Gruppe, sondern ein Nationalstaat mit persistenten Zugriffsoperationen und der Geduld, Jahre zu warten, bis der richtige Moment kommt, um eine eingepflanzte Fähigkeit zu aktivieren.

Supply-Chain-Angriffe auf Container nutzen die schichtartige Natur von Container-Images aus. Ein typisches Missionsanwendungs-Image könnte FROM einem Basis-OS-Image gebaut werden, das Laufzeitpakete aus einem Paket-Repository installiert, die wiederum transitive Abhängigkeiten enthalten, die zur Build-Zeit aus vorgelagerten Sprach-Paket-Registrys gezogen werden. Der Gegner muss die internen Systeme des Verteidigungsauftragnehmers nicht kompromittieren — die Kompromittierung einer Abhängigkeit drei Ebenen tief in dieser Kette erzielt denselben Effekt. Die SolarWinds- und XZ-Utils-Vorfälle haben gezeigt, dass dieses Bedrohungsmodell nicht theoretisch ist; beide waren Supply-Chain-Einschleusungen, die ohne tiefgreifende Supply-Chain-Kontrollen technisch nicht erkennbar gewesen wären.

Verteidigungsumgebungen stellen drei Anforderungen, die Container-Image-Sicherheit wesentlich operativ komplexer machen als in Unternehmensumgebungen:

Luftspaltanforderungen. Klassifizierte Netzwerke können zur Laufzeit keine Images aus Internet-Registrys ziehen. Jede Image-Abhängigkeit muss vorab genehmigt, gescannt und in eine interne Registry gespiegelt werden, bevor sie genutzt werden kann — das bedeutet, die Supply-Chain-Grenze ist ein harter Perimeter, den Ingenieurteams vollständig besitzen und für dessen Überwachung sie verantwortlich sind.
Formale Autorisierungsanforderungen. Software, die auf klassifizierten Systemen läuft, muss einen Authorization to Operate (ATO)-Prozess durchlaufen, der eine dokumentierte Herkunft für jede Softwarekomponente erfordert. SBOM-Generierung und Image-Signierung wandeln sich von optionalen Hygienepraktiken zu obligatorischen ATO-Nachweislieferables.
Unveränderliche Infrastruktur-Durchsetzung. Verteidigungsplattformen schreiben zunehmend vor, dass keine Laufzeit-Modifikation von Container-Images erlaubt ist: Container werden zerstört und ersetzt, niemals im laufenden Betrieb gepatcht. Das bedeutet, dass die Sicherheitslage eines bereitgestellten Workloads dauerhaft zum Zeitpunkt des Image-Builds festgelegt wird, was Build-Zeit-Härtung und Scan-Gates nicht verhandelbar macht.

STIG-konforme Basis-Images

DISA (Defense Information Systems Agency) veröffentlicht Security Technical Implementation Guides (STIGs) für Betriebssysteme und Plattformen, die in Verteidigungsumgebungen eingesetzt werden. Für containerisierte Workloads sind die operativ bedeutsamsten der RHEL 8 STIG und RHEL 9 STIG, die für Red Hat Universal Base Image (UBI)-Derivate gelten — die am häufigsten verwendeten Basis-Images auf Verteidigungscontainerplattformen, einschließlich DoD Platform Ones Iron Bank-Repository für gehärtete Images.

Der RHEL STIG setzt Kontrollen in mehreren Kategorien durch, die sich wesentlich von einer Standard-OS-Installation unterscheiden:

Kernel-Parameter (sysctl). IP-Weiterleitung standardmäßig deaktiviert (net.ipv4.ip_forward=0), ICMP-Umleitungen abgelehnt, TCP SYN-Cookies aktiviert und randomisierter virtueller Adressraum (ASLR) erzwungen. Diese Kontrollen reduzieren die Exposition des OS als Netzwerk-Relay und erschweren die Ausnutzung von Speicherschwachstellen.
PAM-Konfiguration. Passwort-Komplexitätsregeln (Mindestlänge, Zeichenklassen), Kontosperrung nach fehlgeschlagenen Authentifizierungsversuchen und Sitzungsaufzeichnungsanforderungen. Für Container-Dienstkonten, die schlüssel- oder tokenbasierte Authentifizierung verwenden, benötigen einige dieser Kontrollen möglicherweise dokumentierte Ausnahmen.
auditd-Regeln. Der STIG spezifiziert einen umfassenden Satz von auditd-Regeln, der den Dateisystemzugriff auf sensible Pfade, die Verwendung von Befehlserweiterungsbefehlen (sudo, su), Änderungen an Benutzer- und Gruppendatenbanken, Netzwerkkonfigurationsänderungen und das Laden von Kernel-Modulen abdeckt. Im Container-Kontext läuft auditd typischerweise auf dem Host-Kernel und gilt für alle Container — die STIG-Regeln sollten auf Knotenebene angewendet werden, nicht pro Container.
FIPS 140 Kryptographie-Richtlinie. Der STIG erfordert, dass die systemweite Krypto-Richtlinie auf FIPS oder FIPS:OSCP gesetzt wird, wodurch TLS 1.0/1.1, MD5, SHA-1 für Signaturen, RC4 und DES/3DES deaktiviert werden. Anwendungskomponenten, die auf veraltete Algorithmen angewiesen sind, werden unter der FIPS-Krypto-Richtlinie fehlschlagen — dies ist ein häufiges Integrationsproblem, das in Härtungsprojekten spät entdeckt wird, wenn das STIG-Basis-Image gegen Anwendungstestsuiten validiert wird.

Iron Bank (das gehärtete Container-Registry von Platform One) veröffentlicht vorgehärtete Images, die gegen DISA STIGs validiert, auf Schwachstellen gescannt und signiert wurden. Für Programme, die bereits auf Platform One sind, ist das Bauen FROM einem Iron Bank-Basis-Image der praktischste Ansatz: Es bietet eine dokumentierte, vorautorisierte Baseline, die die Basis-Image-Anforderungen der meisten ATOs erfüllt. Für Programme, die nicht auf Platform One sind, ist das unabhängige Bauen und Validieren der STIG-Konformität mit OpenSCAP (oscap-docker oder oscap gegen ein exportiertes Container-Dateisystem) der gleichwertige Prozess.

# Validierung eines Container-Image-Dateisystems gegen den RHEL 9 STIG
# Export des Image-Dateisystems in ein temporäres Verzeichnis
docker export $(docker create registry.example.mil/myapp:v1.2.3) | tar -C /tmp/image-fs -xf -

# OpenSCAP gegen das exportierte Dateisystem ausführen
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --results /tmp/stig-results.xml \
  --report /tmp/stig-report.html \
  --chroot /tmp/image-fs \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Mehrstufige Build-Härtung

Mehrstufige Docker-Builds sind die effektivste Einzeltechnik zur Reduzierung der Angriffsfläche von Container-Images. Das Prinzip ist einfach: Verwenden Sie eine oder mehrere Zwischen-Build-Stufen, die alle zum Kompilieren und Paketieren der Anwendung erforderlichen Tools enthalten, und kopieren Sie nur die kompilierten Artefakte in eine finale Laufzeitstufe, die nichts enthält, was die Anwendung nicht zur Ausführung benötigt. Eine C++-Anwendung, die in einer Stufe mit gcc, make, cmake und Entwicklungsheadern gebaut wird, erzeugt ein finales Image, das nur die Binärdatei und ihre Laufzeit-Shared-Libraries enthält.

# Stufe 1: Build — vollständige Toolchain, nicht im finalen Image vorhanden
FROM registry.mil/ironbank/redhat/ubi/ubi9:latest AS builder
RUN dnf install -y gcc make cmake openssl-devel && dnf clean all
WORKDIR /build
COPY src/ .
RUN cmake -DCMAKE_BUILD_TYPE=Release . && make -j$(nproc)

# Stufe 2: Laufzeit — minimale Basis, keine Build-Tools
FROM registry.mil/ironbank/redhat/ubi/ubi9-micro:latest
COPY --from=builder /build/bin/myapp /usr/local/bin/myapp
# Nicht-Root-Benutzer — STIG- und NSA-Härtungsanforderung
RUN useradd -r -u 10001 -s /sbin/nologin appuser
USER 10001
EXPOSE 8443
ENTRYPOINT ["/usr/local/bin/myapp"]

Für statisch kompilierte Go- oder Rust-Anwendungen kann die finale Stufe scratch sein — ein völlig leeres Image, das nur die Binärdatei enthält. Dadurch wird die OS-Schicht vollständig eliminiert, sodass alle OS-Schwachstellen aus der Scan-Fundfläche entfernt werden. Die Cross-Kompilierungs- und statischen Verlinkungsfähigkeiten der Go-Standardbibliothek machen Scratch-Images für eine breite Klasse von Verteidigungsmikrodiensten ohne zusätzliche Build-Komplexität praktikabel.

Wenn die Anwendung zur Laufzeit eine Shell oder OS-Utilities benötigt (Debugging in der Entwicklung, Health-Check-Skripte, Initialisierungslogik), bieten gcr.io/distroless-Images einen Mittelweg: eine minimale Debian- oder Alpine-Basis, die nur die Sprachlaufzeit und die C-Bibliothek enthält, ohne Shell, ohne Paketmanager und ohne Systemdienstprogramme. Distroless-Images werden von Google gepflegt und mit Schwachstellen-Scan-Ergebnissen veröffentlicht; Verteidigungsprogramme, die distroless verwenden, sollten diese Images in ihre interne Registry spiegeln und eigene Schwachstellenbewertungsunterlagen führen.

Die Durchsetzung von Nicht-Root-Benutzern ist eine Härtungsanforderung sowohl im NSA Kubernetes Hardening Guide als auch im STIG. Die USER-Anweisung im Dockerfile legt den Standardbenutzer für alle nachfolgenden Befehle und für den Container-Einstiegspunkt fest. Verwenden Sie eine numerische UID (keinen benannten Benutzer), um eine Abhängigkeit von der /etc/passwd-Datei zu vermeiden, und wählen Sie eine UID über 10000, um Konflikte mit Systembenutzerradressen zu vermeiden. Admission-Controller, die das Pod Security restricted-Profil durchsetzen, lehnen Pods ab, bei denen runAsNonRoot nicht true ist oder bei denen ein Container runAsUser: 0 deklariert.

Schwachstellen-Scanning in klassifizierten CI/CD-Pipelines

Schwachstellen-Scanning ist das Qualitäts-Gate, das verhindert, dass Images mit bekannten ausnutzbaren CVEs klassifizierte Deployments erreichen. Zwei Open-Source-Scanner dominieren die Implementierungen auf Verteidigungscontainerplattformen: Trivy (Aqua Security) und Grype (Anchore). Beide unterstützen den Offline-Betrieb — eine nicht verhandelbare Anforderung für CI/CD in luftgespaltenen Verteidigungsumgebungen.

Der Offline-Modus von Trivy erfordert, dass die Schwachstellendatenbank vorab heruntergeladen und in die luftgespaltene Umgebung übertragen wird. Die Datenbank deckt OS-Pakete (RPM, DEB, APK), Sprach-Ökosystem-Pakete (pip, npm, Maven, Go-Module, Cargo) und binäre Anwendungssignaturen ab. Der Übertragungsworkflow über Wechseldatenträger oder eine Cross-Domain-Lösung muss als geplante Aufgabe in den regulären Betrieb des Teams integriert werden — eine veraltete Datenbank (älter als 14 Tage) ist ein häufiger Befund bei Sicherheitsbewertungen klassifizierter Umgebungen.

# Auf verbundenem (internetfähigem) System — Trivy-DB herunterladen
trivy image --download-db-only --cache-dir /transfer/trivy-cache

# /transfer/trivy-cache über genehmigte Medien auf das luftgespaltene System übertragen

# Auf luftgespaltenen CI/CD-Runner — Image mit lokaler DB scannen
trivy image \
  --skip-update \
  --cache-dir /opt/trivy-cache \
  --severity CRITICAL,HIGH \
  --exit-code 1 \
  --ignore-unfixed \
  --format json \
  --output /artifacts/scan-results.json \
  registry.classified.mil/myapp@sha256:abc123...

# Grype-Äquivalent — Auto-Update deaktivieren, auf lokale DB zeigen
GRYPE_DB_AUTO_UPDATE=false \
GRYPE_DB_CACHE_DIR=/opt/grype-db \
grype registry.classified.mil/myapp@sha256:abc123... \
  --fail-on critical \
  --output json > /artifacts/grype-results.json

Scan-Richtlinien-Gates definieren, welche Befunde einen Pipeline-Build blockieren versus Warnungen generieren. Eine vertretbare Gate-Richtlinie für klassifizierte Umgebungen:

Blockieren (Pipeline schlägt fehl, Image wird nicht gepusht): jedes CVE mit CRITICAL-Schweregrad, jedes CVE mit HIGH-Schweregrad in einer direkten Abhängigkeit mit einem CVSS-Ausnutzbarkeits-Teilwert über 7,0 oder einem EPSS-Score über 0,05.
Warnen und Ausnahme erforderlich: HIGH-Schweregrad-CVEs in transitiven Abhängigkeiten, HIGH-Schweregrad-CVEs ohne verfügbaren Vendor-Patch, MEDIUM-Schweregrad-CVEs.
Nur informativ: LOW- und NEGLIGIBLE-Befunde, CVEs, die Komponenten betreffen, die im Ausführungspfad der Anwendung nachweislich nicht erreichbar sind.

Jede Ausnahme muss ein unterzeichnetes, zeitlich begrenztes Dokument sein, das die CVE-Kennung, die Begründung (kein Patch verfügbar, Komponente nicht erreichbar, kompensierende Kontrolle), den genehmigenden Sicherheitsbeauftragten und ein Ablaufdatum für die erneute Bewertung enthält. Als code-überprüfte YAML-Dateien im CI/CD-Repository gespeicherte Ausnahmen bieten einen prüfbaren Nachweis, der die ATO-Nachweis-Anforderungen erfüllt.

Image-Signierung mit Cosign/Sigstore in getrennten Umgebungen

Image-Signierung liefert den kryptographischen Nachweis, dass ein bestimmtes Container-Image — identifiziert durch seinen SHA-256-Inhalts-Digest — von einer autorisierten Pipeline erstellt wurde und seit der Signierung nicht verändert worden ist. Cosign (Teil des Sigstore-Projekts der Linux Foundation) ist zum Standard-Image-Signiertool für Container-Umgebungen geworden und erzeugt OCI-kompatible Signaturen, die als Artefakte in derselben Registry wie das Image gespeichert werden.

Der schlüssellose Signier-Flow von Sigstore verwendet OIDC-Identitätstoken und öffentliche Infrastruktur (Fulcio CA und Rekor Transparency Log), um Images ohne Verwaltung langlebiger privater Schlüssel zu signieren. Dieses Modell eignet sich gut für öffentliche Open-Source-CI/CD, erfordert aber Internetzugang zur öffentlichen Sigstore-Infrastruktur — inkompatibel mit luftgespaltenen klassifizierten Umgebungen. Getrennte Umgebungen haben zwei praktische Optionen:

Schlüsselbasiertes Signieren (empfohlen für klassifiziert). Generieren Sie ein Cosign-Schlüsselpaar; speichern Sie den privaten Schlüssel in einem HSM oder einem genehmigten Secrets-Manager (HashiCorp Vault mit FIPS-validiertem Backend, AWS CloudHSM oder Azure Dedicated HSM). Der Signierschritt in der CI/CD-Pipeline ruft die Schlüsselreferenz ab und signiert den Image-Digest. Der öffentliche Schlüssel wird an Admission-Controller zur Verifikation verteilt. Es ist keine externe Infrastruktur erforderlich.
Private Sigstore-Instanz. Stellen Sie Fulcio und Rekor im klassifizierten Netzwerk bereit. Dies bietet die schlüssellose Benutzerführung und Transparency-Log-Vorteile, erfordert jedoch den Betrieb zusätzlicher Infrastruktur, einschließlich eines internen OIDC-Identitätsanbieters. Geeignet für große Programme mit dedizierten Plattformingenieurteams.

# Cosign-Schlüsselpaar generieren (einmalig ausführen, privaten Schlüssel in HSM/Vault speichern)
cosign generate-key-pair --kms awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def

# Image nach bestandenen Scan-Gates signieren — Image per Digest referenzieren, nicht per Tag
IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' myapp:v1.2.3)
cosign sign \
  --key awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def \
  --tlog-upload=false \
  registry.classified.mil/myapp@${IMAGE_DIGEST}

# Signatur verifizieren (verwendet von Admission-Controllern und bei manuellen Audits)
cosign verify \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  registry.classified.mil/myapp@sha256:abc123...

Die Durchsetzung der Image-Signaturverifikation durch den Admission-Controller schließt die Lücke zwischen Pipeline-Signierung und Laufzeit-Deployment. Eine Kyverno-ClusterPolicy mit einer verifyImages-Regel lehnt jeden Pod ab, der auf ein Image ohne gültige Signatur des genehmigten Cosign-öffentlichen Schlüssels verweist. Die Richtlinie sollte auch mutateDigest: true aktivieren, wodurch veränderliche Tag-Referenzen zum Zeitpunkt der Zulassung in unveränderliche Digest-Referenzen in der Pod-Spezifikation umgeschrieben werden — so wird sichergestellt, dass die Container-Laufzeit genau das verifizierte Image zieht, nicht einen nachfolgenden Push auf denselben Tag.

SBOM-Generierung für ATO-Pakete

Ein Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar jeder Softwarekomponente in einem bereitgestellten Artefakt — OS-Pakete, Sprachlaufzeitbibliotheken, Anwendungsabhängigkeiten und ihre Beziehungen. Für ATO-Pakete gibt das SBOM dem Genehmigungsbeauftragten Einblick in die Supply Chain des bereitgestellten Systems und wird zunehmend zu einem erforderlichen Lieferobjekt gemäß der DoD-Software-Beschaffungsrichtlinie und dem CISA-Leitfaden zur Umsetzung der Executive Order 14028.

Syft (Anchore) ist der Standard-Open-Source-SBOM-Generator für Container-Images. Es scannt das Image-Dateisystem Schicht für Schicht, identifiziert Pakete sowohl anhand von OS-Paketdatenbankeinträgen als auch anhand von Sprachökosystem-Lock-Dateien und gibt strukturierte SBOM-Dokumente aus. Das Ausführen von Syft gegen den finalen Image-Digest (nicht das Dockerfile oder das Quell-Repository) erfasst den tatsächlich bereitgestellten Komponenten-Satz, einschließlich Paketen, die transitiv installiert oder während des Build-Prozesses hinzugefügt wurden und nicht explizit in Anwendungsabhängigkeitsdateien aufgeführt sind.

# SBOM in SPDX- und CycloneDX-Formaten aus finalem Image generieren
syft registry.classified.mil/myapp@sha256:abc123... \
  -o spdx-json=/artifacts/sbom.spdx.json \
  -o cyclonedx-json=/artifacts/sbom.cdx.json

# SBOM an das Image in der Registry anhängen (als OCI-Artefakt gespeichert)
cosign attach sbom \
  --sbom /artifacts/sbom.spdx.json \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

# SBOM-Anhang verifizieren
cosign verify-attestation \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

Zur Frage SPDX versus CycloneDX: Beide Formate werden vom CISA-Leitfaden akzeptiert und können dieselben Komponenteninformationen darstellen. SPDX (ISO/IEC 5962:2021) ist der ältere Standard mit dem stärkeren Mandat in Regierungskontexten; CycloneDX hat eine stärkere Tool-Unterstützung für Schwachstellen-Anreicherung über VEX (Vulnerability Exploitability eXchange)-Dokumente. Für die SBOM-Durchsetzung in Verteidigungspipelines kostet die Generierung beider Formate aus einem einzigen Syft-Aufruf nichts und gewährleistet die Kompatibilität mit allen nachgelagerten ATO-Tools oder Anforderungen des genehmigenden Beamten.

Das dem Genehmigungsbeauftragten vorgelegte SBOM sollte von einem Schwachstellen-Offenlegungsdokument begleitet werden, das SBOM-Komponentenkennungen Scan-Befunden und ihrer Disposition (gepatcht, mit Begründung ausgenommen, nicht betroffen) zuordnet. Dieses kombinierte Paket — Image-Digest, SBOM, Scan-Ergebnisse, Ausnahmen und Cosign-Signatur — bildet den Supply-Chain-Nachweissatz, den Prüfer verwenden, um die Vertrauenswürdigkeit eines bereitgestellten Systems zu bewerten.

Container-Image-Registry-Sicherheit

Harbor ist das CNCF-zertifizierte Container-Registry, das am weitesten in Verteidigungs- und klassifizierten Umgebungen eingesetzt wird. Sein Funktionsumfang adressiert die spezifischen Betriebsanforderungen von Verteidigungs-Registrys: Tag-Unveränderlichkeit, Content-Trust-Integration mit Cosign, rollenbasierte Zugangskontrolle, Schwachstellen-Scan-Integration (Trivy) und Replikationsrichtlinien für Registry-Netzwerke mit mehreren Enklaven. Der Betrieb von Harbor in einer klassifizierten Umgebung erfordert besondere Aufmerksamkeit auf mehrere Konfigurationsbereiche, die Standardeinstellungen nicht durchsetzen.

Tag-Unveränderlichkeit verhindert, dass Push-Operationen einen vorhandenen Image-Tag überschreiben. Ohne diese Kontrolle könnte ein kompromittiertes CI/CD-Dienstkonto oder eine falsch konfigurierte Pipeline unbemerkt ein genehmigtes, signiertes Image durch ein bösartiges oder unsigniertes unter demselben Tag ersetzen. Harbors Tag-Unveränderlichkeitsregeln werden pro Projekt konfiguriert und können auf bestimmte Tag-Muster beschränkt werden — zum Beispiel das Sperren aller Tags, die v[0-9]* (Release-Versionen) entsprechen, während veränderliche dev-*-Tags in Entwicklungsprojekten erlaubt bleiben.

Content-Trust-Richtlinie in Harbor integriert sich mit Cosign, um die Signaturverifizierung beim Pull-Vorgang durchzusetzen. Wenn Content Trust für ein Projekt aktiviert ist, ruft Harbors Proxy-Schicht Cosign verify für jede Image-Pull-Anfrage auf und gibt bei fehlendem gültigem Signatur-Nachweis einen Autorisierungsfehler zurück. Dies bietet Registry-Ebenen-Durchsetzung unabhängig vom Kubernetes-Admission-Controller — Images können auch von Tools, die den Admission-Webhook umgehen, nicht gezogen werden.

# Harbor-Projektkonfiguration über CLI (harbor-cli oder curl gegen Harbor-API)
# Tag-Unveränderlichkeit für Produktionsprojekt aktivieren
curl -X POST https://registry.classified.mil/api/v2.0/projects/mission-apps/immutabletagrules \
  -H "Content-Type: application/json" \
  -u "admin:${HARBOR_ADMIN_PASSWORD}" \
  -d '{
    "action": "immutableTagRule",
    "scope_selectors": {"repository": [{"decoration": "repoMatches","pattern": "**"}]},
    "tag_selectors": [{"decoration": "matches","pattern": "v[0-9]*"}]
  }'

# Schwachstellen-Scanning beim Push für alle Projekte aktivieren
curl -X PUT https://registry.classified.mil/api/v2.0/projects/mission-apps \
  -H "Content-Type: application/json" \
  -u "admin:${HARBOR_ADMIN_PASSWORD}" \
  -d '{"metadata": {"auto_scan": "true", "severity": "critical"}}'

Pull-Through-Cache in Harbor übernimmt eine kritische Funktion in Multi-Enklave-Architekturen. Die verbundene (niedriger klassifizierte) Harbor-Instanz wird mit vorgelagerten Proxy-Cache-Projekten konfiguriert, die auf genehmigte externe Registrys (Red Hat Registry, Iron Bank) zeigen. Auf der klassifizierten Seite verfügt eine separate Harbor-Instanz über keine konfigurierte vorgelagerte Registry — sie stellt nur Images bereit, die auf der verbundenen Seite über den Cache gezogen, gescannt, signiert und physisch über den genehmigten Cross-Domain-Übertragungsmechanismus in die klassifizierte Registry übertragen wurden. Dies schafft einen kontrollierten Image-Promotion-Workflow, bei dem jedes Image die Sicherheitskontrollen passieren muss, bevor es die klassifizierte Umgebung betritt.

Garbage-Collection-Richtlinie in Harbor entfernt nicht markierte Manifeste und ungenutzte Schichten nach einem definierten Zeitplan. In klassifizierten Umgebungen mit begrenzter Speicherkapazität verhindert die Garbage Collection, dass der Registry-Speicher unbegrenzt wächst, wenn Images durch neue Versionen ersetzt werden. Die empfohlene Konfiguration führt die Garbage Collection wöchentlich während eines Wartungsfensters durch, behält eine konfigurierbare Anzahl historischer markierter Images pro Repository für Rollback-Fähigkeit und generiert ein Löschprotokoll für Prüfzwecke. Die Löschung von Images in einer klassifizierten Registry muss mit den ATO-Nachweis-Aufbewahrungsanforderungen koordiniert werden — SBOM- und Scan-Artefakte für bereitgestellte Image-Versionen müssen möglicherweise über den Image-Lebenszyklus hinaus aufbewahrt werden.

Wichtigste Erkenntnis: Container-Image-Sicherheit ist keine einzelne Kontrolle, sondern eine Defense-in-Depth-Kette: STIG-Basis-Images reduzieren die geerbte Schwachstellenfläche; mehrstufige Builds eliminieren ungenutzte Angriffsfläche aus dem Laufzeit-Image; Schwachstellen-Scanning zur Build-Zeit fängt bekannte CVEs vor dem Deployment ab; Image-Signierung bietet Integritätsverifikation vom Build bis zur Laufzeit; SBOM-Generierung schafft Supply-Chain-Transparenz für die Autorisierung; und Registry-Kontrollen (Unveränderlichkeit, Content Trust, Pull-Through-Cache) setzen die Kette auf der Distributionsschicht durch. Eine Lücke in einem der Glieder dieser Kette — ein unsigniertes Image, eine veraltete Schwachstellendatenbank, ein veränderlicher Tag — ist die Angriffsfläche, die ein Gegner mit Supply-Chain-Zugang ausnutzen wird.

Ihr Projekt besprechen

Wir konzipieren und implementieren Container-Sicherheitspipelines für klassifizierte Verteidigungsumgebungen — von der STIG-Basis-Image-Validierung und luftgespaltenen Schwachstellen-Scans bis hin zur Cosign-Signierungsinfrastruktur und Harbor-Registry-Konfiguration für Multi-Enklave-Architekturen.

Secure Cloud Services → Briefing buchen

Diese Analyse wurde von Corvus Intelligence-Ingenieuren erstellt, die missionskritische Software für Verteidigungs- und Regierungsorganisationen entwickeln. Mehr über unser Team →

Häufig gestellte Fragen

Warum erfordert Container-Image-Sicherheit im Verteidigungsbereich im Vergleich zu kommerziellen Unternehmen einen anderen Ansatz?

Verteidigungsumgebungen fügen drei Anforderungen hinzu, die in den meisten Unternehmensumgebungen fehlen. Erstens können klassifizierte Workloads keine Images aus Internet-Registrys ziehen, sodass jede Abhängigkeit in eine genehmigte interne Registry gespiegelt werden muss — das bedeutet, die Supply-Chain-Grenze ist ein harter Perimeter, den Sie vollständig besitzen. Zweitens muss Verteidigungssoftware einen formalen Autorisierungsprozess (ATO) erfüllen, der eine dokumentierte Herkunft für jede Komponente erfordert, was SBOM-Generierung und Image-Signierung von „nice-to-have" zu obligatorisch macht. Drittens umfasst das Gegner-Bedrohungsmodell staatliche Akteure mit der Fähigkeit und Motivation, bösartige Komponenten in Open-Source-Bibliotheken oder Basis-OS-Pakete einzuschleusen — genau die Angriffsfläche, die eine Container-Image-Supply-Chain exponiert.

Welcher STIG gilt für Container-Basis-Images und was setzt er durch?

DISA veröffentlicht den Container Platform Security Requirements Guide (SRG) und spezifische STIGs für Red Hat Universal Base Image (UBI)-Derivate und RHEL 8/9. Der RHEL STIG ist die operativ relevanteste Baseline: Er schreibt bestimmte sysctl-Kernel-Parameterwerte vor (Einschränkung von IP-Weiterleitung, ICMP-Umleitungen und SYN-Cookies), PAM-Konfiguration zur Durchsetzung von Passwortkomplexität und Kontosperrung, auditd-Regeln für Dateizugriff, Rechteausweitung und Netzwerkkonfigurationsänderungen sowie die FIPS 140-2/140-3-Kryptographie-Richtlinie. Wenn Sie FROM einem DISA-bereitgestellten oder unabhängig STIG-gehärteten Basis-Image bauen, erben Sie die OS-Ebenen-Kontrollen und müssen nur Ihre Anwendungsschicht darüber hinaus härten.

Was ist ein distroless Container-Image und wann sollten Verteidigungsworkloads es verwenden?

Ein distroless-Image enthält nur die Anwendungslaufzeit und ihre direkten Bibliotheksabhängigkeiten — keinen Paketmanager, keine Shell, keine Systemdienstprogramme. Der Sicherheitsvorteil ist erheblich: Ein Container ohne Shell kann nicht durch Shell-Injection ausgenutzt werden; ein Container ohne Paketmanager kann nicht verwendet werden, um Angreifer-Tools nach einer Kompromittierung herunterzuladen und zu installieren. Für statisch kompilierte Go- oder Rust-Binärdateien ist scratch (ein völlig leeres Basis-Image) noch minimaler. Verteidigungsworkloads, die distroless tolerieren können — die meisten zustandslosen Mikrodienste können es — sollten es gegenüber allgemeinen OS-Basis-Images bevorzugen, unabhängig davon, wie gehärtet dieses OS-Image ist.

Wie führt man Trivy oder Grype in einem luftgespaltenen klassifizierten Netzwerk aus?

Sowohl Trivy als auch Grype unterstützen den Offline-Datenbankbetrieb. Für Trivy laden Sie das Schwachstellendatenbank-Bundle auf einem verbundenen System herunter, übertragen es über die Datendiode oder Wechseldatenträger in das klassifizierte Netzwerk und verweisen Trivy mit den Flags --skip-update und --cache-dir auf die lokale Kopie. Grype verwendet ein ähnliches Muster: das grype-db-Bundle herunterladen, es im konfigurierten Cache-Verzeichnis platzieren und GRYPE_DB_AUTO_UPDATE=false setzen. Die wichtigste Betriebsdisziplin ist ein regelmäßiger (wöchentlicher oder pro Sprint) Datenbankaktualisierungszyklus — veraltete Schwachstellendatenbanken in klassifizierten Umgebungen sind ein häufiger Compliance-Befund, da der Aktualisierungsprozess einen physischen Medientransfer erfordert und leicht aufgeschoben wird.

Was ist Cosign und wie ermöglicht es Image-Signierung ohne öffentliche Fulcio/Rekor-Instanz?

Cosign (Teil des Sigstore-Projekts) signiert Container-Images, indem es eine kryptographische Signatur als OCI-Artefakt anhängt, das in derselben Registry neben dem Image gespeichert wird. Im schlüssellosen Sigstore-Flow verwendet Cosign OIDC-Identitätstoken und die öffentliche Fulcio CA und den Rekor Transparency Log — was Internetzugang erfordert. In einer verteidigungstypischen luftgespaltenen Umgebung erfordert der einfachere schlüsselbasierte Signing-Flow — bei dem Cosign mit einem privaten Schlüssel aus einem HSM oder Secrets-Manager signiert — überhaupt keine externe Infrastruktur und ist der praktischste Ansatz für klassifizierte Umgebungen. Das Flag --tlog-upload=false deaktiviert den Transparency-Log-Upload, und --insecure-ignore-tlog=true überspringt die Rekor-Verifikation auf der Verifikationsseite.

Welches SBOM-Format sollten Verteidigungsprogramme verwenden — SPDX oder CycloneDX?

Beide Formate werden von CISA akzeptiert und können dieselben Supply-Chain-Informationen darstellen. SPDX (ISO/IEC 5962:2021) ist der ältere Standard mit stärkerem Regierungsmandat, einschließlich der Executive Order 14028 SBOM-Leitlinien. CycloneDX bietet stärkere Unterstützung für Schwachstellen-Anreicherung (VEX-Dokumente), Sicherheitsbewertungen und maschinenlesbare Komponentenidentität und wird zunehmend von SBOM-Analysetools bevorzugt. Für ATO-Pakete kostet die Generierung beider Formate aus einem einzigen Syft-Aufruf nichts und erfüllt jede Anforderung des nachgelagerten Genehmigungsbeamten — verwenden Sie zwei --output-Flags in einem Befehl.

Wie schützt Tag-Unveränderlichkeit in Harbor vor Image-Substitutionsangriffen?

Standardmäßig erlauben Container-Registrys das Überschreiben eines vorhandenen Tags mit einem anderen Image-Digest — so kann :latest oder :v2.3.1 morgen auf ein völlig anderes Image zeigen als heute. In einer Verteidigungs-Supply-Chain könnte ein kompromittiertes Registry-Konto oder eine falsch konfigurierte CI-Pipeline unbemerkt ein genehmigtes Image durch ein bösartiges unter demselben Tag ersetzen. Harbors Tag-Unveränderlichkeitsfunktion, die pro Projekt konfiguriert wird, verhindert jeden Push, der einen vorhandenen Tag überschreiben würde. In Kombination mit Image-Signierung (die den Digest in die Signatur einbettet) und Admission-Controller-Digest-Pinning schließt die Tag-Unveränderlichkeit den Image-Substitutionsangriffsvektor vollständig.

Welche Scan-Richtlinien-Gate-Schwellenwerte sind für Verteidigungs-CI/CD-Pipelines angemessen?

Eine vertretbare Richtlinie: Blockieren bei jeder CRITICAL-Schwachstelle mit bekanntem Exploit (EPSS-Score über 0,05 oder CVSS-Ausnutzbarkeits-Teilwert über 7,0); Blockieren bei jeder HIGH-Schwachstelle in einer direkten Abhängigkeit mit einem bekannten Exploit; Warnen und dokumentierte Ausnahme erforderlich für HIGH-Schwachstellen ohne öffentlichen Exploit und MEDIUM-Schwachstellen. Die Regel „Blockieren bei allen HIGH" ist in Compliance-Frameworks verbreitet, erzeugt aber in der Praxis übermäßig viel Lärm — insbesondere bei OS-Paket-Schwachstellen in STIG-Basis-Images, bei denen der Vendor-Patch noch nicht verfügbar ist. Schweregrad-plus-Ausnutzbarkeits-Gating reduziert falsch-positive Blockierungen, während die Schwachstellen, die am wahrscheinlichsten ausgenutzt werden, weiterhin abgefangen werden.

Welche Rolle spielt ein SBOM im ATO (Authorization to Operate)-Prozess?

Ein SBOM ist ein maschinenlesbares Stücklisten-Dokument, das jede Softwarekomponente in einem bereitgestellten System auflistet, einschließlich Versionskennungen und Komponentenbeziehungen. Im ATO-Prozess gibt das SBOM dem Genehmigungsbeauftragten (AO) Einblick in die vollständige Software-Supply-Chain des zu autorisierenden Systems — der AO kann so bewerten, ob eine Komponente bekannte Schwachstellen, kommerzielle Lizenzbeschränkungen oder eine nicht vertrauenswürdige Herkunft aufweist. Das dem AO vorgelegte SBOM sollte zum Image-Build-Zeitpunkt generiert werden (nicht aus dem Quellcode), alle Schichten jedes Container-Images abdecken und unveränderlich neben dem signierten Image in der Artefakt-Registry gespeichert werden. Ein begleitendes VEX-Dokument, das CVEs ihrem Ausnutzbarkeitsstatus zuordnet, stärkt die Einreichung.

Wie unterstützt Pull-Through-Cache in Harbor klassifizierte Netzwerkoperationen?

Harbors Proxy-Cache-Projekt ermöglicht es, eine vorgelagerte Registry (Red Hat Registry, Iron Bank) zu konfigurieren und Images beim ersten Pull transparent zu spiegeln. In einem klassifizierten Netzwerk ohne Internetzugang wird der Pull-Through-Cache typischerweise vorab befüllt: Images werden auf der verbundenen Enklave-Seite über den Cache gezogen, und die Harbor-Registry-Daten werden über Wechseldatenträger oder eine Daten-Dioden-Übertragung in die klassifizierte Harbor-Instanz repliziert. Die klassifizierte Harbor-Instanz hat keine konfigurierte vorgelagerte Registry und stellt nur vorab genehmigte, vorab gescannte, vorab signierte Images bereit. Dies erzwingt Sicherheitskontrollen, bevor Images in die klassifizierte Umgebung gelangen, anstatt sich allein auf Laufzeit-Durchsetzung zu verlassen.