Docker Hub ist für viele Administratoren und Selfhoster die erste Anlaufstelle, wenn es um Container-Images geht. Mit nur wenigen Zeilen in einer docker-compose.yml lässt sich nahezu jede Anwendung in Betrieb nehmen.
Doch genau diese Einfachheit birgt auch Risiken. In den vergangenen Monaten wurde deutlich, dass selbst Images bekannter Projekte kompromittiert werden können. Angreifer nutzten gestohlene Zugangsdaten von Maintainern, um manipulierte Images unter vertrauenswürdigen Repository-Namen bereitzustellen.
Die gute Nachricht: Mit einigen bewährten Sicherheitsmaßnahmen lässt sich das Risiko erheblich reduzieren.
Warum Docker-Images ein Sicherheitsrisiko darstellen
Ein Docker-Image besteht letztlich aus einer Sammlung von Dateien und Programmen. Sobald ein Container gestartet wird, werden diese Dateien mit den Rechten des Containers ausgeführt.
Enthält ein Image Schadcode, kann dieser beispielsweise:
- Daten stehlen
- Kryptowährungs-Miner starten
- Passwörter auslesen
- Schadsoftware nachladen
- Container im Netzwerk angreifen
- den Docker-Host kompromittieren (bei falscher Konfiguration)
Je größer die Berechtigungen eines Containers sind, desto größer sind auch die möglichen Auswirkungen.
Was bei den aktuellen Angriffen passiert ist
Viele Administratoren gehen davon aus, dass bekannte Docker-Hub-Repositories automatisch sicher sind. Leider stimmt das nicht immer.
Im Jahr 2026 wurden unter anderem Repositorys bekannter Open-Source-Projekte kompromittiert. Dabei verschafften sich Angreifer Zugriff auf die Docker-Hub-Konten der Maintainer und veröffentlichten manipulierte Images unter bereits bekannten Tags.
Besonders gefährlich war dabei:
- bestehende Image-Tags wurden überschrieben
- Benutzer erhielten beim nächsten Pull automatisch das manipulierte Image
- CI/CD-Pipelines installierten teilweise unbemerkt die kompromittierte Version
Diese Vorfälle zeigen deutlich, dass nicht nur unbekannte Images ein Risiko darstellen.
Warum latest problematisch sein kann
Viele Compose-Dateien enthalten noch immer:
image: nginx:latest
Das wirkt zunächst komfortabel, bringt jedoch einige Nachteile mit sich.
Beim nächsten Pull kann plötzlich eine völlig andere Version installiert werden.
Mögliche Folgen:
- neue Fehler
- inkompatible Änderungen
- geänderte Konfigurationen
- Sicherheitsprobleme
- ungewollte Downgrades oder Upgrades
Besser ist eine feste Versionsnummer:
image: nginx:1.29.2
Dadurch bleibt das System reproduzierbar.
Versionstags oder Image-Digests?
Noch sicherer als Versionsnummern sind sogenannte Image-Digests.
Beispiel:
image: nginx@sha256:5d93b...
Ein Digest verweist exakt auf einen bestimmten Image-Inhalt.
Selbst wenn jemand später den Tag 1.29.2 überschreibt, bleibt der Digest unverändert.
Vorteile
- unveränderlich
- reproduzierbare Deployments
- ideal für Produktivsysteme
- Schutz gegen manipulierte Tags
Docker-Images vor dem Einsatz prüfen
Vor jeder Installation sollte ein Image auf bekannte Sicherheitslücken überprüft werden.
Sehr beliebt ist Trivy.
Beispiel:
trivy image nginx:1.29.2
Trivy überprüft unter anderem:
- bekannte CVEs
- veraltete Bibliotheken
- fehlerhafte Konfigurationen
- Secrets im Image
- Lizenzinformationen
Auch Docker Scout bietet umfangreiche Sicherheitsanalysen direkt für Docker-Images.
Idealerweise erfolgt die Prüfung automatisch innerhalb einer CI/CD-Pipeline.
Automatische Updates mit Bedacht einsetzen
Werkzeuge wie Watchtower vereinfachen Updates erheblich.
Allerdings gilt:
Automatische Updates können auch manipulierte oder fehlerhafte Images verteilen.
Deshalb empfiehlt sich:
- automatische Benachrichtigung statt automatischer Installation
- Images zunächst in einer Testumgebung prüfen
- Backup vor jedem Update
- anschließend kontrolliert aktualisieren
Gerade bei produktiven Systemen ist ein geplanter Update-Prozess meist sicherer als vollständig automatisierte Aktualisierungen.
Nur vertrauenswürdige Quellen verwenden
Vor jeder Installation sollte geprüft werden:
- Wer veröffentlicht das Image?
- Ist das Repository offiziell?
- Wie aktiv wird das Projekt gepflegt?
- Wann erschien das letzte Update?
- Gibt es eine Dokumentation?
Vertrauenswürdige Quellen sind beispielsweise:
- offizielle Docker-Images
- Images der jeweiligen Projektentwickler
- bekannte Open-Source-Projekte
- eigene, selbst gebaute Images
Bei unbekannten Images ist besondere Vorsicht geboten.
Secrets niemals im Image speichern
Ein häufiger Fehler besteht darin, API-Schlüssel oder Passwörter direkt in Images oder Compose-Dateien abzulegen.
Schlecht:
ENV PASSWORD=MeinSuperPasswort
Oder:
environment:
MYSQL_ROOT_PASSWORD=meinpasswort
Besser:
.env-Dateien verwenden- Docker Secrets nutzen
- Passwortmanager einsetzen
- sensible Dateien niemals in Git veröffentlichen
So bleiben vertrauliche Informationen besser geschützt.
Images signieren und verifizieren
Neben klassischen Sicherheitsprüfungen gewinnt die Signierung von Images zunehmend an Bedeutung.
Moderne Verfahren wie Cosign oder Notation ermöglichen es, die Herkunft eines Images kryptografisch nachzuweisen.
Dadurch kann überprüft werden:
- stammt das Image wirklich vom Entwickler?
- wurde es nachträglich verändert?
- ist die Signatur gültig?
Gerade für Unternehmen und größere Selfhosting-Umgebungen wird dies künftig eine immer wichtigere Rolle spielen.
Best Practices für Selfhoster
Für die meisten privaten Docker-Server reichen bereits einige einfache Maßnahmen aus:
✅ Keine latest-Tags verwenden
✅ Nur offizielle Images einsetzen
✅ Regelmäßig Sicherheitsupdates installieren
✅ Images vor dem Einsatz mit Trivy prüfen
✅ Container möglichst ohne Root-Rechte betreiben
✅ Keine unnötigen Privilegien vergeben
✅ Docker-Socket niemals ungeschützt freigeben
✅ Backups regelmäßig testen
✅ Image-Digests für kritische Anwendungen verwenden
✅ Sicherheitsmeldungen der jeweiligen Projekte verfolgen
Fazit
Docker gehört zu den leistungsfähigsten Werkzeugen für Selfhoster und Administratoren. Gleichzeitig basiert jede Installation auf dem Vertrauen in das verwendete Image.
Die jüngsten Angriffe zeigen, dass selbst bekannte Projekte nicht automatisch vor einer Kompromittierung geschützt sind. Wer feste Versionen oder Digests verwendet, Images regelmäßig überprüft und nur vertrauenswürdige Quellen nutzt, reduziert das Risiko erheblich.
Mit wenigen zusätzlichen Sicherheitsmaßnahmen lassen sich Docker-Umgebungen deutlich robuster gestalten – ohne auf den Komfort von Containern verzichten zu müssen.
Gerade in produktiven Umgebungen gilt daher: Nicht jedes Image ist automatisch vertrauenswürdig. Vertrauen sollte immer durch Überprüfung ergänzt werden.
