Container sind aus modernen IT-Umgebungen kaum noch wegzudenken. Docker, Kubernetes und Container-basierte Anwendungen gehören längst zum Alltag vieler Administratoren. Dabei wird allerdings häufig unterschätzt, wie viele Komponenten ein gewöhnliches Container-Image tatsächlich mitbringt.

Genau hier setzt Docker mit den Docker Hardened Images (DHI) an. Diese speziell abgesicherten Images sollen die Angriffsfläche von Containern deutlich reduzieren und gleichzeitig die Software-Supply-Chain transparenter machen. Besonders interessant: Die grundlegenden Hardened Images stehen inzwischen auch kostenlos als Community-Variante zur Verfügung.

Das Problem gewöhnlicher Container-Images

Ein klassisches Linux-Base-Image enthält häufig wesentlich mehr Software, als eine Anwendung tatsächlich benötigt. Dazu können beispielsweise Shells, Paketmanager, Debugging-Werkzeuge, Netzwerktools oder Bibliotheken gehören, die im laufenden Container überhaupt nicht benötigt werden.

Docker nennt als Beispiel allgemeine Distributionen mit mehreren hundert installierten Paketen, während eine konkrete Anwendung davon möglicherweise nur einige Dutzend benötigt. Jedes zusätzliche Paket kann jedoch weitere bekannte Schwachstellen mitbringen und damit sowohl die Angriffsfläche als auch die Zahl der Meldungen eines Vulnerability-Scanners erhöhen.

Das ist auch aus Sicht eines Administrators ein bekanntes Prinzip: Was nicht installiert ist, muss nicht gepatcht und kann auch nicht angegriffen werden.

Was sind Docker Hardened Images?

Docker Hardened Images sind speziell für den produktiven Betrieb optimierte Container-Images. Sie sollen nur die Komponenten enthalten, die zur Ausführung der jeweiligen Anwendung notwendig sind.

Docker beschreibt dabei vier wesentliche Eigenschaften:

• möglichst kleine und gehärtete Images
• kontinuierliche Sicherheitsupdates
• möglichst wenige bekannte CVEs
• nachvollziehbare Herkunft und Zusammensetzung der Images

Die Images sind dabei nicht einfach nur verkleinerte Varianten bestehender Docker-Images. Docker baut und pflegt die verwendeten Systempakete teilweise selbst auf Basis der jeweiligen Upstream-Projekte.

Unterstützt werden unter anderem bekannte Linux-Basen wie Debian und Alpine. Dadurch sollen bestehende Umgebungen möglichst ohne grundlegenden Wechsel der Distribution migriert werden können.

Deutlich kleinere Angriffsfläche

Einer der größten Vorteile liegt in der Reduzierung unnötiger Komponenten.

Produktionscontainer benötigen normalerweise weder einen Texteditor noch Compiler, Debugger oder einen Paketmanager. Auch eine Shell ist für den eigentlichen Betrieb häufig überflüssig.

Genau diese Bestandteile werden bei Hardened Images soweit möglich entfernt. Docker spricht dabei von einer möglichen Reduzierung der Angriffsfläche um bis zu 95 Prozent gegenüber herkömmlichen Images.

Das hat zwei Vorteile.

Zum einen stehen einem Angreifer nach einer erfolgreichen Kompromittierung wesentlich weniger Werkzeuge innerhalb des Containers zur Verfügung. Zum anderen reduziert sich häufig die Zahl der vom Vulnerability-Scanner gefundenen Schwachstellen erheblich.

Near-Zero CVEs

Docker wirbt bei den Hardened Images mit „Near-zero CVEs“. Die Images werden kontinuierlich aktualisiert, sobald entsprechende Sicherheitsupdates zur Verfügung stehen.

Das bedeutet allerdings nicht, dass ein Hardened Image grundsätzlich vollkommen frei von Schwachstellen ist.

Neue CVEs können jederzeit veröffentlicht werden. Entscheidend ist vielmehr, dass möglichst wenig unnötige Software vorhanden ist und Sicherheitsupdates zeitnah in neue Images einfließen.

Für den Betrieb bedeutet das weiterhin:

docker pull IMAGE:TAG

beziehungsweise regelmäßige Aktualisierungen der verwendeten Container-Images.

Ein gehärtetes Image ersetzt also keinen vernünftigen Update-Prozess.

SBOM: Was steckt eigentlich im Container?

Ein weiterer wichtiger Bestandteil von DHI ist die Software Bill of Materials (SBOM).

Eine SBOM ist im Grunde eine vollständige Stückliste der Software innerhalb eines Images. Sie dokumentiert beispielsweise verwendete Bibliotheken und Pakete.

Docker liefert die Hardened Images mit überprüfbaren und signierten SBOM-Informationen aus. Zusätzlich gibt es Informationen über bekannte CVEs und die Herkunft des Builds.

Gerade in größeren Unternehmensumgebungen wird das zunehmend wichtig.

Statt bei einer neuen Sicherheitslücke erst herausfinden zu müssen, in welchen Containern eine bestimmte Bibliothek vorhanden ist, kann diese Information über entsprechende Security- und Supply-Chain-Werkzeuge ausgewertet werden.

SLSA Build Level 3 Provenance

Docker liefert für die Hardened Images außerdem sogenannte SLSA Build Level 3 Provenance.

Damit lässt sich nachvollziehen, wie ein Image erstellt wurde und aus welchen Quellen seine Komponenten stammen. Die Herkunft des Images wird damit überprüfbarer.

Das ist ein wichtiger Unterschied zu irgendeinem Image, das man beispielsweise auf einer öffentlichen Registry findet.

Bei einem beliebigen Image muss man letztendlich darauf vertrauen, dass der Herausgeber das Image korrekt gebaut und nicht manipuliert hat.

Bei einem modernen Supply-Chain-Sicherheitsmodell soll dagegen möglichst nachvollziehbar sein:

Source Code
    ↓
Build-System
    ↓
Pakete
    ↓
Container-Image
    ↓
Signatur / Provenance / SBOM

Damit wird aus dem klassischen „Ich vertraue dem Image“ zunehmend ein überprüfbarer Prozess.

Migration soll möglichst einfach sein

Ein interessantes Konzept von Docker ist die sogenannte Drop-in Adoption.

In vielen Fällen soll ein vorhandenes Base-Image lediglich gegen das entsprechende Hardened Image ausgetauscht werden können. Docker verspricht dabei nur minimale Änderungen an bestehenden Workflows.

Aus beispielsweise

FROM python:3.13

würde entsprechend das passende Docker-Hardened-Image.

Natürlich sollte man eine solche Änderung trotzdem testen. Gerade bei sehr kleinen Images können administrative Werkzeuge fehlen, die ältere Anwendungen oder eigene Startskripte stillschweigend voraussetzen.

Warum fehlt plötzlich die Shell?

Wer mit sehr minimalistischen Container-Images arbeitet, stößt irgendwann auf ein interessantes Problem:

docker exec -it container /bin/bash

funktioniert möglicherweise nicht mehr.

Und das ist Absicht.

Eine Shell gehört zu den Werkzeugen, die ein Angreifer nach einer erfolgreichen Kompromittierung besonders gut gebrauchen könnte. Dasselbe gilt für Tools wie curl, wget, Paketmanager oder Netzwerk-Diagnoseprogramme.

Aus Security-Sicht ist deren Entfernung sinnvoll.

Für Administratoren ändert sich damit allerdings die klassische Fehlersuche.

Früher:

docker exec -it container bash

und anschließend im Container nachsehen.

Bei konsequent gehärteten Images verlagert sich die Analyse stärker auf Logs, Observability, Debug-Container und externe Diagnosewerkzeuge.

Das ist zunächst ungewohnt, entspricht aber dem eigentlichen Container-Prinzip: Ein Container sollte möglichst nur genau den Prozess enthalten, für den er gebaut wurde.

Docker Hardened Images sind inzwischen kostenlos

Besonders interessant ist die aktuelle Lizenzierung.

Docker bietet eine Community-Version der Hardened Images kostenlos an. Der Open-Source-Katalog steht laut Docker unter der Apache-2.0-Lizenz zur Verfügung. Enthalten sind unter anderem gehärtete Images, SBOMs, SLSA-Level-3-Provenance und vollständige CVE-Informationen.

Damit sind die Images nicht mehr nur für große Unternehmen interessant.

Auch Betreiber kleiner Docker-Server, Homelabs oder selbst gehosteter Dienste können damit experimentieren.

Docker nennt mittlerweile einen Katalog von mehr als 1.000 Images auf seiner Produktseite; im April 2026 berichtete das Unternehmen bereits von mehr als 2.000 gehärteten Images und weiteren Artefakten wie Helm Charts und MCP-Servern im erweiterten DHI-Katalog.

Was kosten die Enterprise-Funktionen?

Für Unternehmen gibt es zusätzliche kostenpflichtige Varianten.

Der aktuell ausgewiesene Select-Tarif startet bei 5.000 US-Dollar pro Repository. Dazu gehören unter anderem FIPS/STIG-Varianten, SLA-basierte Behebung kritischer CVEs innerhalb von weniger als sieben Tagen sowie zusätzliche Anpassungsmöglichkeiten.

Darüber hinaus gibt es einen Enterprise-Tarif mit individuellen Preisen und erweiterten Möglichkeiten zur Anpassung der Images.

Für die meisten privaten Installationen oder klassischen Self-Hosting-Umgebungen dürfte zunächst die kostenlose Community-Version wesentlich interessanter sein.

Extended Lifecycle Support

Interessant für Unternehmen mit älteren Anwendungen ist auch Extended Lifecycle Support – ELS.

Normalerweise endet irgendwann die Pflege einer bestimmten Software-Version. Ab diesem Zeitpunkt gibt es vom eigentlichen Projekt keine Sicherheitsupdates mehr.

Docker bietet für bestimmte Images eine zusätzliche Absicherung von bis zu fünf Jahren nach dem Upstream-End-of-Life an. Dabei sollen weiterhin Sicherheitsupdates, SBOMs und Provenance-Daten bereitgestellt werden.

Diese Funktion gehört allerdings zum kostenpflichtigen Enterprise-Angebot.

Lohnt sich DHI für Self-Hosting?

Für Self-Hosting und kleinere Docker-Infrastrukturen finde ich den Ansatz besonders interessant.

Viele Server laufen heute beispielsweise mit:

Vaultwarden
Nextcloud
Grafana
Nginx
PostgreSQL
Redis
Node.js
Python

und weiteren Containern.

Normalerweise konzentriert man sich bei der Absicherung auf Firewall, Reverse Proxy, Updates, Fail2ban und möglichst geschlossene Ports.

Die Sicherheit des eigentlichen Container-Images wird dagegen häufig einfach dem Image-Hersteller überlassen.

Hardened Images setzen eine Ebene tiefer an:

Internet
   ↓
Firewall
   ↓
Reverse Proxy
   ↓
Container Runtime
   ↓
Hardened Container Image
   ↓
Anwendung

Damit wird die klassische Defense-in-Depth-Strategie sinnvoll ergänzt.

Hardened Images ersetzen kein Sicherheitskonzept

Trotzdem sollte man DHI nicht als Wunderwaffe betrachten.

Ein gehärtetes Base-Image schützt beispielsweise nicht automatisch vor einer Sicherheitslücke in der eigenen Anwendung.

Auch Dinge wie

regelmäßige Updates
minimale Container-Rechte
keine unnötigen Ports
Secrets nicht im Image speichern
read-only Filesystems
Netzwerksegmentierung
Image-Scanning
Logging
Backups

bleiben weiterhin notwendig.

Ein kompromittiertes Webinterface bleibt ein kompromittiertes Webinterface – auch wenn darunter ein hervorragend gehärtetes Linux-Image läuft.

Fazit

Docker Hardened Images sind eine interessante Entwicklung, weil sie ein altes und bewährtes Sicherheitsprinzip konsequent auf Container übertragen:

Installiere nur das, was wirklich gebraucht wird.

Weniger Pakete bedeuten weniger mögliche Schwachstellen, weniger CVE-Meldungen und weniger Werkzeuge, die ein Angreifer nach einer Kompromittierung missbrauchen könnte.

Noch interessanter wird das Konzept durch signierte SBOMs, nachvollziehbare Build-Provenance und kontinuierliche Updates.

Dass Docker die grundlegenden Hardened Images inzwischen kostenlos anbietet, macht das Thema auch für kleinere Unternehmen, Administratoren und Self-Hosting interessant.

Für bestehende Docker-Installationen würde ich deshalb nicht sofort sämtliche Container austauschen. Aber bei neuen Projekten oder beim nächsten ohnehin anstehenden Container-Update lohnt sich ein Blick auf den DHI-Katalog.

Denn letztendlich gilt bei Docker dasselbe wie früher bei einem gut administrierten Unix-Server:

Je weniger unnötige Software installiert ist, desto weniger muss abgesichert werden.