La mayoría de los equipos que trabajan con Spring Boot tienen sus contenedores en producción, pero pocos han revisado alguna vez el Dockerfile con ojos enfocados en la seguridad. Una encuesta reciente a 250 desarrolladores Spring revela que el 64% no sabe que ese fichero puede introducir vulnerabilidades graves. Este artículo explica por qué ocurre y qué puedes hacer al respecto sin necesidad de ser un experto en seguridad.
Si trabajas con Spring Boot y despliegas en contenedores, lo más probable es que tengas un Dockerfile en tu proyecto. También es probable que lo escribieras una vez, funcionase, y desde entonces nadie lo haya vuelto a mirar. Eso es exactamente el problema según la reciente encuesta "Spring Container Security Report 2026" de BellSoft Java, publicada en mayo de 2026 tras el evento Spring I/O 2026 en Barcelona.
El dato que más llama la atención del informe de BellSoft:
El 64% de los desarrolladores Spring encuestados no sabe que las decisiones que tomas en el Dockerfile pueden introducir vulnerabilidades de seguridad.
No es que no les importe la seguridad, sino que tienen un punto ciego enorme justo en el sitio donde menos se lo esperan.
La encuesta, realizada a 250 developers, arquitectos e ingenieros de plataforma que trabajan con Spring y contenedores, revela una brecha entre intención y práctica. La mayoría de equipos quiere tener sus contenedores seguros. Pero los números dicen otra cosa:
- Solo el 43% usa herramientas de escaneo de vulnerabilidades.
- Solo el 45% tira de registros de imágenes de confianza.
- El 36% reconoce que parchear de forma regular le cuesta trabajo.
- El 42% nunca ha oído hablar de las hardened images.
- Y solo el 2% aplica las cinco prácticas de seguridad recomendadas a la vez.
El problema es que muchos equipos asumen que el contenedor es, por definición, un entorno aislado y seguro. Y lo es, hasta cierto punto. Pero esa capa de confianza puede romperse mucho antes de que el contenedor arranque, en el momento en que escribes (o copias) el Dockerfile.
¿Por qué un Dockerfile mal escrito puede ser una vulnerabilidad?
Aquí está el núcleo del problema, y merece un momento de atención porque no es obvio.
Un Dockerfile no es solo un script de construcción de tu imagen. Es la especificación completa de lo que va a ejecutarse en producción: qué sistema operativo exacto, qué runtime, qué paquetes, qué usuario, qué puertos. Cada una de esas decisiones tiene implicaciones de seguridad, y estos son los errores más frecuentes y sus consecuencias:
- Imágenes base sin versión fija: usar
FROM eclipse-temurin:latest o FROM ubuntu:latest parece cómodo. Pero latest es una referencia móvil: hoy apunta a una imagen, mañana a otra. Puedes arrancar una build con una versión que tiene CVEs conocidos sin darte cuenta, porque nunca la fijaste.
- Imagen base demasiado grande: una imagen como
ubuntu o debian completa incluye cientos de paquetes que tu aplicación nunca va a usar. Cada paquete extra es superficie de ataque potencial. Si un atacante consigue acceso al contenedor, tiene más herramientas disponibles. Las imágenes minimalistas tipo alpine o distroless reducen esa superficie drásticamente.
- Secretos "hardcodeados" en el Dockerfile: un clásico que es más común de lo que parece. Un
ENV DB_PASSWORD=supersecreta o un ARG API_KEY=... en el Dockerfile quedan registrados en el historial de capas de la imagen. Aunque luego sobrescribas la variable, la capa original sigue ahí y es recuperable con docker history. Cualquiera con acceso a la imagen puede extraerla.
- Ejecutar el proceso como root: por defecto, los procesos dentro de un contenedor se ejecutan como
root. Si hay una vulnerabilidad en tu aplicación y alguien consigue escapar del contenedor (cosa que ha pasado), tiene privilegios de administrador en el host 😱 Añadir un USER nonroot al final del Dockerfile es un cambio de dos segundos que marca una diferencia enorme.
- Copiar todo el contexto de build sin filtros: un
COPY . . sin un .dockerignore bien definido puede meter en la imagen archivos que no deberían estar ahí: claves SSH, archivos .env, configuraciones locales, el propio .git. Nadie lo hace con mala intención. Simplemente no se piensa en ello y luego pasan cosas...
Los tres errores más frecuentes al construir un DockerFile
Si tuvieras que quedarte con tres cosas para revisar hoy mismo en tu Dockerfile, serían estas:
- Fija la versión de la imagen base y elige una minimalista: en lugar de
FROM eclipse-temurin:21, usa el digest exacto o al menos una etiqueta de versión completa (eclipse-temurin:21.0.11_10-jre-alpine) (info sobre las releases de Eclipse Temurin). Y si puedes usar una imagen distroless o equivalente, mejor todavía. Menos paquetes, menos CVEs potenciales.
- Saca los secretos del Dockerfile: los secretos no tienen nada que hacer en un
ENV o ARG. Monta los secretos en tiempo de ejecución desde tu orquestador (Kubernetes Secrets, Vault, etc.). Si usas BuildKit, tienes soporte para --secret en tiempo de build sin que quede rastro en las capas.
- Define un usuario sin privilegios: añade esto antes del
ENTRYPOINT o CMD de tu Dockerfile para que el proceso se ejecute sin privilegios de root (no es una solución mágica pero elimina un agujero habitual):
RUN addgroup --system appgroup && adduser --system --ingroup appgroup appuser
USER appuser
Consejo: los multi-stage builds son otro cambio con mucho impacto. En ellos separas la fase de compilación (donde necesitas el JDK completo, Maven, etc.) de la imagen final (que solo necesita el JRE y el JAR). El resultado es una imagen de producción considerablemente más pequeña y sin herramientas de build que no pintan nada en un entorno en vivo y son otra superficie de ataque más.
Hardened images y el resto de capas que casi nadie aplica
Más allá del Dockerfile, existe otro nivel de seguridad que la encuesta deja en evidencia: el 42% de los developers Spring no sabe qué es una hardened image (o "imagen endurecida" en español).
Una imagen endurecida no es más que una imagen base que ha pasado por un proceso de "bastionado": se eliminan paquetes innecesarios, se aplican parches de seguridad, se configura siguiendo benchmarks tipo CIS, y normalmente incluye un proceso de actualización y certificación continua. BellSoft ofrece las suyas para el ecosistema Java bajo la marca Liberica (por eso hicieron la encuesta, claro), pero hay otras opciones en el mercado.
El resto de prácticas que la encuesta identifica como ausentes en la mayoría de equipos:
- Escaneo de vulnerabilidades (CVEs): herramientas como Trivy o Grype analizan tu imagen en busca de CVEs conocidos. Se integran fácilmente en cualquier pipeline de CI/CD y son gratuitas y de código abierto.
- Software Bill of Materials (SBOMs): un inventario de todos los componentes de tu imagen. Imprescindible si necesitas cumplir con normativas como la directiva NIS2 de la comisión europea, o si trabajas con clientes que lo exigen. La encuesta revela que el 44% de los desarrolladores ni sabe qué regulaciones aplican a su stack tecnológico.
- Firma de imágenes: permite verificar que la imagen que despliega en producción es exactamente la que salió de tu pipeline, y no ha sido manipulada. Herramientas como Cosign (proyecto de la CNCF) lo hacen relativamente accesible.
Que solo el 2% aplique todas estas prácticas a la vez no implica que sean complicadas, sino que muy pocos han priorizado implementarlas de forma sistemática.
Por dónde empezar a asegurar tus contenedores sin volverte loco
No hace falta abordar todo a la vez. Una hoja de ruta razonable podría ser la siguiente:
- Audita tu Dockerfile esta misma semana: revisa imagen base, usuario, secretos y el
.dockerignore. Esta es una acción de bajo coste pero con un posible alto impacto.
- Evalúa si tu imagen base es la adecuada: si usas una imagen genérica de Docker Hub sin mantenimiento activo, considera migrar a una con soporte oficial para Java (Eclipse Temurin, Amazon Corretto, o una hardened image si el contexto lo justifica.
- Añade Trivy a tu CI: una sola línea en tu pipeline de GitHub Actions o GitLab CI. Te dará visibilidad inmediata de los CVEs en tus imágenes sin tener que cambiar nada más.
- Genera un SBOM en cada build: herramientas como Syft lo hacen en un comando.
La conclusión del informe es que la seguridad no puede ser "un extra que gestionan otros". Si sigues creyendo que Kubernetes o tu proveedor de servicios gestionados te protegen de un Dockerfile mal diseñado, estás jugando a la ruleta rusa.
La seguridad en contenedores empieza en ese modesto fichero de texto de 20 líneas que lleva meses sin que nadie lo toque. Así que toca prestarle la atención que merece.