Java-Docker-Images absichern und CVE-Risiken reduzieren

Der Feldführer der Black Forest Commandos zu CVEs, SBOMs, gehärteten Images, Attestierungen und Software-Supply-Chain-Sicherheit.

Deine Java-Anwendung kann verwundbare Abhängigkeiten und Pakete aus deinem Basis-Image erben, bevor du überhaupt eine einzige Zeile Anwendungscode geschrieben hast. Außerdem hat das Scannen deines Docker-Images nach Schwachstellen blinde Flecken, denn das im Nachhinein erzeugte SBOM liefert dir kein vollständiges Bild. Ein erfolgreicher Docker-Build allein sagt dir nicht, was ausgeliefert wird, wie es gebaut wurde oder ob du ihm vertrauen kannst.

Asgard steht unter Beschuss. Schattenkreaturen namens CVEs sind in das Reich eingedrungen, und Thors Hammer erweist sich als überraschend wirkungslos. Odin hat nur eine Option: die Black Forest Commandos zu rufen.

Hinter der Mythologie steckt eine praktische Frage: Wie bauen wir Container-Images, die wir inspizieren, denen wir vertrauen und die wir mit Zuversicht deployen können?

Lass uns gemeinsam ein Spring-Boot-Beispielprojekt absichern, mit Hilfe der Commandos (CLI-Befehle).

Kurzfassung (TL;DR)

Die meisten CVEs stammen aus Basis-Images. Allein der Austausch des Basis-Images gegen ein Docker-Hardened-Basis-Image reduziert das Runtime-Inventar – also die Pakete, die ein Angreifer tatsächlich erreichen könnte – um 75,5 %, ohne dass sich zwischen den beiden Images eine einzige Anwendungsabhängigkeit ändert.

Weniger Pakete bedeuten weniger Angriffsfläche. Docker Hardened Images werden zudem mit nahezu null CVEs, einem Non-Root-Benutzer und ohne Shell oder Paketmanager für die Produktions-Images ausgeliefert. Selbst wenn ein Angreifer also in deinen Container gelangt, hat er nicht viel zum Spielen.

Alles in allem: Der Austausch deiner Basis-Images beseitigt die CVEs deiner Anwendung nicht. Deshalb solltest du den vollständigen Artikel lesen!

Mit dem lauffähigen Beispiel starten

Bevor wir beginnen, prüfen wir dein Werkzeugset:

Docker baut, kompiliert und testet die Anwendung, sodass du diese Schritt-für-Schritt-Anleitung durchgehen kannst, ohne Java oder Maven lokal zu installieren. Verwende für die folgenden Befehle ein Bash-ähnliches Terminal.

Den getesteten Ausgangspunkt auschecken

Das Referenz-Repository hat zwei Branches:

• main, das ist der Zustand, den du am Ende des Artikels erreichen wirst.
• start, das ist der Beginn der Reise.

Wir starten start von dort:

git clone --branch start --single-branch \
  https://github.com/ContainerSecurity-dev/dockerize-java-securely.git
cd dockerize-java-securely

Du kannst deine Experimente in diesem lokalen Branch bearbeiten und committen. Basis-Image-Tags und Schwachstellendatenbanken können sich weiterhin ändern, daher können deine Scan-Ergebnisse abweichen.

Die Dateien, die du verwenden wirst, sind:

• src/ und pom.xml: die funktionierende Anwendung und ihr HTTP-Integrationstest.
• Dockerfile.baseline: das Ausgangs-Image, das die offiziellen Maven- und Eclipse-Temurin-Images verwendet.
• Dockerfile: die gehärtete Version, die du damit vergleichen wirst.
• scripts/: Helfer, um die HTTP-Antwort zu prüfen und Schwachstellenberichte zu speichern.

Also, lass es losgehen.

1. Eine überprüfbare Baseline bauen

Die Commandos erkunden das Gelände, bevor sie kämpfen. Für uns ist dieses Gelände ein Basis-Image, das gebaut und gepusht wird, damit es inspiziert werden kann.

Wir verwenden eine temporäre, nur über Loopback erreichbare Registry, damit das Publikum Pushes und Attestierungen üben kann, ohne Anwendungs-Images in eine öffentliche Registry zu veröffentlichen. Diese nicht authentifizierte HTTP-Registry ist nur für lokale Demos gedacht. Verwende für eine entfernte Registry einen authentifizierten Namespace, den du über HTTPS besitzt.

docker run -d --name dockerize-java-demo-registry \
  -p 127.0.0.1:15000:5000 registry:3
export PLATFORM=linux/amd64   # verwende linux/arm64 auf Apple Silicon
export IMAGE_REPO=127.0.0.1:15000/dockerize-java-securely
mkdir -p results

docker buildx build --platform "$PLATFORM" \
  -f Dockerfile.baseline \
  --sbom=true --provenance=mode=max \
  --metadata-file results/baseline-build-metadata.json \
  --push -t "$IMAGE_REPO:baseline" .

scripts/smoke-test.sh "$IMAGE_REPO:baseline"
export IMAGE="$IMAGE_REPO:baseline"

Entpacken wir die Befehle:

• Der Befehl docker buildx build ist ein erweiterter Befehl zum Bauen von Docker-Images mit BuildKit.
• Das Flag --sbom=true weist den Builder an, SBOM-Attestierungen zu erzeugen: SBOM-Datensätze, die an das Image „angehängt" werden.
• Das Flag --provenance=mode=max erzeugt Provenance-Attestierungen. Diese Attestierung zeichnet mehr Metadaten über den Build-Prozess auf.
• Wie du siehst, wird -f Dockerfile.baseline verwendet, um das Dockerfile anzugeben. Das einzige nicht optionale Argument, das . am Ende, ist also nicht der Pfad zum Dockerfile, sondern der Build-Kontext – all die Dateien, auf die Docker zugreifen kann und die möglicherweise in deinem Docker-Image landen.

Wenn du dir außerdem die Datei smoke-test.sh ansiehst, wird das Image mit den folgenden Flags ausgeführt:

docker run --detach --rm --read-only --tmpfs /tmp --cap-drop ALL \
  --security-opt no-new-privileges:true -p 127.0.0.1::8080 "$image"

Der Smoke-Test sollte Hello, Docker Security! als Benutzer 10001:10001 zurückgeben. Die Flags dienen dazu, den Container in einer sichereren Umgebung auszuführen.

2. Kenne deinen Feind: CVEs und SBOMs

Log4Shell (CVE-2021-44228) hat gezeigt, warum es wichtig ist zu wissen, welche Abhängigkeiten wir ausliefern. Ein SBOM, eine Software Bill of Materials, ist eine Liste der Softwarekomponenten in deiner Anwendung. Diese Liste zur Hand zu haben, hilft dir, deine Pakete zu identifizieren, falls eines davon eine bekannte Schwachstelle aufweist. Sie bloß zu besitzen, macht deine Anwendung jedoch nicht von selbst sicherer.

Rothütles erste Mission in Asgard ist es, herauszufinden, wer dort lebt. Mit Docker Scout kannst du die Liste mit dem Befehl docker scout sbom prüfen:

docker scout sbom "$IMAGE" --format list
docker scout sbom "$IMAGE" --format spdx --output results/sbom.spdx.json

Wie viele Pakete sind hier aufgelistet?

Die Ausgabe dieser Befehle wird die verwendete SBOM-Attestierung erwähnen. Wenn die Attestierung beim Build fehlt, versucht Docker Scout, sie durch Scannen deiner Dateien zu erstellen.

In dem docker buildx build-Befehl, den wir ausgeführt haben, haben wir eine SBOM-Attestierung erstellt, und der Docker-Scout-Befehl hat sie aufgegriffen. Das SBOM enthält jedoch nur Pakete aus der letzten Stufe, was kein vollständiges Bild ergibt. Ein kompromittiertes Build-Zeit-Paket kann dennoch eine Hintertür in deine Anwendung schreiben.

Weiterlesen:

Generating SBOM with Docker Scout

Am I vulnerable? That's the first question a CTO might ask in the case of a new CVE. To answer it, you need to know what's inside your container. SBOM is the word of the day. Especially, since EU Resilience Act makes it mandatory.

containersecurity.dev

3. CVEs jagen: Docker Scout und Trivy

Jack, unser kybernetischer Scout, der sich zu Halloween als Jack-o'-Lantern verkleidet, kann CVEs aufspüren, die sich in Container-Images verstecken.

docker scout cves "$IMAGE"
docker scout cves --only-severity critical,high "$IMAGE"

Docker Scout ist ein Enterprise-Angebot, kostenlos für die private Nutzung. Trivy ist eine Open-Source-Alternative und ebenso ein Industriestandard.

trivy image --scanners vuln "$IMAGE"
trivy image --scanners vuln --severity CRITICAL,HIGH --exit-code 1 "$IMAGE"

Der letzte Befehl sollte den Exit-Code 1 zurückgeben, weil es hohe und/oder kritische CVEs im Image gibt. Das ist ein Security-Gate, das du in deinen Workflow einbauen solltest. Speichern wir maschinenlesbare Berichte mit dem Helfer des Repositories:

# Speichert JSON, fasst Ergebnisse zusammen und beendet mit 1, wenn das Gate fehlschlägt.
scripts/scan.sh "$IMAGE" results/baseline-trivy.json

Das Skript scan.sh führt im Hintergrund Trivy aus, speichert aber auch die Berichte und parst sie. Ein ähnliches Skript würde in deiner Pipeline stehen, z. B. um die Anzahl der CVEs über einen Pull-Request-Kommentar zu melden.

Beachte, dass Schweregrad nicht dasselbe ist wie Ausnutzbarkeit, und dass bösartige Software nicht unbedingt eine CVE hat. Auch Scanner-Datenbanken und Paket-Zuordnung unterscheiden sich: Dieselbe Baseline ergab unterschiedliche Summen bei Scout und Trivy. Vergleiche Images innerhalb desselben Scanners und untersuche die betroffenen Pakete.

4. Die Build-Stufe in dein SBOM aufnehmen

Rothütle vermutet, dass das Inventar unvollständig ist: Einige Komponenten waren vorhanden, während die Anwendung gebaut wurde, nicht nur während sie läuft.

Die Baseline verwendet einen Multi-Stage-Build, aber --sbom=true allein inventarisiert nur das finale Image. Pakete, die nur beim Kompilieren der Anwendung verwendet werden, können aus diesem Inventar verschwinden, wenn die Build-Stufe verworfen wird.

Inspiziere zuerst das angehängte SBOM und die Provenance der Baseline:

docker buildx imagetools inspect "$IMAGE_REPO:baseline" --format '{{json .SBOM}}' > results/baseline-sbom.json
docker buildx imagetools inspect "$IMAGE_REPO:baseline" --format '{{json .Provenance}}' > results/baseline-provenance.json

Bearbeite nun Dockerfile.baseline. Füge dieses Argument unmittelbar nach der FROM-Zeile der Build-Stufe ein:

FROM maven:3.9-eclipse-temurin-21 AS build
ARG BUILDKIT_SBOM_SCAN_STAGE=true

Baue unter einem separaten Tag neu, damit du die beiden Inventare vergleichen kannst:

docker buildx build --platform "$PLATFORM" \
  -f Dockerfile.baseline \
  --sbom=true --provenance=mode=max \
  --metadata-file results/baseline-build-sbom-metadata.json \
  --push -t "$IMAGE_REPO:baseline-build-sbom" .

docker buildx imagetools inspect "$IMAGE_REPO:baseline-build-sbom" --format '{{json .SBOM}}' > results/baseline-with-build-sbom.json

Die neue Ausgabe enthält ein zusätzliches sbom-build-Dokument neben dem Runtime-SPDX-Inventar. Das Argument fügt Metadaten über die Pakete aus früheren Stufen hinzu, und es bedeutet nicht, dass diese Pakete im finalen Image landen.

• SBOM: Welche Software wurde im Image inventarisiert, und wurden Build-Stufen abgedeckt?
• Provenance: Wie wurde das Image gebaut, und aus welchen Materialien?

Verwende BuildKit-Secret-Mounts für Anmeldedaten. Provenance auf maximaler Stufe kann Build-Argumente offenlegen, also lege niemals Secrets hinein. Darüber hinaus ist eine angehängte Attestierung nicht automatisch eine vertrauenswürdige kryptografische Signatur.

Nun, wie viele Pakete sind in den SBOM-Attestierungen aufgelistet?

Weiterlesen:

The Poisoned Macchiato: Signing Java SBOMs with Cosign

A café, a suspicious espresso, and a lesson in supply chain trust. Learn how to generate BuildKit SBOM attestations for Java images and re-attest them with Cosign as OCI referrers.

containersecurity.dev

5. Die Runtime härten und den Unterschied messen

Zeit für die Rüstung. Docker Hardened Images sind eine Reihe von Open-Source- und nahezu CVE-freien Basis-Images, die dazu dienen, dein Docker-Image für zukünftige Angriffe zu „panzern". Den Katalog kannst du auf dhi.io einsehen.

Tauschen wir das Basis-Image gegen die gehärteten aus:

# syntax=docker/dockerfile:1
FROM dhi.io/maven:3-jdk21-dev AS build
ARG BUILDKIT_SBOM_SCAN_STAGE=true
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn -B verify

FROM dhi.io/eclipse-temurin:21-alpine3.23
WORKDIR /app
COPY --from=build /app/target/app.jar /app/app.jar
USER 10001:10001
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

Wenn du das Beispiel-Repository prüfst, findest du dort eine Datei .dockerignore mit folgendem Inhalt:

**
!pom.xml
!src/
!src/**
!Dockerfile
!Dockerfile.baseline

Das bedeutet, dass alles vom Befehl docker buildx build ignoriert wird (aus dem Build-Kontext entfernt), außer den aufgelisteten Dateien. Das nennt man eine Allowlist. Statt also eine Reihe von Dateien zu ignorieren, ignorieren wir alles und erlauben eine Reihe von Dateien.

Außerdem setzt das POM finalName auf app und vermeidet so einen mehrdeutigen JAR-Wildcard.

Das folgt Dockers Java-DHI-Migrationsmuster, mit expliziten Tests und einem Non-Root-Runtime-Benutzer.

docker buildx build --platform "$PLATFORM" \
  --sbom=true --provenance=mode=max \
  --metadata-file results/hardened-build-metadata.json \
  --push -t "$IMAGE_REPO:hardened" .

scripts/smoke-test.sh "$IMAGE_REPO:hardened"
# Gibt für das aufgezeichnete Beispiel ebenfalls 1 zurück:
scripts/scan.sh "$IMAGE_REPO:hardened" results/hardened-trivy.json
python3 scripts/summarize-scans.py results/baseline-trivy.json results/hardened-trivy.json

Es ist Zeit für den Bericht! Du kannst alle selbst ausführen oder einfach meinen durchlesen!

Beobachtete Ergebnisse: 13. Oktober 2026

Beide finalen Anwendungs-Images verwenden Spring Boot 4.0.8 und Java 21. Die Ergebnisse basieren auf Läufen unter Linux Ubuntu (linux/amd64) und Mac Silicon (linux/arm64) mit identischen Resultaten. Dies sind Trivy 0.75.0-Schwachstellenaufzeichnungen, gruppiert nach Scan-Ziel; die Summen sind keine Zählungen eindeutiger CVE-IDs über alle Pakete hinweg.

Docker Scout 1.20.3 meldete 5 kritisch / 13 hoch / 2 mittel / 3 unspezifiziert für die Baseline und 3 kritisch / 5 hoch / 2 mittel für das gehärtete Image. Das sind separate Scanner-Beobachtungen, nicht austauschbar mit den Trivy-Zählungen.

Das ursprüngliche Spring-Boot-4.0.5-Beispiel hatte 9 kritisch / 18 hoch / 20 mittel / 6 niedrig Java-Funde in Trivy. Das Update auf 4.0.8 reduzierte diese Funde, beseitigte sie aber nicht. Die verbleibenden Java-Funde betrafen Tomcat- und Jackson-Abhängigkeiten. Prüfe die Fixed-Version-Hinweise des Berichts, aktualisiere die Anwendungsabhängigkeiten, führe die Tests erneut aus und scanne erneut, bevor du promotest.

Den Blast Radius im Dependency-Baum untersuchen

„Aktualisiere Tomcat und Jackson" ist leichter gesagt als getan, denn die meisten dieser Bibliotheken kommen transitiv über das Spring-Boot-BOM. Untersuche, was dein Projekt tatsächlich auflöst, bevor du eine Version anfasst:

# Vollständig aufgelöster Baum (führe ihn im Builder-Image aus, wenn du kein lokales JDK hast):
./mvnw -B dependency:tree

# Eingrenzen auf die Pakete, die der Scanner markiert hat:
./mvnw -B dependency:tree -Dincludes=org.apache.tomcat.embed:tomcat-embed-core
./mvnw -B dependency:tree -Dincludes=tools.jackson.core:jackson-core

Ich kann nicht glauben, dass es 2026 ist und Maven-Flags noch immer so aussehen. Dincludes. Wie auch immer!

Der Baum zeigt die Tiefe jedes Artefakts und den Pfad, über den es hereinkam. Eine Abhängigkeit, die du direkt in pom.xml deklarierst, kann dort oder in einem <dependencyManagement>-Eintrag überschrieben werden; eine transitive benötigt normalerweise ein Versions-Override oder ein aktualisiertes Parent/BOM. Bestätige nach der Änderung, dass der Fix das Runtime-JAR erreicht, führe mvn verify erneut aus und scanne den neuen Digest. Wenn ein betroffenes Artefakt transitiv ist und noch keinen Fix hat, halte das in einer VEX-Aussage fest, statt es stillschweigend zu unterdrücken.

VEX prüfen, bevor du Scanner vergleichst

VEX (Vulnerability Exploitability eXchange) hält fest, ob eine bestimmte Schwachstelle ein Produkt betrifft. Man kann VEX-Datensätze für CVEs erstellen, die im eigenen Fall harmlos sind. Man kann sie zusammen mit seinem Docker-Image als „VEX-Attestierungen" ausliefern. Docker Hardened Images bringen ihre eigenen VEX-Attestierungen mit.

Docker Scout wendet DHI-VEX-Aussagen automatisch an und schließt sie aus den aufgelisteten CVEs aus; Trivy benötigt aktiviertes VEX:

docker scout cves dhi.io/eclipse-temurin:8-alpine3.23

# Konfiguriere und lade zuerst das DHI-VEX-Repository herunter (siehe verlinkte Anleitung).
trivy image --scanners vuln --vex repo dhi.io/eclipse-temurin:8-alpine3.23

Aktiviere für Trivy das Repository docker-hardened-images/advisories in seiner VEX-Konfiguration und lade es herunter, bevor du --vex repo verwendest. Prüfe die zutreffenden VEX-Aussagen; Unterdrückung ist eine Einschätzung der Betroffenheit, kein Dependency-Fix.

Das kann manchmal Unterschiede bei den gemeldeten CVEs erklären, ohne dass sich das Image ändert. Siehe Dockers VEX-fähige Scan-Anleitung.

Die oben aufgezeichneten Trivy-Scans hatten VEX nicht aktiviert. Der beobachtete Unterschied zwischen Scout und Trivy lag jedoch in der Nicht-DHI-Baseline, stammte also nicht aus VEX-Attestierungen.

Beide Images bestanden den HTTP-Smoke-Test. Im aufgezeichneten Vergleich enthielt das Runtime-SBOM bei aktiviertem Build-Stage-Scanning 192 Pakete für die Baseline und 47 für das gehärtete Image; die separaten Build-Stage-Inventare enthielten 396 bzw. 377. Allein durch den Austausch gegen ein DHI-Basis-Image reduziert sich die Anzahl der Abhängigkeiten im Produktions-Image also um 75 %. Daher das Balkendiagramm-Bild von Artemisia, während sie die Angriffsfläche zermalmt!

Der Ergebnisbericht zeichnet Image-Digests, Versionen und Belege auf.

Docker Hardened Images are Free

Docker Hardened Images are now open-source under Apache 2.0 license and free to use in your projects.

containersecurity.dev

6. Signieren, bevor du vertraust: Cosign

Evie ist die Commando, die für kryptografische Signaturen zuständig ist. Sie verwendet stets den unveränderlichen Digest, den der Build zurückgibt, statt eines veränderlichen Tags:

export DIGEST_IMAGE="$IMAGE_REPO@$(python3 -c 'import json; print(json.load(open("results/hardened-build-metadata.json"))["containerimage.digest"])')"
mkdir -p .demo-keys
cosign generate-key-pair --output-key-prefix .demo-keys/cosign
cosign sign --key .demo-keys/cosign.key "$DIGEST_IMAGE"
cosign verify --key .demo-keys/cosign.pub "$DIGEST_IMAGE"

# Scanne dasselbe unveränderliche Artefakt; dieses Beispiel scheitert weiterhin am Gate.
trivy image --scanners vuln --severity CRITICAL,HIGH --exit-code 1 "$DIGEST_IMAGE"

Cosign 3.1.3 verifiziert erfolgreich die Signatur, die Claims und den Einschluss im Transparenz-Log. Das Schwachstellen-Gate gibt weiterhin 1 zurück. Ein signiertes Image kann bekannte Schwachstellen enthalten.

Halte den privaten Schlüssel aus Git heraus; das Beispiel ignoriert .demo-keys/ und *.key. Gib ein Schlüsselpasswort interaktiv ein und verwende für die Probe einen Wegwerf-Schlüssel. Standardmäßiges Signieren veröffentlicht Signatur-Metadaten und den öffentlichen Schlüssel in einem Transparenz-Log. Produktions-Verifikation benötigt eine vertrauenswürdige Signaturrichtlinie, nicht einen beliebigen öffentlichen Schlüssel, der mit einem Image geliefert wird.

Wir signieren das Image, um sicherzustellen, dass niemand es auf dem Weg in die Produktion verändert hat. Aber die Angreifer werden schlauer. Lies den Bericht zur Shai-Hulud-Familie, um von dem Vorfall zu erfahren, bei dem ein signiertes Image vom Angreifer verändert wurde:

The Shai-Hulud Family: A Taxonomy of Modern Supply Chain Worms 🪱

Seven supply chain worm campaigns, from Shai-Hulud to malware with valid provenance, and what each one teaches us about software trust.

containersecurity.dev

7. Erst SIP, dann ship

Die Shai-Hulud-Familie veranschaulicht, warum das Scannen eines finalen Images nicht ausreicht: Bösartige Pakete können Entwickler und CI anvisieren, bevor ein Image überhaupt existiert. KI-Coding-Agenten sind eine weitere Umgebung mit Zugriff auf Code, Tools und potenziell Anmeldedaten.

SIP: Security Immediate Plan verbindet die Kontrollen miteinander:

1. Agenten sandboxen. Isoliere die Ausführung und beschränke Anmeldedaten, Netzwerkzugriff und eingebundene Verzeichnisse.
2. Abhängigkeiten absichern. Verwalte Maven-Abhängigkeits- und Plugin-Versionen, inspiziere den aufgelösten Baum und prüfe Updates. Gradle- und npm-Projekte brauchen ihre eigenen Locking- und Installationsrichtlinien; dieses Maven-Beispiel nutzt diese Werkzeuge nicht.
3. Builds härten. Halte Compiler und Build-Tools in der Build-Stufe und führe das finale Image ohne Root-Rechte aus.
4. Attestieren. Erzeuge SBOM und Provenance, einschließlich relevanter Build-Stufen.
5. Vor der Promotion scannen. Scanne den exakten Digest, erzwinge deine Schwachstellenrichtlinie und verifiziere vertrauenswürdige Signaturen vor dem Deployment.

Sandbox → Lock → Harden → Attest → Scan. Kein einzelner Scanner, kein Image und keine Signatur sichert die gesamte Supply Chain. Für Agenten-Isolation und ökosystemspezifische Abhängigkeitskontrollen siehe die vollständige SIP-Implementierung.

Diese Anleitung demonstriert drei dieser Kontrollen durchgängig an einem echten Java-Image: Harden (eine DHI-Runtime, die als Non-Root-Benutzer läuft), Attest (SBOM und Provenance, einschließlich der Build-Stufe) und Scan (das Gaten des exakten Digests vor der Promotion). Sie berührt Lock nur teilweise, über den oben gezeigten Maven-Abhängigkeitsbaum und die Versionsdisziplin; vollständiges Dependency-Locking für Gradle- und npm-Projekte liegt außerhalb dieses Beispiels. Agenten sandboxen – das Isolieren von KI-Coding-Agenten und das Beschränken ihrer Anmeldedaten, ihres Netzwerkzugriffs und ihrer Mounts – wird hier überhaupt nicht geübt, also behandle es als zusätzliche SIP-Kontrolle und nicht als etwas, das dieses Experiment bewiesen hat.

Lies mehr über sbx und Kits hier:

Docker Sandbox Kits: A Hands-On Tutorial

A step-by-step walkthrough of Docker Sandboxes and Sandbox Kits: run a plain sandbox, compose a published Kit, then build your own GitHub CLI mixin.

containersecurity.dev

Wenn du fertig bist, entferne die dedizierte lokale Registry und ihre temporären Daten:

docker rm -f dockerize-java-demo-registry

Fazit

Drei Erkenntnisse gingen aus diesem Lauf hervor, und sie passen direkt zum Commando-Team:

Das Härten des Basis-Images und das Signieren des Ergebnisses sind notwendig, aber nicht ausreichend. Die Rüstung der Commandos hielt die Kreaturen fern, die mit dem Basis-Image kamen; diejenigen, die sich in Tomcat und Jackson verstecken, sind ein anderer Kampf, und er wird auf der Ebene der Abhängigkeiten geführt. Behebe, was du auslieferst, beweise, wie du es gebaut hast, und scanne den exakten Digest, bevor er die Produktion erreicht.

Weiterlernen: Artikel und Tutorials

• SBOM mit Docker Scout generieren — Software-Inventare inspizieren und exportieren.
• Der vergiftete Macchiato — Java-SBOM-Attestierungen, Cosign und OCI-Artefakte.
• Docker Hardened Images sind kostenlos — gehärtete Basis-Images und Schwachstellenvergleiche.
• Die Shai-Hulud-Familie — Taxonomie moderner Supply-Chain-Würmer.
• Docker Sandbox Kits: Ein praktisches Tutorial — Agenten-Isolation und Capability-Kontrollen.
• Black Forest Commandos: Asgard-Mission zum Selbermachen — eine längere, praktische Version der Commandos-Mission.

Offizielle Dokumentation

• Docker Scout SBOM CLI
• Docker Scout CVE CLI
• Docker BuildKit SBOM-Attestierungen
• Docker BuildKit Provenance
• Trivy
• Sigstore Cosign
• Docker Sandboxes

Die Black Forest Commandos in meinen Büchern

• Docker and Kubernetes Security. Um etwas über Linux-Capabilities (die, die wir hier verworfen haben) oder sichere CI-Workflows zu lernen, schau in dieses Buch.
• Black Forest Shadow. Die Entstehungsgeschichte von Gord, Rothütle, Evie und den CVE-Monstern, angesiedelt im Schwarzwald des Jahres 1865.
• Black Forest Commandos: Asgard-Mission. Der Comic hinter dem Abenteuer der Commandos in Asgard. Die Geschichte erweitert die Mythologie, die in meinen Talks und Workshops verwendet wird. Willst du das Ende wissen? Spoiler-Warnung!

SIP it before you ship it.

Mohammad-Ali A'râbi — Docker Captain, Autor und Schöpfer der Black Forest Commandos.

Die Ergebnisse sind eine datierte Momentaufnahme aus dem verlinkten Beispiel. Prüfe Versionen, Berechtigungen und Sicherheitsrichtlinien und führe die Checks vor dem Produktiveinsatz erneut aus.