Las mejores herramientas de endurecimiento de imágenes en 2026

Las plantillas estándar de imágenes de contenedores vienen sobrecargadas de software innecesario, lo que aumenta la superficie de ataque y puede dar lugar a CVE y vulnerabilidades. Los investigadores que analizaron 7.380 imágenes de Docker basadas en Debian descubrieron que ninguna estaba libre de vulnerabilidades conocidas. El endurecimiento de imágenes es el proceso de reducir las imágenes de contenedores a versiones más pequeñas y seguras para reducir los puntos de entrada de los atacantes y cumplir con las normas reglamentarias.

Sin embargo, el «hardening» de imágenes ha evolucionado y puede tener diferentes significados en 2026. Algunas herramientas reconstruyen imágenes libres de CVE en sus propias distribuciones. Pero esto implica que hay que migrar todos los servicios a su base y volver a comprobar si se producen fallos, además de que quedas atado a la distribución y al ritmo de lanzamientos de ese proveedor. Otro enfoque consiste en aplicar parches a la imagen que ya estás ejecutando, de modo que mantienes la misma distribución y versión principal y evitas la migración.

Esta publicación compara las mejores herramientas para el endurecimiento de imágenes en 2026 en función de cómo las refuerzan, el riesgo de migración y cambios incompatibles (breaking changes), la velocidad de remediación y cómo se integran en el resto de tu flujo de trabajo de seguridad. Comparamos:

• Aikido Security
• Chainguard
• Docker Hardened Images
• Rapidfort
• Echo
• Minimus
• Wiz

TL;DR

Aikido Security es nuestra principal elección. En lugar de obligarte a cambiar a una nueva distribución, parchea la imagen base que ya utilizas, por lo que no hay migración ni cambios incompatibles. Los parches se aplican mediante una pull request de autofix que revisas y fusionas una sola vez. A partir de ahí, Aikido sigue reconstruyendo la imagen a medida que se parchean nuevas vulnerabilidades y te avisa cuando hay una compilación más reciente disponible. Aikido también sigue parcheando versiones después de que alcanzan su fin de vida útil (end-of-life), para que puedas mantenerte en una base anterior sin arrastrar sus CVE críticas y altas conocidas. Aikido Intel amplía la cobertura más allá de las bases de datos públicas, señalando vulnerabilidades que se parchearon silenciosamente en el upstream pero a las que nunca se les asignó un CVE. Cada imagen es un reemplazo directo (drop-in) con un SBOM, VEX y procedencia SLSA, cubriendo CVE a nivel de sistema operativo bajo un SLA de creación de parches definido, todo ello dentro de una plataforma que también abarca SAST, DAST, SCA, detección de secretos y postura en la nube.

{{cta}}

¿Qué es el endurecimiento de imágenes de contenedores?

Una imagen base de contenedores es la capa inicial fundamental para un contenedor. Una imagen pública estándar generalmente incluye gestores de paquetes, shells, compiladores y herramientas de depuración para que funcione para todos, pero es probable que tu aplicación no necesite la mayor parte de esto. 

El endurecimiento consiste en eliminar el software que la carga de trabajo nunca utiliza (lo que elimina clases enteros de vulnerabilidades junto con los paquetes) y asegurar lo que queda con versiones parcheadas, valores predeterminados seguros, ejecución sin privilegios de root y configuraciones alineadas con CIS/STIG.

El resultado es una imagen más pequeña y limpia que comienza siendo segura y se mantiene así a medida que se descubren y parchean las vulnerabilidades ascendentes. Las imágenes endurecidas también generan evidencia de auditoría como SBOM firmadas, procedencia de compilación, declaraciones VEX y firmas de cumplimiento.

Limitaciones comunes de las herramientas de endurecimiento de imágenes

La mayoría de las herramientas de endurecimiento de imágenes te obligan a abandonar la base que ejecutas hoy y adoptar su catálogo, para luego depender de su ritmo de actualización mientras la utilices. Ese diseño tiene costes. La adopción implica una migración, y cualquier elemento que el proveedor haya eliminado del que tu aplicación dependiera silenciosamente puede romperse. Mantener los parches al día significa avanzar hacia cada nuevo resumen (digest), por lo que cada solución es una imagen nueva que se debe probar y, bajo el control de cambios, volver a aprobar. Fijar un resumen para obtener estabilidad significa renunciar precisamente a los parches para cuya obtención adoptaste la herramienta. 

También se aplican un par de límites a las imágenes endurecidas en general. Eliminar los paquetes que una carga de trabajo nunca usa elimina las vulnerabilidades, pero una CVE en un paquete que realmente necesitas sigue requiriendo un parche real para solucionarse. Y cualquier recompilación puede alterar el comportamiento del que dependía tu compilación, razón por la cual cambiar de imágenes siempre conlleva una ronda de pruebas.

La alternativa es parchear la base que ya ejecutas, manteniendo tu distribución y versión principal en su lugar y el código abierto bajo tu aplicación accesible. No hay ningún catálogo de proveedores al que migrar ni ninguna necesidad de reestructurar la plataforma. 

Qué buscar en una herramienta de endurecimiento de imágenes

No todas las herramientas que ofrecen "endurecimiento de imágenes" realizan la misma función. Debes buscar estas características antes de tomar una decisión.

• Un gran catálogo preparado: ¿Para cuántas de las bases que ejecutas actualmente ofrece versiones endurecidas? Busca una amplitud real en distribuciones como Debian, Ubuntu y Alpine, compatibilidad con amd64 y arm64, y un catálogo que se mantenga activamente.
• Procedencia verificable: Esto significa una SBOM firmada (lista de materiales de software, el inventario completo de lo que hay en la imagen), un documento VEX (intercambio de explotabilidad de vulnerabilidades, que registra las CVE que en realidad no te afectan) y procedencia SLSA (un estándar que certifica cómo y dónde se construyó la imagen) adjuntos a cada extracción. 
• Seguridad posterior al fin de vida útil (EOL): Busca parches que continúen después de que la distribución ascendente haya avanzado, para que puedas mantenerte en una base anterior sin aceptar sus vulnerabilidades críticas y altas conocidas.
• Inteligencia de remediación: ¿La herramienta solo detecta vulnerabilidades a las que se les ha asignado una CVE? Con el paso del NIST a un modelo basado en riesgos en 2026, una parte creciente de las vulnerabilidades reales no recibirá una CVE a tiempo, y algunas no la recibirán nunca. Cualquier herramienta conectada únicamente a fuentes públicas de CVE hereda esos puntos ciegos. 
• Cumple con los estándares de cumplimiento: Estos esperan imágenes minimizadas y procedencia documentada. Comprueba que la herramienta genere esa evidencia de forma automática.

Mejores herramientas de endurecimiento de imágenes en 2026

Aikido Security

Aikido Images parchea la imagen base que ya utilizas en lugar de obligarte a migrar a una nueva, lo que significa que no hay cambios rupturistas. Aikido Images es un registro de más de 2000 imágenes de reemplazo directo donde las vulnerabilidades CRÍTICAS y ALTAS conocidas en la base ya han sido parcheadas. Esas imágenes se recompilan, parchean, minimizan y endurecen durante la compilación, por lo que obtienes el tratamiento completo, una superficie de ataque más pequeña y valores predeterminados seguros, sobre la base que ya ejecutas.

Para ejemplo, debian:bookworm proporciona un parche glib2.0 para la CVE-2025-4373, que Debian solucionó en Trixie/Sid pero no en Bookworm. La variante de Aikido Images de debian:bookworm contiene una versión parcheada de glib2.0 que soluciona esta vulnerabilidad. 

Dado que el intercambio es un reemplazo directo que AutoFix propone como una pull request, la corrección se aplica en el momento en que realizas el merge en lugar de al final de un ciclo de pruebas y migración, y cada descarga de docker.aikido.io incluye un SBOM, VEX y procedencia SLSA. Aikido sigue parcheando versiones después de que el proveedor upstream las haya abandonado, incluso aquellas que han llegado al fin de su vida útil (end-of-life), para que puedas mantenerte en una base anterior sin arrastrar sus fallos de seguridad conocidos y sin que se te obligue a actualizar a una versión más nueva para seguir cubierto.

Aikido también compila sus imágenes a partir de código abierto estándar (los mismos paquetes upstream que distribuye la propia distro), mientras que varias de estas herramientas recompilan todo desde su propio código fuente o mediante una distribución propietaria.

Un porcentaje cada vez mayor de correcciones reales nunca recibe un CVE. La monitorización continua de Aikido se alimenta, en parte, de Aikido Intel, que lee los registros de cambios (changelogs) y el historial de commits de upstream para detectar vulnerabilidades que se parchearon silenciosamente sin contar con uno. Y mientras que la mayoría de estas herramientas solucionan un CVE actualizando el paquete afectado a una versión más reciente, Aikido hace un uso intensivo de parches retro portados (backports), tomando la solución de la versión más nueva y aplicándola a la que ya estás ejecutando. Esto mantiene el cambio pequeño, por lo que es más probable que la imagen se comporte como espera tu aplicación, reduciendo la deuda técnica de actualización que se acumula cuando se te empuja hacia nuevas versiones. 

Cuando un backport limpio no es posible, Aikido actualizará o recompilará el componente en su lugar. Aikido también mapea cada contenedor con la base de la que hereda y te indica el reemplazo que elimina la mayor cantidad de riesgo en toda la organización, con más de 100 parches investigados y probados diariamente y cobertura a nivel de sistema operativo bajo un SLA de creación de parches definido.

Las vulnerabilidades de paquetes a nivel de aplicación en ecosistemas como npm, PyPI, Maven y Go se parchean in situ a través de Aikido Libraries. Todo ello se integra en una plataforma madura de seguridad de software que también abarca SAST, DAST, SCA, detección de secretos, postura de la nube y escaneo de imágenes de contenedores, de modo que cualquier hallazgo en una imagen se presenta con el contexto de código y nube que lo rodea.

El equipo detrás de estas imágenes se unió a través de la adquisición de Root, la empresa responsable de SlimToolkit (anteriormente DockerSlim), una de las herramientas de endurecimiento (hardening) de imágenes de código abierto más utilizadas, con más de 23.000 estrellas en GitHub y una capacidad demostrada para minimizar imágenes hasta en 30 veces. La construcción y el endurecimiento de imágenes de contenedores es donde comenzó este equipo, y la herramienta sigue siendo gratuita y abierta para que cualquiera la utilice.

‍Ideal para: Equipos empresariales que desean eliminar vulnerabilidades críticas y altas de las imágenes base y dependencias que ya ejecutan, sin necesidad de migrar a una nueva distribución ni perseguir una actualización constante.

{{walkthrough}}

Chainguard

Chainguard reduce una imagen al mínimo y la recompila a partir de Wolfi, su propia distribución de Linux. Las imágenes endurecidas se entregan con SBOMs y firmas de Sigstore, se recompilan desde upstream y cuentan con un SLA de corrección publicado de 7 días para CVE críticos y 14 para el resto. Chainguard ofrece opciones para el cumplimiento federal, incluyendo variantes con validación FIPS, módulos criptográficos validados por el NIST y endurecimiento según las guías DISA STIG.

El coste es la migración y la dependencia del proveedor (lock-in). Adoptar Chainguard implica trasladar tus servicios a su catálogo y distribución Wolfi, y si tu aplicación depende de algo que Chainguard ha eliminado, dejará de funcionar. El modelo también te mantiene en un ciclo de actualizaciones continuas (rolling upgrade), por lo que cada parche representa una nueva imagen que requiere volver a probarse. Fijar una versión a un resumen (digest) específico para garantizar la reproducibilidad impide que los parches te lleguen por completo, lo que anula el motivo por el cual decidiste adoptarlo. 

Chainguard también descarta las versiones anteriores con bastante rapidez. Las versiones de paquetes que no son la más reciente se conservan durante unos 12 meses, y su cobertura de fin de vida útil (end-of-life) se limita a seis meses, aplicándose únicamente a los paquetes de dependencias subyacentes de una imagen y no al componente principal. El efecto es una presión constante para avanzar hacia versiones más recientes, lo que genera fricción en los equipos que prefieren mantener una versión estable.

Ideal para: Equipos que pueden comprometerse con la distribución y el ritmo de lanzamientos de un solo proveedor. No recomendado para equipos que necesitan conservar sus imágenes base y versiones o mantener una versión estable sin necesidad de reevaluaciones constantes.

Docker Hardened Images

El catálogo de imágenes endurecidas de Docker se lanzó en mayo de 2025 y pasó a ser de código abierto bajo la licencia Apache 2.0 en diciembre de 2025. DHI vale la pena para aquellos equipos que ya utilizan Docker Hub. Su objetivo es proporcionar imágenes base con una cantidad cercana a cero CVE, construidas sobre bases estándar de Alpine y Debian, e incluye SBOMs firmados, procedencia SLSA Build Level 3 y atestaciones VEX. DHI Select añade un SLA de 7 días para CVE críticos, además de variantes compatibles con FIPS y STIG. DHI Enterprise incorpora opciones de personalización, con ELS disponible como complemento de pago por hasta cinco años después del fin de vida útil de upstream.

Al ser una incorporación más reciente, el historial operativo de DHI en cargas de trabajo fuertemente reguladas es menor. Su catálogo es menos profundo que el de otras opciones de esta lista y no amplía su cobertura más allá de las imágenes de contenedores.

Ideal para: Equipos que prefieren adoptar imágenes endurecidas dentro de su flujo de trabajo actual en Docker, pero no para aquellos cuyas bases se encuentran fuera del catálogo de Docker, el cual sigue siendo más limitado en comparación con otras herramientas aquí mencionadas.

Rapidfort

RapidFort ofrece un catálogo de imágenes endurecidas construidas sobre distribuciones LTS estándar como Alpine, Debian, Ubuntu y Red Hat, en lugar de una distro de contenedores propietaria. Su oferta está muy orientada a cargas de trabajo federales y de defensa, incluyendo cumplimiento con FedRAMP, FISMA y CMMC. 

Además del catálogo, RapidFort ofrece perfiles de tiempo de ejecución (runtime profiling) para optimizar aún más las imágenes. Su perfilador observa qué paquetes y binarios se ejecutan realmente en producción, genera una Lista de Materiales en Tiempo de Ejecución (RBOM) y elimina todo aquello que no haya visto ejecutarse. Aunque esto puede reducir el tamaño de una imagen, la técnica es frágil, ya que el perfilador conserva únicamente lo que observa; cualquier elemento que no se active durante el perfilado se convierte en candidato a ser eliminado. Cualquier nueva función, dependencia o cambio de configuración requiere volver a perfilar y realizar pruebas antes del despliegue.

Ideal para: Contratistas federales, proveedores de defensa y equipos regulados que ya están comprometidos con el cumplimiento de FIPS y STIG. Sin embargo, aquellos equipos que opten por la optimización basada en perfiles de ejecución deben saber que es un método frágil y que requiere un nuevo perfilado cada vez que la aplicación cambie.

Echo

Echo es un nuevo competidor cuya propuesta es una fábrica de imágenes impulsada por IA que compila imágenes de contenedores a partir del código fuente, incluyendo únicamente los componentes que una aplicación realmente necesita. Sus agentes supervisan los canales de vulnerabilidades y regeneran las imágenes a medida que surgen nuevos CVE en upstream. Las imágenes resultantes aspiran a tener cero CVE y se distribuyen como reemplazos directos de las imágenes base estándar de Docker. Cuentan con validación FIPS y están alineadas con las normativas STIG para los equipos que lo requieran, posicionándose como una alternativa directa a Chainguard y Docker Hardened Images en el ámbito de las imágenes base recompiladas. 

El aspecto en el que Echo cuenta con menor respaldo es en su historial operativo en cuanto al pipeline de recompilación y parcheo impulsado por IA bajo cargas de trabajo reguladas y a escala de producción. 

Ideal para: Equipos que buscan una estrategia de imágenes base recompiladas. No obstante, los equipos deben sentirse cómodos evaluando a un proveedor en su ronda de financiación Serie A, que cuenta con un catálogo más reducido y un historial operativo más corto.

Minimus

Minimus fue fundada en octubre de 2022 por cofundadores que previamente crearon Twistlock (adquirida por Palo Alto Networks en 2019). El producto se lanzó públicamente en el evento RSAC en abril de 2025, por lo que su trayectoria en el mercado es aún muy reciente. Las imágenes de Minimus se construyen a partir del código fuente upstream incluyendo únicamente el software necesario para ejecutar una aplicación. Su pipeline supervisa proyectos de código abierto, recompila paquetes cuando los mantenedores publican nuevas versiones y distribuye imágenes actualizadas tras someterlas a pruebas y firmas automatizadas. Su catálogo publicado incluye más de 1.200 imágenes endurecidas y ofrecen compatibilidad con los estándares de cumplimiento FIPS, CIS, NIST y STIG.

Adoptar Minimus implica migrar tus servicios a sus imágenes y, dado que el modelo recompila desde upstream y lanza nuevas versiones en lugar de aplicar parches retro portados a la versión que has fijado, mantenerse al día requiere avanzar hacia cada nuevo resumen (digest). Cada corrección representa una nueva imagen que debe ser probada y aprobada, y fijar una versión por motivos de estabilidad impide la recepción de los parches. Su historial operativo también es breve, ya que el producto es público desde abril de 2025 y, al igual que otras opciones aquí descritas, se limita a la imagen base sin abarcar el resto de tu infraestructura.

Ideal para: Equipos que prefieren imágenes construidas desde el código fuente y que pueden operar un flujo de trabajo de recompilación y despliegue continuo que mantenga el ritmo de los nuevos digests. No recomendado para equipos que necesitan mantener una versión fija (pinned) y seguir recibiendo las correcciones de seguridad sin tener que actualizar y reevaluar todo en cada parche.

Wiz

Wiz se endurece a través de WizOS, su propio catálogo de imágenes base mínimas construidas a partir del código fuente y mantenidas con un recuento de CVE conocidos muy bajo, que se entregan con SBOMs y procedencia verificable, y un SLA de corrección de 7 días para las críticas y 14 para las altas y medias. Existen variantes con endurecimiento FIPS y STIG para cargas de trabajo reguladas. WizOS se integra dentro de la plataforma de seguridad en la nube de Wiz, de modo que una imagen base vulnerable aparece junto con las señales de la nube, el código y el runtime que la rodean, con recomendaciones para cambiar a un equivalente de WizOS, cumplimiento en el admission controller y actualizaciones con un solo clic en el IDE.

Los inconvenientes son el alcance y el modelo. Al igual que Chainguard, WizOS te obliga a migrar los servicios a las imágenes de Wiz en lugar de aplicar correcciones retroactivas (backporting) a la versión que ya ejecutas, por lo que cada solución implica una nueva imagen que probar y aprobar. El catálogo también es más reciente y reducido que el de los especialistas, ya que comenzó con imágenes enfocadas en Go y se ha ido expandiendo, por lo que no se garantiza un equivalente endurecido para tu base exacta. 

Ideal para: equipos que ya usan Wiz y que quieren que las imágenes base endurecidas aparezcan y se apliquen dentro de la misma plataforma que utilizan para la seguridad en la nube y en runtime. No es adecuado para equipos cuyas bases queden fuera del catálogo, aún en crecimiento, de WizOS.