Die Gefahr in Ihrer Dockerfile: Wie ein einzelner COPY Ihre Container kompromittieren kann

In der sich schnell entwickelnden Welt der Containerisierung ist Docker zum De-facto-Standard für die Anwendungsbereitstellung geworden. Mit zunehmender Nutzung steigen jedoch auch die Sicherheitsrisiken, etwa Schwachstellen in Basis-Images, Angriffe während der Laufzeit und Fehlkonfigurationen. Während sich die meisten Entwickler auf Laufzeitsicherheit und Netzwerkeinstellungen konzentrieren, verbergen sich die kritischsten Schwachstellen oft direkt in der Dockerfile – wo eine einzige falsch platzierte COPY-Anweisung die Tür zu katastrophalen Sicherheitslücken öffnen kann.

Aktuelle Sicherheitswarnungen unterstreichen die Dringlichkeit, Dockerfiles als sicherheitskritischen Code zu behandeln. Ein bösartiger Container, der auf Docker Desktop läuft, könnte die Docker Engine ausnutzen und zusätzliche Container starten, ohne dass das Docker-Socket gemountet werden muss. Dies könnte unbefugten Zugriff auf Dateien des Hosts ermöglichen, wie CVE-2025-9074 zeigt. Diese Erkenntnis verdeutlicht, wie die Grundannahmen der Containerisierung über Isolation bei Vernachlässigung grundlegender Sicherheitspraktiken zerbrechen können.

Die verborgenen Schwachstellen in Ihrer Dockerfile

Die täuschende Natur von Container-Layern

Jede Anweisung in einer Dockerfile erzeugt einen neuen Layer im resultierenden Image. Diese Layer-Architektur ist zwar effizient für Caching und Distribution, hinterlässt aber eine dauerhafte Prüfspur aller Aktionen während des Build-Prozesses. Selbst wenn eine Datei in einer späteren Anweisung entfernt wird, bleibt sie auf den Zwischen-Layern zugänglich, wodurch Geheimnisse und sensible Daten dauerhaft im Image-Verlauf eingebettet sind.

Betrachten Sie dieses scheinbar harmlose Dockerfile-Beispiel:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY .env ./
RUN chmod +x deploy.sh && ./deploy.sh
RUN rm .env
COPY . .
CMD ["npm", "start"]

Trotz der Anweisung RUN rm .env bleibt die Umgebungsdatei im Layer erhalten, der durch COPY .env ./ erstellt wurde. Angreifer können diesen Layer mit einfachen Docker-Befehlen oder Analyse-Tools extrahieren und so Anmeldeinformationen auslesen, die Entwickler für sicher gehalten haben.

Kontamination durch Multi-Stage-Builds

Multi-Stage-Builds sind eine der mächtigsten Funktionen von Docker, um schlanke, sichere Images zu erstellen. Dabei werden die Anweisungen in der Dockerfile in separate Stages aufgeteilt, um sicherzustellen, dass nur die benötigten Dateien in das finale Image gelangen. Wird dies jedoch falsch umgesetzt, können sie zu Vektoren für ausgeklügelte Supply-Chain-Angriffe werden.

Das COPY --from-Kommando, das Artefakte zwischen den Stages kopiert, kann unbeabsichtigt kompromittierte Inhalte einführen, wenn externe Images oder Stages mit schädlichen Abhängigkeiten referenziert werden. Beispiel:

FROM node:18 as builder
RUN npm install -g suspicious-build-tool
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

Wenn das Paket suspicious-build-tool schädlichen Code enthält, kann es Hintertüren in die Build-Artefakte einschleusen, die dann in der Produktionsphase verwendet werden. Das finale Image wirkt sauber und minimal, verschleiert jedoch die während des Builds erfolgte Kompromittierung.

Das Vertrauensproblem bei Basis-Images

Das Fundament jeder containerisierten Anwendung bildet das Basis-Image, das in der FROM-Anweisung angegeben wird. Viele Entwickler behandeln die Auswahl des Basis-Images jedoch als reine technische Entscheidung, nicht als kritische Sicherheitsfrage. Unverifizierte öffentliche Images, selbst mit Millionen von Downloads, können vorinstallierte Malware, Hintertüren oder anfällige Softwareversionen enthalten.

Aktuelle Analysen beliebter Docker Hub-Images zeigen alarmierende Statistiken: Über 30 % der offiziellen Images enthalten mindestens eine Schwachstelle mit hoher Schwere, viele enthalten unnötige Pakete, die die Angriffsfläche vergrößern. Bei der Verwendung von Komfort-Images wie python:latest ohne Verständnis ihrer Zusammensetzung erben Entwickler nicht nur die gewünschte Funktionalität, sondern auch potenzielle Sicherheitsrisiken.

Erweiterte Angriffsvektoren durch COPY-Anweisungen

Geheimnis-Injektion durch Build-Kontext

Die Sicherheitsimplikationen der COPY-Anweisung gehen weit über das einfache Kopieren sensibler Dateien hinaus. Der Docker-Build-Kontext – alles im Verzeichnis, in dem docker build ausgeführt wird – steht während des Builds zur Verfügung. Entwickler fügen versehentlich sensible Informationen in diesen Kontext ein, etwa durch unvorsichtige Verzeichnisstrukturen oder zu großzügige .dockerignore-Regeln.

Ein besonders hinterhältiger Angriffsvektor nutzt Build-Argumente und Umgebungsvariablen innerhalb von COPY-Anweisungen:

FROM ubuntu:20.04
ARG SECRET_KEY
COPY --chown=www-data:www-data config/${SECRET_KEY}.conf /etc/app/

Dieses Muster, das scheinbar Build-Argumente sicher nutzt, schafft mehrere Schwachstellen. Der Wert SECRET_KEY wird dauerhaft in den Image-Metadaten eingebettet, und die referenzierte Konfigurationsdatei wird basierend auf externer Eingabe kopiert, die manipuliert werden könnte, um ungewollte Dateien zugänglich zu machen.

Symlink-Exploitation und Path Traversal

Der Umgang von Docker mit symbolischen Links während des COPY-Vorgangs kann unbeabsichtigten Zugriff auf Dateien ermöglichen. Wenn der Build-Kontext Symlinks enthält, die außerhalb des vorgesehenen Verzeichnisses zeigen, folgt der COPY-Befehl diesen Links und kann so Host-Systemdateien offenlegen.

Angreifer, die den Build-Kontext beeinflussen können (z.B. durch kompromittierte CI/CD-Pipelines), könnten Symlinks erstellen, die das Host-Dateisystem durchqueren:

ln -s /etc/passwd ./innocent-looking-file.txt
ln -s /home/user/.ssh/id_rsa ./public-key.txt

Der Befehl COPY . /app/ würde diese sensiblen Host-Dateien unbemerkt in das Container-Image kopieren, was sie für jeden zugänglich macht, der Zugriff auf das Image hat.

Das Paradox bei Multi-Stage-Builds in Bezug auf Sicherheit

Gemeinsame Abhängigkeiten über Stages hinweg

Multi-Stage-Builds sind zwar hervorragend, um die endgültige Imagegröße zu reduzieren, können aber Schwachstellen bei gemeinsam genutzten Abhängigkeiten schaffen, wenn mehrere Stages auf dieselben kompromittierten Basis-Images oder Paket-Repositories zugreifen. Beispiel:

FROM python:3.9 as builder
RUN pip install build-tools==1.0.0
COPY requirements.txt .
RUN pip wheel --no-cache-dir -r requirements.txt

FROM python:3.9-slim
COPY --from=builder /wheels /tmp/wheels
RUN pip install --find-links /tmp/wheels app-dependencies

Wenn das Paket build-tools oder eine Abhängigkeit in requirements.txt schädlichen Code enthält, kann dies den Wheel-Erstellungsprozess beeinflussen und kompromittierten Code in die finalen Wheels einschleusen, die dann in der Produktionsphase installiert werden.

Der Angriff durch Vererbungs-Kette

Fortgeschrittene Angreifer nutzen die Vererbungsnatur von Docker-Images aus, indem sie scheinbar legitime Basis-Images mit subtilen Hintertüren versehen. Durch das Veröffentlichen solcher Images können sie Hunderte oder Tausende von nachgelagerten Images beeinflussen, die von diesen Foundation-Images erben.

Der Angriff funktioniert, indem schädlicher Code in gängigen Basis-Images versteckt wird, der durch bestimmte Dateimuster oder Umgebungsbedingungen während der COPY-Operationen in Kind-Images aktiviert wird:

# Kompromittiertes Basis-Image mit versteckter Logik
FROM malicious/node:18-alpine
# Normale Anwendungs-Build
COPY package.json .
RUN npm install
COPY app.js .
# Das schädliche Basis-Image erkennt app.js und aktiviert versteckte Funktionen

Layer-Analyse und forensische Schwachstellen

Das Problem des persistenten Speichers

Das Layer-basierte Dateisystem von Docker erzeugt, was Sicherheitsexperten “persistent memory” nennen – Daten, die auch nach expliziten Löschbefehlen zugänglich bleiben. Legen Sie niemals Geheimnisse oder Anmeldeinformationen in Dockerfile-Anweisungen (Umgebungsvariablen, args oder fest in Befehlen) ab. Seien Sie besonders vorsichtig bei Dateien, die in den Container kopiert werden.

Jeder Layer führt eine vollständige Aufzeichnung der Dateisystemänderungen, was bedeutet, dass sensible Daten, die in frühen Layern kopiert wurden, forensisch wiederherstellbar sind. Moderne Container-Analysetools können die vollständige Historie der Dateisystemoperationen rekonstruieren und so Geheimnisse offenlegen, die Entwickler für sicher gehalten haben.

Das Problem verschärft sich durch die Verteilung und Caching-Mechanismen von Container-Registries. Diese Layer werden auf mehreren Systemen propagiert, wodurch zahlreiche Orte entstehen, an denen sensible Daten bestehen bleiben – oft lange, nachdem der ursprüngliche Container gelöscht wurde.

Verstärkung durch Registry-basierte Angriffe

Container-Registries fungieren unabsichtlich als Verstärker für Schwachstellen in Dockerfiles. Wird ein kompromittiertes Image in eine Registry hochgeladen, steht es unzähligen nachgelagerten Nutzern zur Verfügung, die auf die Sicherheitsüberprüfung der Registry vertrauen.

Das zeitabhängige Caching in Registries bedeutet, dass auch nach Entdeckung von Schwachstellen und Patches ältere, zwischengespeicherte Versionen mit kompromittierten Layern weiterhin kursieren können. Dies führt zu einer langen Nachwirkung der Sicherheitslücke, die Monate oder Jahre nach der ursprünglichen Kompromittierung bestehen bleiben kann.

Sichere Muster für Dockerfile-Erstellung

Zero-Trust-Ansatz für Build-Kontexte

Ein Zero-Trust-Ansatz bei der Erstellung von Dockerfiles beginnt damit, jeden Bestandteil des Build-Kontexts als potenziell feindlich zu behandeln. Das bedeutet, strenge .dockerignore-Dateien zu verwenden, die explizit Dateien ausschließen, und Projekte so zu strukturieren, dass der Build-Kontext nur das absolute Minimum enthält, das für den Build notwendig ist.

Nutzen Sie stattdessen eingebaute Docker-Funktionen wie Umgebungsvariablen, Docker-Secrets oder BuildKit für eine sichere Handhabung. Jede Methode hat ihren Anwendungsfall, und die Wahl hängt von den spezifischen Sicherheitsanforderungen und dem Betriebskontext Ihrer Anwendung ab.

Sicherheit bei Multi-Stage-Builds

Richtig implementierte Multi-Stage-Builds sollten jede Stage als Sicherheitsgrenze behandeln. Das bedeutet:

• Verwendung unterschiedlicher Basis-Images für Build- und Produktionsstages
• Implementierung expliziter Abhängigkeitsprüfungen bei jedem Übergang
• Nutzung der BuildKit-Secret-Mount-Fähigkeiten für sichere Anmeldeinformationen
• Erstellung von Zwischen-Validierungsstages, die die Integrität der kopierten Artefakte prüfen

Secret-Management mit BuildKit

Moderne Docker BuildKit bietet native Secret-Management-Fähigkeiten, die viele traditionelle COPY-basierte Sicherheitsrisiken eliminieren:

# syntax=docker/dockerfile:1
FROM python:3.9-slim

# Verwendung von Secret-Mounts anstelle von COPY
RUN --mount=type=secret,id=api_key \
    curl -H "Authorization: Bearer $(cat /run/secrets/api_key)" \
    https://api.example.com/secure-data | process_data

# Secrets werden niemals in Dateisystem-Layern geschrieben
COPY app.py /app/

Dieser Ansatz stellt sicher, dass sensible Daten niemals in Image-Layern verbleiben, während sie während des Builds zugänglich sind.

Erkennungs- und Abhilfestrategien

Automatisierte Sicherheitsprüfung für Dockerfiles

Automatisierte Sicherheits-Scans speziell für Dockerfiles sollten Tools nutzen, die die Layer-Struktur von Containern verstehen. Statische Analysetools sollten konfiguriert werden, um zu erkennen:

• Hardcodierte Geheimnisse in beliebigen Anweisungen
• Potenziell gefährliche COPY-Muster
• Unvertrauenswürdige Basis-Images
• Verstöße gegen Multi-Stage-Sicherheitsgrenzen

Laufzeit-Erkennung von Dockerfile-Komprimierungen

Selbst bei sicheren Build-Praktiken bleibt die Laufzeit-Erkennung entscheidend. Um Angriffe wie Leaky Vessels zu verhindern, bei denen Angreifer Root-Zugriff auf den Host erlangen, ist es wichtig, sowohl Host als auch Docker aktuell zu halten.

Überwachungssysteme sollten folgende Aktivitäten im Blick behalten: - Unerwartete Netzwerkverbindungen von Containern - Dateizugriffsmuster, die vom normalen Verhalten abweichen - Prozessausführungen, die auf Backdoor-Aktivitäten hindeuten - Container-zu-Host-Kommunikationsversuche

Notfallmaßnahmen

Bei Erkennung von Dockerfile-basierten Angriffen müssen Reaktionsprozesse die verteilte Natur der Container-Images berücksichtigen. Dazu gehören:

1. Sofortige Entfernung kompromittierter Images aus allen Registries
2. Benachrichtigung aller nachgelagerten Nutzer und Systeme
3. Forensische Analyse der betroffenen Layer und ihrer Verteilung
4. Wiederherstellung sauberer Images mit verifizierten Build-Prozessen

Die Zukunft der Dockerfile-Sicherheit

Neue Standards und Praktiken

Die Container-Sicherheitsgemeinschaft entwickelt neue Standards für sichere Container-Erstellung. Dazu gehören:

• Anforderungen an die Supply Chain für Basis-Images
• Kryptografische Signaturen einzelner Dockerfile-Anweisungen
• Integration mit Software Bill of Materials (SBOM)
• Zero-Trust-Netzwerke für Container standardmäßig

Technologische Weiterentwicklung

Zukünftige Docker-Versionen sollen erweiterte Sicherheitsfunktionen enthalten, wie:

• Obligatorische Secret-Scans während des Build-Prozesses
• Verbesserte Isolierung zwischen Stages
• Erweiterte Audit-Logs für alle COPY-Operationen
• Integration mit externen Sicherheits-Scanning-Diensten

Fazit: Dockerfiles als sicherheitskritischer Code

Ein einzelner gehackter Container kann sensible Informationen offenlegen, Zugriffsrechte erhöhen oder ganze Systeme lahmlegen. Die Beweisführung ist eindeutig: Dockerfiles müssen mit derselben Sicherheitsrigor behandelt werden wie andere kritische Infrastruktur-Code.

Die subtilen Schwachstellen in Dockerfiles sind besonders gefährlich. Im Gegensatz zu Laufzeitangriffen, die Überwachungssysteme auslösen, sind Dockerfile-Komprimierungen im Kern der Anwendung eingebettet und kaum sichtbar, bis es zu spät ist.

Organisationen sollten Docker nicht nur als Bereitstellungshilfe, sondern als integralen Bestandteil ihrer Sicherheitsarchitektur ansehen. Das bedeutet, umfassende Sicherheitsüberprüfungen, automatisierte Scans und die Behandlung jeder COPY-Anweisung als potenziellen Angriffsvektor umzusetzen.

Der Weg nach vorne erfordert eine Kombination aus technischen Lösungen – bessere Tools, erweiterte Docker-Funktionen, verbesserte Scanning-Tools – und kulturellen Veränderungen, die Sicherheitsdenken in alle Aspekte der Container-Entwicklung integrieren. Nur so können wir die verborgenen Gefahren in unseren Dockerfiles erkennen und beheben, um wirklich sichere containerisierte Anwendungen zu bauen.

Da die Containerisierung die moderne Softwarebereitstellung dominiert, werden die Anforderungen an die Sicherheit von Dockerfiles nur steigen. Denken Sie daran: Das Dockerfile ist im Wesentlichen die Dokumentation des Bauprozesses Ihrer Anwendung – eine Dokumentation, die Angreifer genauso lesen können wie Ihr Entwicklungsteam. Sorgen Sie dafür, dass diese Geschichte von Sicherheit und nicht von Schwachstellen erzählt wird.

Die Gefahr in Ihrer Dockerfile ist nicht nur theoretisch – sie ist unmittelbar, persistent und potenziell katastrophal. Die Frage ist nicht, ob Ihre aktuellen Dockerfiles Sicherheitslücken enthalten, sondern wie schnell Sie sie finden und beheben, bevor sie Sie finden.