El peligro en tu Dockerfile: Cómo un solo COPY puede comprometer tu contenedor

En el panorama en rápida evolución de la contenerización, Docker se ha convertido en el estándar de facto para el despliegue de aplicaciones. Sin embargo, con el aumento de las preocupaciones de seguridad, también crecen los riesgos asociados, como fallos en las imágenes base, ataques durante la ejecución y configuraciones incorrectas. Aunque la mayoría de los desarrolladores se enfocan en la seguridad en tiempo de ejecución y en las configuraciones de red, las vulnerabilidades más críticas a menudo están a simple vista dentro del propio Dockerfile—donde una instrucción COPY mal ubicada puede abrir la puerta a brechas de seguridad catastróficas.

Los avisos de seguridad recientes subrayan la urgencia de tratar los Dockerfiles como código crítico para la seguridad. Un contenedor malicioso en Docker Desktop podría acceder al Docker Engine y lanzar contenedores adicionales sin necesidad de montar el socket de Docker. Esto podría permitir accesos no autorizados a archivos del usuario en el sistema host, como se demuestra con CVE-2025-9074. Esta revelación destaca cómo las suposiciones fundamentales de la contenerización sobre aislamiento pueden desmoronarse cuando se pasan por alto prácticas básicas de seguridad.

Las vulnerabilidades ocultas en tu Dockerfile

La naturaleza engañosa de las capas del contenedor

Cada instrucción en un Dockerfile crea una nueva capa en la imagen resultante. Esta arquitectura en capas, aunque eficiente para caché y distribución, genera una pista de auditoría persistente de cada acción durante el proceso de construcción. Incluso si un archivo se elimina en una instrucción posterior, puede seguir siendo accesible en las capas intermedias, haciendo que secretos y datos sensibles queden permanentemente incrustados en el historial de la imagen.

Considera este fragmento aparentemente inocente de Dockerfile:

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"]

A pesar de la instrucción RUN rm .env, el archivo de entorno permanece accesible en la capa creada por COPY .env ./. Los atacantes pueden extraer esta capa usando comandos simples de Docker o herramientas de análisis de imágenes, recuperando credenciales que los desarrolladores creían eliminadas de forma segura.

Contaminación en construcciones multi-etapa

Las construcciones en varias etapas representan una de las funciones más poderosas de Docker para crear imágenes ligeras y seguras. Divide las instrucciones en etapas distintas para asegurarte de que la salida solo contenga los archivos necesarios para ejecutar la aplicación. Sin embargo, si se implementan incorrectamente, pueden convertirse en vectores para ataques sofisticados en la cadena de suministro.

La instrucción COPY --from diseñada para copiar artefactos entre etapas de construcción, puede introducir inadvertidamente contenido comprometido al hacer referencia a imágenes externas o etapas construidas con dependencias contaminadas. Considera esta construcción en varias etapas:

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

Si el paquete suspicious-build-tool contiene código malicioso, puede inyectar puertas traseras en los artefactos de construcción que luego se copian a la etapa de producción. La imagen final parece limpia y mínima, ocultando la compromisión ocurrida durante la construcción.

El problema de confianza en la imagen base

La base de toda aplicación contenerizada descansa en la imagen base especificada en la instrucción FROM. Sin embargo, muchos desarrolladores tratan la selección de la imagen base como una decisión meramente técnica en lugar de una elección crítica de seguridad. Las imágenes públicas no verificadas, incluso aquellas con millones de descargas, pueden contener malware preinstalado, puertas traseras o versiones vulnerables de software.

Análisis recientes de imágenes populares en Docker Hub revelan estadísticas alarmantes: más del 30% de las imágenes oficiales contienen al menos una vulnerabilidad de alta gravedad, y muchas incluyen paquetes innecesarios que amplían la superficie de ataque. Cuando los desarrolladores usan imágenes de conveniencia como python:latest sin entender su composición, heredan no solo la funcionalidad prevista, sino también posibles vulnerabilidades.

Vectores avanzados de ataque a través de instrucciones COPY

Inyección de secretos mediante el contexto de construcción

Las implicaciones de seguridad de la instrucción COPY van mucho más allá de copiar archivos sensibles. El contexto de construcción—todo en el directorio desde donde se ejecuta docker build—se vuelve accesible al proceso de construcción. Los desarrolladores a menudo incluyen inadvertidamente información sensible en este contexto mediante estructuras de directorios descuidadas o reglas .dockerignore demasiado amplias.

Un vector de ataque particularmente insidioso implica el uso de argumentos de construcción y variables de entorno dentro de las instrucciones COPY:

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

Este patrón, aunque parece usar argumentos de construcción de forma segura, crea múltiples vulnerabilidades. El valor de SECRET_KEY queda incrustado permanentemente en los metadatos de la imagen, y el archivo de configuración referenciado se copia en función de una entrada externa que podría ser manipulada para acceder a archivos no deseados.

Explotación de enlaces simbólicos y traversal de rutas

El manejo de enlaces simbólicos durante las operaciones de COPY puede conducir a accesos no deseados a archivos. Cuando el contexto de construcción contiene enlaces simbólicos que apuntan fuera de la estructura de directorios prevista, la instrucción COPY sigue estos enlaces, exponiendo potencialmente archivos del sistema host al proceso de construcción del contenedor.

Los atacantes que puedan influir en el contexto de construcción (por ejemplo, a través de pipelines CI/CD comprometidos) pueden crear enlaces simbólicos que atraviesen el sistema de archivos del host:

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

La instrucción COPY . /app/ resultante copiaría sin saberlo estos archivos sensibles del host en la imagen del contenedor, haciéndolos accesibles a cualquiera que tenga acceso a la imagen.

La paradoja de seguridad en construcciones multi-etapa

Dependencias compartidas entre etapas

Las construcciones en varias etapas, aunque excelentes para reducir el tamaño final de la imagen, pueden crear vulnerabilidades en dependencias compartidas cuando varias etapas dependen de las mismas imágenes base comprometidas o repositorios de paquetes contaminados. Docker en varias etapas permite dividir los Dockerfiles en varias fases. Por ejemplo, una etapa para compilar y construir la aplicación, que luego puede ser copiada a etapas posteriores.

Considera un escenario donde tanto la etapa de construcción como la de producción extraen de un mismo repositorio de paquetes que ha sido comprometido:

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

Si el paquete build-tools o alguna dependencia en requirements.txt contiene código malicioso, puede influir en el proceso de construcción de ruedas, inyectando código comprometido en las ruedas finales que luego se instalan en la etapa de producción.

El ataque en la cadena de herencia

Los atacantes avanzados explotan la naturaleza de herencia de las imágenes Docker mediante compromisos cuidadosamente diseñados en las imágenes base. Al publicar imágenes base aparentemente legítimas con puertas traseras sutiles, pueden afectar a cientos o miles de imágenes descendientes que heredan de estas bases comprometidas.

El ataque funciona al incrustar código malicioso latente en imágenes base comunes, y activar comportamientos maliciosos mediante patrones de archivos específicos o condiciones de entorno que ocurren durante las operaciones COPY en las imágenes hijas:

# Imagen base comprometida con lógica oculta
FROM malicious/node:18-alpine
# Construcción normal de la aplicación
COPY package.json .
RUN npm install
COPY app.js .
# La imagen base maliciosa detecta app.js y activa funcionalidades ocultas

Análisis de capas y vulnerabilidades forenses

El problema de memoria persistente

El sistema de archivos en capas de Docker crea lo que los investigadores de seguridad llaman “memoria persistente”—datos que permanecen accesibles incluso después de comandos explícitos de eliminación. Nunca pongas secretos o credenciales en las instrucciones del Dockerfile (variables de entorno, args o codificados en comandos). Ten especial cuidado con los archivos que se copian en el contenedor.

Cada capa mantiene un registro completo de los cambios en el sistema de archivos, lo que significa que datos sensibles copiados en capas tempranas permanecen recuperables forensemente durante toda la vida útil de la imagen. Las herramientas modernas de análisis de contenedores pueden reconstruir el historial completo de operaciones en archivos, exponiendo secretos que los desarrolladores creían eliminados de forma segura.

El problema se agrava al considerar los mecanismos de distribución y caché de los registros de contenedores. Estas capas se propagan a través de múltiples sistemas, creando múltiples ubicaciones donde los datos sensibles persisten, a menudo mucho después de que el contenedor original ha sido destruido.

Amplificación de ataques basada en registros

Los registros de contenedores sirven inadvertidamente como multiplicadores de vulnerabilidades en Dockerfile. Cuando una imagen comprometida se sube a un registro, está disponible para innumerables usuarios downstream que confían en la validación de seguridad implícita del registro.

La naturaleza basada en tiempo del caché en registros significa que, incluso después de descubrir vulnerabilidades y aplicar parches, versiones antiguas en caché de capas comprometidas pueden seguir circulando. Esto crea una cola larga de exposición que puede persistir meses o años después del compromiso inicial.

Patrones seguros para construir Dockerfiles

Implementar contextos de construcción de confianza cero

Un enfoque de confianza cero para la construcción de Dockerfiles comienza tratando cada elemento del contexto de construcción como potencialmente hostil. Esto implica usar archivos .dockerignore estrictos que excluyen explícitamente archivos en lugar de incluirlos, y estructurar los proyectos para que el contexto de construcción contenga solo lo mínimo necesario.

En su lugar, utiliza funciones integradas de Docker como variables de entorno, secretos de Docker o BuildKit para un manejo seguro. Cada método tiene su caso de uso apropiado, y la elección depende de los requisitos específicos de seguridad y del contexto operacional de tu aplicación.

Aislamiento de seguridad en construcciones en varias etapas

Las construcciones en varias etapas correctamente implementadas deben tratar cada etapa como un límite de seguridad. Esto significa:

• Usar diferentes imágenes base para las etapas de construcción y producción
• Implementar escaneo explícito de dependencias en cada transición de etapa
• Utilizar las capacidades de montaje de secretos de BuildKit para manejo seguro de credenciales
• Crear etapas de verificación intermedias que validen la integridad de los artefactos copiados

Gestión de secretos en BuildKit

BuildKit de Docker ofrece capacidades nativas de gestión de secretos que eliminan muchos riesgos tradicionales basados en COPY:

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

# Usando montajes de secretos en lugar de 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

# Los secretos nunca se escriben en capas del sistema de archivos
COPY app.py /app/

Este método asegura que los datos sensibles nunca persistan en las capas de la imagen, mientras se proporciona acceso necesario durante las operaciones de construcción.

Estrategias de detección y mitigación

Escaneo automatizado de seguridad en Dockerfiles

Implementar escaneo de seguridad automatizado específicamente para Dockerfiles requiere herramientas que entiendan la naturaleza en capas de las construcciones. Las herramientas de análisis estático deben configurarse para detectar:

• secretos codificados en cualquier tipo de instrucción
• patrones potencialmente peligrosos en COPY
• uso de imágenes base no confiables
• violaciones en los límites de seguridad en construcciones en varias etapas

Detección en tiempo de ejecución de compromisos en Dockerfile

Incluso con prácticas de construcción seguras, la detección en tiempo de ejecución sigue siendo crucial. Para protegerse contra vulnerabilidades conocidas de escape de contenedores como Leaky Vessels, que generalmente resultan en que el atacante obtenga acceso root al host, es vital mantener tanto el host como Docker actualizados.

Los sistemas de monitoreo deben rastrear: - conexiones de red inesperadas desde los contenedores - patrones de acceso a archivos que no coinciden con el comportamiento esperado de la aplicación - ejecución de procesos que indiquen posible activación de puertas traseras - intentos de comunicación entre contenedores y host

Procedimientos de respuesta ante emergencias

Cuando se detecten compromisos basados en Dockerfile, los procedimientos de respuesta deben considerar la naturaleza distribuida de las imágenes de contenedor. Esto incluye:

1. eliminación inmediata de imágenes comprometidas en todos los registros
2. notificación a todos los usuarios y sistemas downstream
3. análisis forense de las capas afectadas y su historial de distribución
4. reconstrucción de imágenes limpias usando procesos de construcción verificados

El futuro de la seguridad en Dockerfile

Normas y prácticas emergentes

La comunidad de seguridad de contenedores está desarrollando nuevos estándares para la construcción segura de contenedores. Estos incluyen:

• requisitos de atestación en la cadena de suministro para imágenes base
• firma criptográfica de instrucciones individuales en Dockerfile
• integración con generación de listas de materiales de software (SBOM)
• redes de confianza cero por defecto

Evolución tecnológica

Se espera que futuras versiones de Docker incluyan funciones de seguridad mejoradas como:

• escaneo obligatorio de secretos durante la construcción
• mejor aislamiento entre etapas de construcción
• auditorías mejoradas para todas las operaciones COPY
• integración con servicios externos de análisis de seguridad

Conclusión: tratar los Dockerfiles como código crítico para la seguridad

Solo se necesita un contenedor hackeado para revelar información sensible, aumentar niveles de acceso o incluso paralizar sistemas enteros. La evidencia es clara: los Dockerfiles deben tratarse con el mismo rigor de seguridad que cualquier otro código de infraestructura crítica.

La naturaleza sutil de las vulnerabilidades basadas en Dockerfile los hace particularmente peligrosos. A diferencia de los ataques en tiempo de ejecución que activan sistemas de monitoreo, las compromisos en Dockerfile se incrustan en la misma base del despliegue de la aplicación, haciéndolos casi invisibles hasta que es demasiado tarde.

Las organizaciones deben cambiar de tratar Docker solo como una conveniencia de despliegue a reconocerlo como un componente crítico de su arquitectura de seguridad. Esto implica realizar revisiones de seguridad exhaustivas en Dockerfiles, análisis automatizados y tratar cada instrucción COPY como un posible vector de ataque.

El camino hacia adelante requiere una combinación de soluciones técnicas—mejoras en las herramientas, funciones mejoradas en Docker, capacidades de análisis avanzadas—y cambios culturales que integren la seguridad en cada aspecto del desarrollo de contenedores. Solo reconociendo y abordando los peligros ocultos en nuestros Dockerfiles podemos construir aplicaciones contenerizadas verdaderamente seguras.

A medida que la contenerización continúa dominando el despliegue de software moderno, los riesgos en la seguridad de Dockerfile solo aumentarán. Recuerda que el Dockerfile es, en esencia, la documentación del proceso de construcción de tu aplicación—documentación que los atacantes pueden leer tan fácilmente como tu equipo de desarrollo. Asegúrate de que esa historia cuente una de seguridad, no de vulnerabilidad.

El peligro en tu Dockerfile no es solo teórico—es inmediato, persistente y potencialmente catastrófico. La pregunta no es si tus Dockerfiles actuales contienen vulnerabilidades de seguridad, sino qué tan rápido puedes encontrarlas y corregirlas antes de que te encuentren a ti.