Qué está pasando realmente
Se ha identificado un nuevo vector de ataque que permite comprometer builds de Docker sin modificar el código fuente.
El problema está en el uso del cache de capas. Docker reutiliza capas previamente construidas para acelerar procesos, pero si ese cache es comprometido, puede introducir artefactos maliciosos directamente en la imagen final.
El resultado: tu código puede estar limpio, pero el build no.
A quién afecta
Este riesgo aplica a prácticamente cualquier equipo que use Docker:
- Pipelines CI/CD
- Builds en la nube
- Runners compartidos
- Arquitecturas multi-stage
Si estás reutilizando cache entre builds, estás expuesto.
Impacto real (sin hype)
Este tipo de ataque permite:
- Inyectar binarios maliciosos en imágenes de producción
- Evadir revisiones de código completamente
- Persistir entre builds a través del cache
Lo más peligroso: no deja señales obvias en el código fuente.
Ejemplo real de cómo ocurre
Un build típico puede verse así:
docker build .
Durante el proceso puede aparecer algo como esto:
Step 5/7 : RUN npm run build
---> Using cache
Ese Using cache es el punto sensible.
Si una capa fue comprometida previamente, Docker la reutiliza sin validación adicional, introduciendo código malicioso sin ejecutar nuevamente el paso.
Qué deberías hacer ahora mismo
Acciones inmediatas:
docker build --no-cache .
Además:
- Evita reutilizar cache entre proyectos
- Usa únicamente imágenes base confiables
- Aísla los entornos de build
- Revisa qué runners o pipelines comparten capas cacheadas
Checklist de mitigación
- Usa
docker build --no-cacheen pipelines sensibles - Implementa firma y verificación de imágenes
- No compartas cache entre repositorios o proyectos distintos
- Reconstruye imágenes regularmente desde cero
- Fija versiones de imágenes base y evita
latest - Monitorea artefactos generados en cada build
- Revisa permisos y aislamiento de tus runners
- Audita dependencias y pasos críticos del proceso de build
Qué cambia a partir de ahora
Este tipo de vulnerabilidad deja algo claro: el sistema de build también es parte de la superficie de ataque.
Durante años, muchos equipos asumieron que si el código estaba limpio, el build también lo estaba. Ese supuesto ya no alcanza.
Ahora también hay que validar:
- cómo se construye la imagen
- qué capas se reutilizan
- quién controla el cache
- qué artefactos terminan en producción
Qué deberías revisar en tu equipo hoy
Hazte estas preguntas:
- ¿Compartimos cache entre proyectos o pipelines?
- ¿Nuestros builds son reproducibles?
- ¿Verificamos imágenes antes de desplegar?
- ¿Tenemos visibilidad sobre los artefactos generados?
- ¿Podemos reconstruir una imagen crítica sin depender de cache previo?
Si no puedes responder con claridad, probablemente tienes un punto ciego en tu pipeline.
Por qué esto importa especialmente para equipos pequeños
Muchos equipos pequeños confían en defaults, runners compartidos y configuraciones heredadas para ganar velocidad. Eso es entendible, pero también abre espacio para riesgos silenciosos.
Cuando no hay un equipo de seguridad dedicado, el pipeline de build suele convertirse en una zona de confianza implícita. Justamente por eso este tipo de amenaza es importante: obliga a revisar una parte de la infraestructura que pocas veces se cuestiona.
Conclusión
Docker sigue siendo una pieza clave del ecosistema moderno, pero este tipo de ataque muestra una debilidad importante en cómo confiamos en el proceso de build.
La dirección es clara:
- menos confianza implícita
- más verificación
- más aislamiento
No se trata de dejar de usar Docker.
Se trata de dejar de asumir que todo lo que sale del build es seguro.