Docker Hub unter der Lupe: 90% der beliebtesten Images haben kritische Sicherheitslücken

Back openDesk Edu for a sovereign, open-source education — every vote counts.

Docker Hub unter der Lupe: 90% der beliebtesten Images haben kritische Sicherheitslücken – und was du JETZT tun kannst | DevOps | Tobias Weiss

Die harte Wahrheit: Deine Container sind wahrscheinlich unsicher. Eine aktuelle Studie von Cristhian Kapelinski, Beatriz Machado und Diego Kreutz (2026) analysiert die am häufigsten genutzten Docker Hub Images und kommt zu einem alarmierenden Ergebnis: Ein einzige unsicheres Base-Image kann eine gesamte Organisation kompromittieren – und fast jedes Image hat mindestens eine kritische Sicherheitslücke.

Warum das einen JEDEN betrifft

Docker Hub ist die Basis für die meisten Container-Deployments weltweit. Wenn du:

Docker Images aus dem Internet nutzt (z. B. FROM ubuntu, FROM nginx, FROM node)
Auf Kubernetes, Docker Swarm oder anderen Orchestrierungstools setzt
Microservices, CI/CD-Pipelines oder Serverless-Funktionen betreibst

... dann hängst du wahrscheinlich von einem der analysierten Base Images ab – und damit von deren Sicherheitsstatus.

💥 Fakt: Eine Schwachstelle in einem Base-Image wird an alle davon abgeleiteten Images vererbt. Wenn also ubuntu:latest eine kritische Lücke hat, betrifft das Millionen von Deployments, die darauf aufbauen.

Die Studie: Was wurde analysiert?

Die Forscher haben die Top 1.000 beliebtesten Docker Hub Images (nach Download-Zahlen) auf Folgendes untersucht:

Kriterium	Ergebnis	Risiko
Sicherheitslücken (CVEs)	89,2% hatten mindestens 1 kritische CVE	❌ Hoch
Hardcoded Secrets	12,4% enthielten API Keys/Passwords	❌ Hoch
Fehlkonfigurationen	67,8% liefen als `root`-User	❌ Mittel
Veraltete Pakete	78,3% hatten veraltete Dependencies	❌ Mittel

Die gefährlichsten Base Images (Top 5)

Image	Kritische CVEs	Secrets gefunden	Läuft als root	Empfehlung
`alpine:latest`	3	❌ Nein	✅ Ja	✅ Nutze `alpine:3.18` + Distroless
`ubuntu:latest`	12	❌ Nein	✅ Ja	✅ Nutze `ubuntu:22.04` + Minimal
`nginx:latest`	5	✅ Ja!	✅ Ja	❌ Vermeiden! Nutze `nginx:alpine`
`node:latest`	8	✅ Ja!	✅ Ja	❌ Nutze `node:18-alpine`
`python:latest`	10	✅ Ja!	✅ Ja	❌ Nutze `python:3.11-slim`

🔍 Quelle: arXiv:2608.02669v1 – Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images

Die größten Risiken im Detail

1️⃣ Supply Chain Angriffe: Der unsichtbare Feind

Ein klassisches Beispiel: Der SolarWinds-Hack (2020).

Ein Kompromittiertes Base-Image wird auf Docker Hub hochgeladen.
Tausende Unternehmen laden es herunter und bauen ihre Anwendung darauf auf.
Resultat: Alle diese Unternehmen sind kompromittiert – ohne es zu wissen.

💡 Lösung: Image-Signaturen prüfen mit Cosign oder Notary.

# Beispiel: Cosign-Signatur prüfen
cosign verify --key cosign.pub ghcr.io/user/image:tag

2️⃣ Hardcoded Secrets: Der selbstverschuldete Albtraum

Die Studie fand API Keys, Datenbank-Passwords und private SSH-Schlüssel in öffentlichen Images.

Beispiel: Ein python:latest-Image enthielt einen AWS Access Key mit vollem Admin-Zugriff.
Folgen: Wenn ein Angreifer diesen Key findet, kann er deine gesamte Cloud-Infrastruktur übernehmen.

💡 Lösung: Secrets scannen mit Trivy oder Gitleaks.

# Trivy: Secrets & Vulnerabilities scannen
trivy image --severity CRITICAL,MEDIUM your-image:tag

3️⃣ Root-User: Das Standard-Risiko

67,8% der Images laufen als root-User – ein kritisches Sicherheitsrisiko!

Warum schlecht? Ein Angreifer, der den Container kompromittiert, hat volle Root-Rechte auf dem Host (wenn der Container nicht richtig isoliert ist).
Beispiel: Ein Exploit in nginx kann den Host übernehmen, wenn der Container als root läuft.

💡 Lösung: Immer als Non-Root-User laufen lassen und USER-Direktive in deinem Dockerfile nutzen.

# Beispiel: Non-Root-User in Dockerfile
FROM alpine:3.18

# Non-Root-User erstellen
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Als Non-Root-User ausführen
USER appuser

# Deine Anwendung kopieren und ausführen
COPY --chown=appuser:appgroup . /app
WORKDIR /app
CMD ["./start.sh"]

4️⃣ Veraltete Pakete: Das schleichende Risiko

78,3% der Images hatten veraltete Pakete – ein Hauptgrund für Sicherheitslücken.

Beispiel: openssl:1.0.2 (veraltet) hat mehrere kritische CVEs, während openssl:3.0+ sicher ist.
Folgen: Selbst wenn dein Code sicher ist, kann eine veraltete Dependency dein System kompromittieren.

💡 Lösung: Automatische Updates mit dependabot oder renovate und regelmäßige Scans.

# Beispiel: GitHub Dependabot für Dockerfile
# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

🔧 Praktische Lösungen: Wie du deine Container sicherst

✅ Schritt 1: Sichere Base Images wählen

Zweck	Empfohlenes Image	Warum?
Allgemein (Alpine)	`alpine:3.18`	Leicht, minimal, sicher
Allgemein (Debian)	`debian:12-slim`	Stabil, gut gewartet
Allgemein (Ubuntu)	`ubuntu:22.04`	LTS, langfristige Updates
Distroless	`gcr.io/distroless/base`	No Shell, minimal Attack Surface
Node.js	`node:18-alpine`	Alpine-Basis, kleiner
Python	`python:3.11-slim`	Slim-Variante, weniger Pakete
Nginx	`nginx:alpine`	Alpine-Basis, sicherer
Postgres	`postgres:15-alpine`	Alpine-Basis, weniger Angriffsfläche

💡 Tipp: Nutze --platform=linux/amd64, um Multi-Arch-Images zu vermeiden (kann Sicherheitslücken enthalten).

# Beispiel: Sicheres Image pullen
docker pull --platform=linux/amd64 node:18-alpine

✅ Schritt 2: Images vor dem Deployment scannen

Tool	Zweck	Installation	Beispielbefehl
Trivy	Vulnerabilities + Secrets	`brew install trivy`	`trivy image your-image:tag`
Snyk	Vulnerabilities + License Issues	`npm install -g snyk`	`snyk container test your-image:tag`
Grype	Vulnerabilities	`brew install grype`	`grype your-image:tag`
Docker Scout	Vulnerabilities (Docker Native)	In Docker Desktop	`docker scout quickview your-image:tag`

💡 Tipp: In CI/CD integrieren (z. B. GitHub Actions, GitLab CI).

# Beispiel: Trivy in GitHub Actions
# .github/workflows/docker-scan.yml
name: Docker Image Scan

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t your-image:latest .
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'your-image:latest'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
      - name: Upload Trivy scan results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: 'trivy-results.sarif'

✅ Schritt 3: Multi-Stage Builds nutzen

Problem: Viele Images enthalten Build-Tools (z. B. gcc, make), die im Produktions-Container nicht benötigt werden – aber Sicherheitslücken enthalten können.

Lösung: Multi-Stage Builds – nur das Nötigste im finalen Image.

# Beispiel: Multi-Stage Build für Node.js
# Stage 1: Build
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Production
FROM node:18-alpine
WORKDIR /app

# Nur die Build-Artefakte kopieren (keine Build-Tools!)
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./

# Non-Root-User
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

EXPOSE 3000
CMD ["node", "dist/index.js"]

✅ Schritt 4: Minimale Images: Distroless & Scratch

Image-Typ	Vorteile	Nachteile	Beispiel
Distroless	❌ Keine Shell, minimal	⚠️ Debugging schwer	`gcr.io/distroless/nodejs:18`
Alpine	❌ Leicht, sicher	✅ Gut für die meisten Anwendungen	`alpine:3.18`
Slim	❌ Weniger Pakete	⚠️ Größer als Alpine	`debian:12-slim`
Scratch	❌ Absolut minimal	❌ Keine Libraries (nur für statische Binaries)	`scratch`

💡 Tipp: Nutze Distroless für Produktions-Images, aber Alpine für Entwicklung (wegen Shell).

# Beispiel: Distroless für Node.js
FROM gcr.io/distroless/nodejs:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM gcr.io/distroless/nodejs:18
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./

USER nonroot:nonroot
EXPOSE 3000
CMD ["/app/dist/index.js"]

✅ Schritt 5: Immutable Images & Version Pinning

Problem: FROM ubuntu:latest kann sich jederzeit ändern – und plötzlich neue Sicherheitslücken enthalten.

Lösung: Immer spezifische Versionen nutzen (z. B. ubuntu:22.04.3).

# ❌ Schlechte Praxis (kann sich ändern)
FROM ubuntu:latest
FROM node:latest
FROM alpine:latest

# ✅ Gute Praxis (immutable)
FROM ubuntu:22.04.3
FROM node:18.17.1
FROM alpine:3.18.4

💡 Tipp: Nutze renovate oder dependabot, um automatisch auf neue Versionen upzudaten.

📊 Checkliste: Ist dein Docker-Setup sicher?

Frage	Ja	Nein	Aktion
Nutze ich spezifische Versionen (kein `latest`)?	✅	❌	Versionen pinnen
Laufen meine Container als Non-Root-User?	✅	❌	`USER`-Direktive nutzen
Scanne ich Images vor dem Deployment?	✅	❌	Trivy/Snyk integrieren
Nutze ich Multi-Stage Builds?	✅	❌	Build-Tools entfernen
Nutze ich minimale Base Images (Alpine/Distroless)?	✅	❌	Auf Distroless/Alpine umsteigen
Prüfe ich Image-Signaturen?	✅	❌	Cosign/Notary nutzen
Habe ich Dependabot/Renovate für Dockerfiles?	✅	❌	Automatische Updates einrichten
Laufen meine Container mit least privileges?	✅	❌	Security Context prüfen

💡 Tipp: 9/9 Ja? → Dein Setup ist state-of-the-art! 0–4 Ja? → Dringender Handlungsbedarf!

🚀 Tools im Vergleich

Tool	Vulnerability Scanning	Secret Scanning	License Scanning	Integration	Kosten
Trivy	✅ Ja	✅ Ja	❌ Nein	CLI, CI/CD	Kostenlos
Snyk	✅ Ja	✅ Ja	✅ Ja	CLI, CI/CD, IDE	Freemium
Grype	✅ Ja	❌ Nein	❌ Nein	CLI, CI/CD	Kostenlos
Docker Scout	✅ Ja	❌ Nein	❌ Nein	Docker GUI	Kostenlos (Docker Pro)
Anchore	✅ Ja	✅ Ja	✅ Ja	CLI, CI/CD	Freemium
Clair	✅ Ja	❌ Nein	❌ Nein	API, Kubernetes	Kostenlos

💡 Empfehlung: Trivy für Einsteiger, Snyk für Enterprise.

🔗 Weiterführende Ressourcen

Docker Security Cheat Sheet – OWASP
CIS Docker Benchmark – Center for Internet Security
Trivy GitHub – Open-Source Scanner
Snyk Container – Enterprise-Scanner
Distroless Images – Minimale Images von Google
Cosign: Signing Docker Images – Sigstore

💬 Fazit: Handeln statt hoffen

Die Studie zeigt: Docker Hub ist ein Minenfeld. Aber das Gute ist: Du kannst dich schützen – und das ohne großen Aufwand.

🎯 Sofort umsetzbar:

Scanne alle deine Images (Trivy/Snyk).
Ersetze latest-Tags durch spezifische Versionen.
Nutze Non-Root-User und Multi-Stage Builds.
Wechsle auf Distroless/Alpine für Produktions-Images.
Integriere Scans in deine CI/CD.

🚀 Langfristig:

Image-Signaturen prüfen (Cosign).
Automatische Updates (Dependabot/Renovate).
Immutable Infrastructure (keine manuellen Änderungen).

💡 Letzter Tipp: Fang heute an. Die nächste Sicherheitslücke in deinem Docker-Setup könnte morgen ausgenutzt werden.

🔗 Original-Studie: Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images (arXiv:2608.02669v1)

📌 Tags: #Docker #Security #DevOps #Container #SupplyChain #Cloud

Cart

Wishlist

Your wishlist is empty

Docker Hub unter der Lupe: 90% der beliebtesten Images haben kritische Sicherheitslücken – und was du JETZT tun kannst

KI-generierte Infrastruktur: Warum dein Terraform-Code eine Sicherheitslücke ist (und wie du das änderst)