En el mundo de los contenedores, existe una paradoja incómoda: intentar reducir el tamaño de una imagen con la intención de disminuir su superficie de ataque a menudo dificulta la detección de vulnerabilidades, ya que los escáneres no pueden identificar con claridad qué contiene la imagen tan «ligera».
Este conflicto refleja una tensión global en la industria entre minimizar posibles vectores de ataque y mantener una visibilidad clara para garantizar la seguridad. Para comprender por qué existe este problema y cómo superarlo es necesario analizar la evolución tradicional de los contenedores y sus limitaciones en las operaciones posteriores al despliegue (conocidas como Day 2 operations).
El origen del sobrepeso en los contenedores
Durante años, el estándar de la industria consistía en usar imágenes de contenedores completas. La práctica habitual era que los desarrolladores partieran de una imagen base que incorporaba un sistema operativo completo, sobre el que agregaban la aplicación y luego la enviaban a producción. 
Esta metodología, aunque cómoda, generaba un serio problema de seguridad: estas imágenes contenían un shell, gestores de paquetes y múltiples herramientas que la aplicación no utilizaba en tiempo de ejecución. Cada componente extra no utilizado incrementaba la superficie de ataque potencial y el riesgo de vulnerabilidades. En caso de que un atacante comprometiera la aplicación, dispondría de herramientas integradas para escalar la brecha y descargar software malicioso adicional.
La brecha de seguridad de los contenedores distroless
Para contrarrestar estos riesgos, surgió el movimiento «distroless» (sin distribución). La idea era lógica y prometedora: eliminar todo lo que no fuera absolutamente necesario, creando contenedores con únicamente las dependencias mínimas para ejecutar la aplicación, sin incluir shell, gestores de paquetes ni utilidades adicionales.
Si bien esta aproximación redujo considerablemente la exposición, introdujo otra dificultad operativa significativa. Crear una imagen distroless es un proceso complejo y delicado, donde al recortar agresivamente la imagen, la metadata importante —como el manifiesto de los paquetes instalados— suele eliminarse por completo.
Este fenómeno ha sido bautizado como la «brecha de seguridad distroless» y no es teoría, sino una debilidad documentada ampliamente. Por ejemplo, herramientas de escaneo como Trivy advierten cuando falta la metadata del sistema operativo, y el informe sobre vulnerabilidades de Rezilion de 2022 evidenció un elevado índice de falsos negativos: vulnerabilidades activas que no se detectan por carecer del contexto necesario.
«Puedes tener un contenedor extremadamente pequeño, pero si el equipo de seguridad no puede escanearlo ni certificar su inocuidad, se convierte en un riesgo enorme para la conformidad normativa.»
Empresas como Chainguard también señalan la importancia de disponer de metadata completa para que los resultados del análisis reflejen la realidad del contenedor. En consecuencia, nos enfrentamos a una dicotomía incómoda: mantener contenedores hinchados con un gran riesgo o apostar por minimizarlos a costa de perder capacidad de auditoría.
De recortar a construir: la evolución hacia contenedores bottom-up
Por fortuna existe una tercera opción. En lugar de partir de una imagen grande a la que se recorta, con el riesgo de eliminar datos esenciales para la seguridad, se puede construir la imagen desde cero, solo con lo estrictamente necesario.
Este planteamiento se basa en armar la imagen dejando intactos los metadatos de los componentes, asegurando así que los escáneres de vulnerabilidades funcionen correctamente. En el ámbito open source, esta nueva generación recibe el nombre de «rocks» (rocas).
El proceso bottom-up se asemeja a una cadena de montaje dividida en tres fases: Slice (segmentación), Build (construcción) y Run (ejecución).
Primera fase: segmentación precisa
En esta etapa el contenedor comienza vacío. Con herramientas open source como Chisel, se extraen piezas finas y específicas de paquetes Linux confiables (por ejemplo, del repositorio oficial de Ubuntu). El objetivo es seleccionar únicamente los «trozos» que la aplicación realmente necesita.
Al usar fuentes reconocidas y conservar la metadata de estas partes, se garantiza la integridad de la cadena de suministro y la operación correcta de los escáneres de seguridad, logrado con una precisión quirúrgica.
Segunda fase: compilación declarativa
A diferencia del uso tradicional de Dockerfiles, donde las instrucciones son imperativas y el orden es crucial —lo que suele añadir complejidad y tamaño—, la construcción bottom-up sigue un modelo declarativo.
Con herramientas como Rockcraft, el desarrollador escribe un archivo YAML sencillo que describe qué necesita la aplicación. La herramienta recopila el código fuente, descarga los fragmentos seleccionados, los compila y genera una imagen estándar compatible con OCI. Así, se pasa de «ordenar cómo hacer la construcción» a simplemente «declarar el estado deseado».
name: chiseled-python
base: bare
build-base: ubuntu@26.04-lts
version: "3.14"
summary: Chiseled Python3.14 rock
description: Chiseled Python rock
license: Python-2.0
platforms: { amd64: }
run-user: _daemon_
parts:
install-python:
plugin: nil
stage-packages:
- base-files_release-info
- python3_core
Tercera fase: gestión eficiente de procesos en tiempo de ejecución
Para que un contenedor minimalista funcione correctamente, es fundamental gestionar el proceso PID 1 (el primer proceso del contenedor) para que recoja adecuadamente los procesos «zombie» (procesos muertos que consumen recursos). En sistemas operativos convencionales, el kernel lo hace automáticamente, pero en contenedores minimalistas esta funcionalidad suele perderse.
Las imágenes distroless típicamente eliminan el gestor de procesos para ahorrar espacio, lo que puede conducir a acumulación de zombies y fallos inesperados a gran escala. La solución bottom-up utiliza herramientas como Pebble, un gestor ligero que actúa como PID 1, hace de punto de entrada al contenedor y elimina correctamente esos procesos inactivos, manteniendo la estabilidad sin añadir peso innecesario.
Perspectivas futuras
Durante demasiado tiempo, el ecosistema cloud-native ha considerado que la visibilidad en seguridad y el minimalismo en contenedores estaban reñidos. La iniciativa distroless fue crucial para comprender los riesgos de las imágenes abultadas, pero las limitaciones de sus escaneos ya no son aceptables en entornos empresariales.
«Durante mucho tiempo, visibilidad en seguridad y contenedores minimalistas se han tratado como un juego de suma cero.»
La transición hacia una construcción declarativa de abajo arriba ofrece el equilibrio ideal: contenedores seguros, auditables y ligeros, sin sacrificar la experiencia del desarrollador ni la supervisión post-despliegue.
La seguridad en contenedores no debe ser un compromiso entre protección y operatividad, sino una convergencia de ambas, accesible gracias a nuevas metodologías y herramientas de código abierto.
