⏱️ Lectura: 11 min
El catálogo de imágenes endurecidas de Minimus llegó para disputar un mercado que Google y Chainguard ya habían empezado a calentar: contenedores mínimos, sin shell ni gestor de paquetes, que prometen recortar entre 75% y 100% los CVEs reportados frente a las imágenes base oficiales.
📑 En este artículo
- TL;DR
- Qué pasó: Minimus abre su catálogo de imágenes endurecidas
- Contexto e historia: de la imagen gorda al distroless
- Por qué las imágenes endurecidas reducen los CVEs
- Ejemplo práctico: multi-stage build y pull del catálogo
- Datos y cifras del catálogo
- Impacto y análisis para LATAM
- Qué sigue
- Preguntas frecuentes
- Referencias
La promesa suena a marketing, pero el mecanismo es real y vale entenderlo. Acá repasamos qué publica Minimus, cómo funciona la reducción de vulnerabilidades, los datos del catálogo y cómo aplicar la idea en un pipeline de CI/CD en la región.
TL;DR
- Minimus publica un catálogo de imágenes de contenedor mínimas y endurecidas (hardened) para apps, bases de datos e infra.
- Varias imágenes anuncian reducciones de CVEs de entre 75% y 100% frente a las imágenes base oficiales.
- Ofrece variantes FIPS (cripto validada) y STIG (guías de endurecimiento del DoD) para entornos regulados.
- El truco técnico: quitar shell, gestor de paquetes y librerías que la app nunca ejecuta reduce la superficie de ataque.
- Compite con Google Distroless y Chainguard Images en el espacio de cadena de suministro de software.
- El tier gratuito viene sin soporte ni SLA; los parches priorizan a las suscripciones de pago.
- Para LATAM es relevante por cumplimiento (banca, gobierno) y por bajar ruido de escáneres en CI/CD.
Qué pasó: Minimus abre su catálogo de imágenes endurecidas
Minimus publicó un catálogo público de imágenes endurecidas y charts de Helm que cubre el stack típico de una empresa moderna: bases de datos (PostgreSQL, MariaDB, MongoDB, Redis, Elasticsearch), infraestructura de Kubernetes (cert-manager, Argo Rollouts, Kyverno, KEDA, external-dns), utilidades (Fluent Bit, Fluentd, Prometheus) y herramientas de desarrollo. Cada imagen aparece etiquetada con un porcentaje de reducción de vulnerabilidades; muchas marcan literalmente 100% reduction.
La propuesta no es nueva como categoría, pero sí en su amplitud. Junto a cada imagen estándar, Minimus ofrece variantes FIPS (con módulos criptográficos validados) y STIG (alineadas con las guías de endurecimiento del Departamento de Defensa de EE. UU.). Eso es exactamente lo que hoy una empresa regulada arma a mano, con semanas de trabajo y mantenimiento perpetuo.
Contexto e historia: de la imagen gorda al distroless
Durante años, el patrón por defecto fue arrancar un Dockerfile con FROM ubuntu o FROM node y empacar la aplicación encima. Cómodo, pero costoso: esas imágenes traen un sistema operativo casi completo — shell bash, apt o apk, compiladores, librerías de sistema, utilidades de red. Tu aplicación usa una fracción de eso; el resto es peso muerto y, peor, superficie de ataque.
En 2017 Google liberó Distroless, imágenes que contienen solo la aplicación y sus dependencias de runtime: sin shell, sin gestor de paquetes, sin nada que un atacante pueda aprovechar para moverse lateralmente. En 2022, ex-ingenieros de Google fundaron Chainguard y llevaron la idea a producto comercial con reconstrucciones diarias y SBOM (Software Bill of Materials) firmados. Minimus es el siguiente capítulo de esa misma historia.
El telón de fondo es la seguridad de la cadena de suministro de software. Ataques como SolarWinds, las vulnerabilidades de Log4j y los typosquatting en npm y PyPI dejaron claro que el contenedor que corre en producción es tan seguro como su eslabón más débil. Marcos como SLSA empujaron a tratar la procedencia y la minimización como requisitos, no como lujo.
💭 Clave: Una vulnerabilidad en un paquete que tu app nunca ejecuta sigue apareciendo en el escáner y sigue exigiendo respuesta del equipo. Quitar el paquete elimina el hallazgo de raíz.
Por qué las imágenes endurecidas reducen los CVEs
Acá está el matiz que separa el marketing de la ingeniería. Cuando Minimus anuncia 100% menos CVEs, no quiere decir que parchó cien vulnerabilidades: quiere decir que eliminó los paquetes que las contenían. Un escáner como Trivy o Grype compara los paquetes instalados contra bases de datos de CVEs. Si la imagen no trae bash, openssl de sistema, curl ni glibc completa, esos CVEs simplemente no existen en tu superficie.
Las imágenes endurecidas aplican varias técnicas combinadas:
- Minimización — solo la aplicación y sus dependencias directas de runtime. Nada de toolchains de compilación ni utilidades de depuración.
- Sin shell — al no haber
/bin/sh, un atacante que logre ejecución de comandos se queda sin intérprete para encadenar payloads. - Usuario no-root — el proceso corre con privilegios mínimos por defecto.
- Reconstrucción frecuente — al rearmar la imagen seguido, los parches upstream entran rápido y la ventana de exposición se acorta.
El siguiente diagrama resume por qué dos imágenes con la misma app dan resultados de escaneo opuestos:
graph LR
A["Imagen base completa"] --> B["Escaneo de CVEs"]
B --> C["Cientos de paquetes sin usar"]
D["Imagen minima endurecida"] --> E["Escaneo de CVEs"]
E --> F["Superficie casi nula"]Ejemplo práctico: multi-stage build y pull del catálogo
El patrón canónico para llegar a una imagen mínima es el multi-stage build: compilás en una imagen gorda con todas las herramientas y copiás solo el binario final a una imagen mínima. Veamos un ejemplo con Go:
# Etapa 1: build con toolchain completo
FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/api
# Etapa 2: runtime minimo y endurecido
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /app /app
USER nonroot
ENTRYPOINT ["/app"]La imagen final no tiene shell ni gestor de paquetes: solo tu binario. Para traer una imagen de un catálogo como el de Minimus, el comando es el mismo docker pull en cualquier sistema operativo. Lo que cambia es cómo abrís la terminal:
# Windows (PowerShell)
docker pull images.minimus.io/library/redis:latest
# macOS (Terminal / zsh)
docker pull images.minimus.io/library/redis:latest
# Linux (bash)
docker pull images.minimus.io/library/redis:latestUna vez descargada, podés escanearla y comparar el conteo de hallazgos contra la imagen oficial:
# Escaneo comparativo con Trivy (mismo comando en Win/macOS/Linux)
trivy image redis:latest
trivy image images.minimus.io/library/redis:latest⚠️ Ojo: sin shell no podés hacerdocker exec -it contenedor shpara depurar. Tenés que depurar con contenedores efímeros,kubectl debugo logs estructurados. Es un compromiso real: ganás seguridad, perdés comodidad de diagnóstico en caliente.
Datos y cifras del catálogo
El catálogo de Minimus es explícito con los números. Las reducciones publicadas no son uniformes: dependen de cuánto sobra en la imagen base original. Algunos ejemplos del propio catálogo:
- Imágenes de infraestructura y bases de datos populares marcan 100% reduction, es decir, cero CVEs reportados al momento del build.
- Herramientas de desarrollo y utilidades muestran rangos de 75% a 99% según las dependencias que arrastran.
- Casos con stacks más pesados o dependencias nativas marcan reducciones menores, del orden de 40% a 80%.
Minimus es transparente con la letra chica: “hardened” describe la configuración de seguridad al momento del build y no garantiza ausencia de vulnerabilidades futuras. El tier gratuito viene sin soporte, sin SLA ni cadencia de parches garantizada, y las actualizaciones de seguridad pueden aplicarse a las suscripciones de pago antes que al tier libre. Es el mismo modelo de negocio que Chainguard popularizó.
Impacto y análisis para LATAM
Para los equipos de la región, las imágenes endurecidas tocan dos dolores concretos. El primero es el cumplimiento: banca, fintech, salud y gobierno enfrentan auditorías que exigen contenedores con superficie mínima, criptografía validada (FIPS) y configuración endurecida (STIG). Armar y mantener esas variantes a mano consume tiempo de equipos que en muchas organizaciones ya están cortos de personal.
El segundo es el ruido de los escáneres. Cualquiera que haya conectado Trivy o Snyk a un pipeline conoce la fatiga: cientos de CVEs “críticos” en paquetes del sistema operativo base que la aplicación nunca toca. Ese ruido entrena al equipo a ignorar los reportes, lo que es peor que no escanear. Una imagen mínima deja en el reporte solo lo que importa, y eso devuelve sentido al gate de seguridad en CI/CD.
💡 Tip: antes de migrar todo, elegí un servicio de bajo riesgo, cambiá su imagen base por una variante mínima, corré tu suite de tests y compará el conteo de CVEs. El número suele convencer más que cualquier presentación.
La contrapartida es la dependencia de un proveedor para los rebuilds y la pérdida de herramientas de depuración dentro del contenedor. La decisión sensata es híbrida: imágenes mínimas en producción, e imágenes con shell solo en entornos de desarrollo donde la comodidad de diagnóstico pesa más que el endurecimiento.
Qué sigue
El mercado de imágenes mínimas y endurecidas pasó de ser un proyecto open source de nicho a una categoría con varios competidores comerciales. La diferenciación ya no está en “tener menos CVEs” — eso lo logra cualquiera que minimice — sino en la cadencia de parches, la procedencia verificable, los SBOM firmados y la cobertura de variantes reguladas. La entrada de Minimus presiona los precios y empuja a Google y Chainguard a mejorar su catálogo libre.
Para el desarrollador, la señal es clara: la imagen base “gorda” por defecto está en retirada en cargas de producción serias. En los próximos años, partir de una imagen mínima endurecida será tan estándar como hoy lo es usar HTTPS.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Una imagen endurecida con 100% menos CVEs es realmente invulnerable?
No. Significa que, al momento del build, el escáner no encontró CVEs conocidos en los paquetes instalados, porque se eliminaron los componentes que solía marcar. Pueden aparecer vulnerabilidades nuevas después, o estar en tu propio código de aplicación, que el escáner de imagen no evalúa.
¿Qué diferencia a Minimus de Google Distroless o Chainguard?
La idea central es la misma: minimizar y endurecer. Las diferencias están en el catálogo cubierto, la amplitud de variantes FIPS y STIG, la cadencia de reconstrucción, el modelo de soporte y el precio. Distroless es totalmente gratuito pero más acotado; Chainguard y Minimus son productos comerciales con tier libre limitado.
¿Puedo depurar un contenedor sin shell?
Sí, pero cambia el método. Usás contenedores de depuración efímeros (por ejemplo kubectl debug), copiás un binario de shell temporal o dependés de logs estructurados y métricas. La ausencia de shell es justamente lo que reduce el riesgo si un atacante logra ejecución.
¿Qué significan FIPS y STIG en estas imágenes?
FIPS se refiere a módulos criptográficos validados bajo el estándar federal de EE. UU., requeridos en muchos contratos de gobierno y banca. STIG son las guías técnicas de endurecimiento del Departamento de Defensa. Tener variantes listas evita que cada equipo las arme y mantenga por su cuenta.
¿Sirven para reducir el tamaño de la imagen además de los CVEs?
Sí. Al quitar el sistema operativo casi completo, las imágenes mínimas suelen pesar megabytes en lugar de cientos de megabytes. Eso acelera los pulls, reduce el uso de registro y mejora los tiempos de arranque en escalado automático.
Referencias
- Images & Charts — Minimus — catálogo público de imágenes endurecidas con porcentajes de reducción de CVEs.
- Google Distroless — proyecto open source que popularizó las imágenes de contenedor sin shell ni gestor de paquetes.
- Chainguard Images — repositorio de imágenes mínimas con reconstrucción diaria y SBOM firmados.
- SLSA — Supply-chain Levels for Software Artifacts — marco para procedencia y seguridad de la cadena de suministro.
- Docker: Multi-stage builds — documentación oficial del patrón para construir imágenes finales mínimas.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios