Container-Technologien wie Docker haben die Softwareentwicklung revolutioniert. Doch wo Vorteile entstehen, lauern auch neue Bedrohungen – insbesondere dann, wenn Entwickler unzureichend auf Sicherheit achten. Ein aktueller Report deckt auf: Tausende Container-Images auf Docker Hub enthalten versehentlich sensible Zugangsdaten. Die Gefahr ist real – und sie betrifft nicht nur Entwickler, sondern ganze Unternehmen weltweit.
Wenn Bequemlichkeit zur Bedrohung wird
Mit über 15 Millionen registrierten Benutzern und mehr als 13 Milliarden monatlichen Pulls (Stand September 2024, laut Docker Inc.) ist Docker Hub das größte öffentliche Repository für Container-Images weltweit. Entwickler können Images dort hochladen und mit anderen teilen – ein zentraler Bestandteil moderner DevOps-Prozesse. Doch genau diese Offenheit macht die Plattform auch anfällig für Risiken.
Eine alarmierende Analyse des Sicherheitsunternehmens JFrog und der open-source Sicherheitsplattform DockerScout vom März 2024 hat ergeben: Über 10.000 frei zugängliche Images auf Docker Hub beinhalten versehentlich hinterlegte Zugangsdaten. Darunter befinden sich API-Keys, SSH-Private Keys, Datenbankverbindungsdaten und Passwörter – vielfach ohne jegliche Verschlüsselung.
Laut dieser Studie fanden sich unter den entdeckten Zugangsdaten unter anderem:
- 3.612 GitHub-PATs (Personal Access Tokens),
- 1.218 AWS-Schlüsselpaare,
- mehr als 8.000 .env- und Konfigurationsdateien mit sensiblen Informationen,
- sowie 110 SSH-Schlüssel mit Zugriffsrechten auf Produktionssysteme.
Die Untersuchung zeigte darüber hinaus, dass bei rund 85 % der betroffenen Container-Images die vertraulichen Informationen noch aktiv und nutzbar waren – manche davon sogar Monate nach ihrer erstmaligen Analyse.
Die Risiken für Unternehmen und Organisationen
Was auf den ersten Blick wie ein individuelles Entwicklerversehen wirkt, birgt auf Organisationsebene massive Risiken. Viele Unternehmen binden öffentliche Container-Images direkt in ihre Build- oder Deployment-Pipelines ein – oft ohne konkrete Sicherheits- oder Prüfmechanismen. Die potenziellen Folgen:
- Zugriff auf interne Infrastrukturen: Angreifer können über kompromittierte API-Schlüssel Zugriff auf Cloud-Ressourcen wie AWS, Azure oder GitHub gewinnen.
- Laterale Bewegung in Netzwerken: Ein SSH-Key innerhalb eines Containers kann als Einstiegstor in produktive Systeme dienen.
- Verlust geistigen Eigentums: Offen gelegte Tokens für private Git-Repositories ermöglichen unbefugte Einsicht in Quellcode und Betriebsinterna.
- Compliance-Risiken: Offenliegende personenbezogene Daten oder vertrauliche Geschäftsinformationen können regulatorische Konsequenzen nach sich ziehen (Stichwort: DSGVO, ISO 27001).
Die Nationale Initiative für Informations- und Internet-Sicherheit (NIFIS) warnte in einem Bericht 2024 davor, dass 46 % der deutschen Unternehmen keine konkreten Richtlinien zur sicheren Nutzung von Container-Registern implementiert haben. Besonders im Mittelstand ist das Sicherheitswissen rund um Containerisierung häufig noch lückenhaft.
Wie geheime Zugangsdaten in Images gelangen – und warum das ein Dauerproblem ist
Doch wie gelangen diese geheimen Informationen überhaupt in die Container-Images? In vielen Fällen schlichtweg durch Unachtsamkeit oder mangelndes Verständnis sicherheitskritischer Praktiken. Häufige Ursachen sind:
- Inclusion von Konfigurationsdateien mit sensiblen Variablen direkt ins Image (z. B. .env-Dateien).
- Hardcoded Secrets im Anwendungscode (API-Keys oder Datenbankverbindungen).
- Nutzung ungefilterter Build-Logs, die sensible Daten via Debug-Ausgaben preisgeben.
- Fehlerhafte .dockerignore-Dateien, die sensible Dateien nicht vom Build ausschließen.
Ein weiteres Problem: Selbst wenn Zugangsdaten aus einem public Image entfernt werden, bleiben ältere Pulls im Umlauf. Ohne explizite Image-Verwaltung oder Secret Rotation stellen solche Artefakte weiterhin ein Risiko dar.
Dieses Problem ist nicht neu. Bereits 2019 veröffentlichte Docker Inc. einen Sicherheitshinweis zu versehentlich eingebetteten Secrets, doch die aktuelle Analyse zeigt: Das Thema bleibt drängend aktuell – und wird durch die zunehmende Automatisierung von Build- und Deployment-Prozessen noch verschärft.
Best Practices: Wie Entwickler sichere Container-Images erstellen
Weder Docker Hub noch Container-Technologie an sich sind die Schuldigen. Die Verantwortung liegt bei den Teams, die Container-Images erstellen und veröffentlichen. Mit einem bewussten Sicherheitsansatz lassen sich die Risiken erheblich reduzieren. Folgende praktische Maßnahmen empfehlen sich dringend für Entwickler und DevSecOps-Teams:
- Vermeide Hardcoded Secrets: Niemals API-Schlüssel, Passwörter oder Tokens direkt im Code oder Image speichern. Nutze stattdessen Secrets-Management-Lösungen wie HashiCorp Vault, AWS Secrets Manager oder Kubernetes Secrets.
- Nutze ein Security-Scanning vor dem Upload: Tools wie Trivy, Snyk Container, Docker Scout oder JFrog Xray erkennen eingebettete Schlüssel, Konfigurationsfehler und Schwachstellen automatisiert im Build-Prozess.
- Verwalte deine .dockerignore-Datei effektiv: Sorge dafür, dass sensible Dateien – einschließlich .env, secrets.json, id_rsa – beim Build ausgeschlossen werden.
Ergänzend sollten Unternehmen darauf achten, dass Container-Builds grundsätzlich in CI/CD-Systemen mit definierten QA- und Security-Richtlinien erfolgen – nie manuell auf Entwicklerrechnern. Prinzipien wie least privilege, Audit-Trails und Deployment-Isolation sorgen für zusätzliche Sicherheit.
Technologische Antworten: Automatisierung und Sicherheitstools
Die steigende Zahl an Zwischenfällen wie durchgeführte Angriffe via „poisoned Container Images“ hat dazu geführt, dass sich auch die Tool-Landschaft angepasst hat. Immer mehr Plattformen integrieren Sicherheitsfunktionen direkt in den DevOps-Workflow. Hier ein Überblick über aktuelle Gegenmaßnahmen:
- Docker Scout: Seit 2023 offizieller Bestandteil der Docker-Plattform. Erkennt eingebaute Secrets, veraltete Abhängigkeiten und Schwachstellen auf Ebene der Softwarekomponenten.
- Sigstore und Cosign: Open-Source-Projekte zur kryptografischen Signierung und Verifikation von Container-Images – wichtig für Supply-Chain-Sicherheit.
- OWASP Docker Top 10: Ein industrieller Leitfaden zur Absicherung von Container-Umgebungen – vom Image über Layers bis hin zur Registry-Konfiguration.
Die Einführung von Security-as-Code und automatisierten Policy Enforcement-Tools wie OPA/Gatekeeper trägt zusätzlich zur systematischen Vermeidung einfacher Fehlerquellen bei.
Branchenperspektive: Sicherheit wird zum Wettbewerbsfaktor
Immer mehr Unternehmen erkennen, dass der Schutz ihrer Containerinfrastruktur ein entscheidender Teil der digitalen Resilienz ist. Laut einer Studie von Red Hat aus dem Frühjahr 2025 setzen 59 % der befragten Unternehmen mittlerweile auf automatisierte Container-Security-Lösungen – ein Anstieg um 18 Prozentpunkte im Vergleich zu 2023.
Gleichzeitig führen neue regulatorische Anforderungen – etwa durch NIS 2 oder das geplante EU-Cyber-Resilience-Act – dazu, dass auch kleine und mittlere Unternehmen sich stärker mit Container-Sicherheit befassen müssen. Der Schutz sensibler Daten ist dabei nur ein Aspekt. Vielmehr geht es um die Sicherstellung verlässlicher Lieferketten (Software-Supply-Chains) – in denen Container eine Schlüsselrolle spielen.
Docker selbst hat die Zeichen der Zeit erkannt und will 2026 verpflichtende Sicherheitsprüfungen für alle „official“ Images einführen. Darüber hinaus rät die Plattform seit Juli 2024 aktiv davon ab, Secrets direkt ins Image zu schreiben – und bietet Entwicklern stattdessen neue APIs zur getrennten Geheimnisspeicherung an.
Fazit: Sicherheit beginnt beim Container – und bei uns selbst
Die jüngsten Enthüllungen rund um Docker Hub sollten für Entwickler, DevOps-Teams und Unternehmen ein Weckruf sein. Container-Images sind kein statisches Artefakt, sondern potenzielle Eintrittspunkte für Angreifer – insbesondere wenn sie versehentlich mit vertraulichen Zugangsdaten veröffentlicht werden.
Mit Awareness, den richtigen Sicherheitsrichtlinien und geeigneten Tools lassen sich solche Vorfälle weitgehend vermeiden. Entscheidend ist jedoch: Sicherheit darf kein nachgelagerter Gedanke im Entwicklungsprozess sein. Sie muss von Anfang an mitgedacht und aktiv gestaltet werden.
Welche Tools nutzt ihr zur Absicherung eurer Container-Workflows? Habt ihr eigene Best Practices oder Beispiele aus der Praxis? Diskutiert mit uns in den Kommentaren und teilt diesen Artikel mit euren Teams – denn sichere Software beginnt mit gemeinsamem Wissen.
