Wolfi: la distribución base pensada para contenedores

Actualizado: 2026-05-03

Wolfi cumplió tres años en agosto de 2025 y es uno de esos proyectos de infraestructura silenciosa cuya influencia se nota más por donde aparece que por lo que dice de sí mismo. Naciendo como la base de las imágenes de contenedor de Chainguard, ha terminado siendo usado directamente por equipos que quieren controlar más su cadena de suministro sin depender del ritmo de Debian o de las peculiaridades de Alpine. He estado trabajando con Wolfi como base de imágenes para varios servicios durante los últimos seis meses y tengo una lectura sedimentada.

Puntos clave

• Wolfi es una distribución Linux sin kernel, diseñada exclusivamente para el espacio de usuario de contenedores.
• Usa glibc en lugar de musl, eliminando incompatibilidades sutiles con Python, numpy y bibliotecas nativas.
• Cada paquete se publica con SBOM en formato SPDX y firma Sigstore, sin trabajo manual adicional.
• La publicación continua elimina versiones congeladas: los parches de seguridad llegan en horas, no en meses.
• El coste de adopción es real: apk de Wolfi difiere de Alpine y hay fricción inicial para equipos acostumbrados a apt.

Qué es Wolfi en realidad

Wolfi se describe como una distribución Linux sin kernel. Esa frase parece paradójica hasta que entiendes el contexto: una imagen de contenedor nunca ejecuta su propio kernel porque usa el del anfitrión. Todo el espacio dedicado a kernel, módulos e iniciadores en una distribución tradicional es, para un contenedor, peso muerto. Wolfi elimina esa capa y se queda solo con lo que ejecuta un proceso en espacio de usuario: glibc, gestor de paquetes, bibliotecas y binarios.

Lo distintivo frente a Alpine es la elección de glibc como biblioteca estándar. Alpine usa musl, más compacto pero incompatible de formas sutiles con mucho software compilado para glibc. Esos casos de borde aparecen sobre todo en:

• Resolución DNS.
• Manejo de locales.
• Carga dinámica de módulos.
• Ruedas precompiladas de Python (numpy, pandas, pyarrow).

Wolfi compila todo con glibc y recupera la compatibilidad total con cualquier binario que funcione en Debian o Ubuntu, al coste de unos megabytes extra.

El gestor de paquetes es apk, el mismo que Alpine, pero con un repositorio propio construido y firmado por Chainguard. Los paquetes de Wolfi no son los de Alpine con otro nombre: son compilaciones nuevas desde el código fuente con opciones de hardening activadas por defecto, SBOM generado en cada paquete y publicación continua sin versión semántica congelada.

La publicación continua como decisión estructural

Debian publica una versión mayor cada dos años aproximadamente. Ubuntu, cada seis meses con versiones LTS cada dos años. Alpine, cada seis meses. Wolfi no tiene versiones numeradas: cada paquete se actualiza individualmente cuando hay versión nueva del software original, y el repositorio en su conjunto está siempre vigente.

Esta decisión tiene consecuencias en ambos sentidos:

• Ventaja: cuando OpenSSL publica una corrección de seguridad, el paquete de Wolfi se actualiza en horas y las imágenes reconstruidas desde esa base incorporan el arreglo inmediatamente. No hay vulnerabilidades antiguas arrastradas meses esperando la siguiente versión de la distribución.
• Desventaja: no hay puntos de referencia estables para reproducir una construcción. La misma Dockerfile que funcionaba ayer puede producir una imagen distinta hoy porque un paquete se ha actualizado.

Mi recomendación después de varios proyectos: anclar versiones explícitamente en el Dockerfile cuando la reproducibilidad importe, y aceptar la publicación continua cuando lo que importe sea estar al día.

SBOM y firma como primeros principios

Cada paquete de Wolfi se publica con su SBOM generado automáticamente en formato SPDX, que lista toda la cadena de dependencias de construcción. Las imágenes de Chainguard construidas sobre Wolfi heredan y agregan esos SBOMs, de modo que una imagen final trae documentación precisa de todo su contenido sin que tengas que generarla tú.

La firma también es nativa. El repositorio apk está firmado con claves públicas, y las imágenes se firman con Sigstore cosign. Esto permite verificar en tiempo de despliegue que una imagen viene del repositorio oficial y no ha sido alterada. Para quien está obligado por cumplimiento o por cliente a demostrar procedencia del software que ejecuta, Wolfi elimina una capa entera de trabajo manual.

En mi caso, he usado estos SBOMs para alimentar el escaneo de vulnerabilidades en el pipeline. La diferencia con imágenes Debian es notable: en Debian el SBOM generado a posteriori tiene lagunas en paquetes instalados vía pip, npm o go install, porque no pasan por apt. En Wolfi la base está tan bien documentada que el ruido en los reportes baja significativamente.

Comparativa práctica con Alpine y Debian slim

Para una aplicación Go estática la diferencia es trivial: Wolfi y Alpine producen imágenes de menos de 20 MB. Para una aplicación Python con bibliotecas compiladas, Alpine genera problemas que Wolfi no: numpy, pandas y pyarrow no tienen ruedas precompiladas para musl y obligan a compilar desde código fuente. En Wolfi las ruedas de glibc funcionan directamente.

Frente a Debian slim la comparación es distinta:

Donde Wolfi gana claramente es en el ritmo de publicación y en la calidad del SBOM, no en el tamaño puro. El precio de adoptar Wolfi es la familiaridad del equipo con apk; esa fricción desaparece en un mes pero existe.

Dónde no encaja

Wolfi no encaja bien en dos casos:

1. Aplicaciones con dependencias de paquetes Debian no portados. Cuando el sistema depende de un paquete específico de Ubuntu que Wolfi no empaqueta, reimportarlo desde código fuente es trabajo serio. Wolfi obliga a un ejercicio de inventario que a veces no compensa.
2. Equipos sin capacidad de mantener imágenes propias. Wolfi gana mucho cuando reconstruyes imágenes con regularidad y mantienes tu propio registro. Si el equipo depende de pull directo de una imagen pública, no ganas nada especial frente a usar una imagen oficial de Docker Hub bien elegida. El valor de Wolfi se manifiesta en el pipeline, no en el docker pull.

Cuándo compensa

La decisión de adoptar Wolfi depende de tu postura sobre cadena de suministro:

• Entornos regulados (cliente o auditor pide trazabilidad de cada binario): Wolfi ahorra semanas. El SBOM viene de serie, las firmas están ahí, el ritmo de publicación reduce la ventana de exposición y glibc evita los casos de borde de Alpine. Compensa desde el primer proyecto.
• Equipos pragmáticos (cadena no auditada, imágenes que se actualizan cada pocos meses): Wolfi no cambia la postura de seguridad de forma notable, y la inversión en migrar Dockerfiles y formar al equipo en apk no se recupera fácilmente. Debian slim actualizado regularmente ofrece un balance razonable.

El punto medio donde yo me he quedado es usar Wolfi como base para servicios que publican imágenes hacia fuera o manejan datos sensibles, y mantener Debian slim para servicios internos donde la cadena de suministro no es un vector crítico. A medida que el equipo gana familiaridad, la frontera se mueve hacia más adopción como consolidación gradual, no como salto disruptivo.

Conclusión

Wolfi resuelve bien el triángulo glibc + SBOM nativo + parches rápidos que las distribuciones tradicionales no podían resolver juntos. No es la elección correcta para todo equipo, pero para quienes tienen presión de cumplimiento sobre la cadena de suministro o pipelines de reconstrucción nocturna, reduce trabajo real. La adopción incremental —empezando por los servicios más expuestos— es el camino más sensato.