Chainguard[1] es la empresa de los creadores de Sigstore, enfocada en supply chain security práctica. Su producto principal son Chainguard Images: imágenes Docker construidas con rigor extremo, con cero CVEs conocidos, SBOMs firmados y reproducible builds de fábrica. Para empresas con compliance estricta o que quieren reducir superficie de ataque, son una alternativa seria a debian:latest o alpine:latest.

Puntos clave

  • Cero CVEs conocidos en el momento de publicación: las imágenes se reconstruyen diariamente.

  • SBOMs firmados con Sigstore/Cosign incluidos de fábrica: verificación criptográfica sin pasos adicionales.

  • Basadas en Wolfi, la propia distribución de Chainguard con glibc, lo que evita las incompatibilidades musl de Alpine.

  • El tier gratuito cubre las imágenes latest más populares; versiones pinned y soporte SLA son enterprise.

  • Distroless sin shell es la variante de producción; la variante -dev añade herramientas de build para multi-stage.

Qué ofrecen

Cada imagen Chainguard tiene características diferenciadas frente a las imágenes oficiales de Docker Hub:

  • Mínima: solo lo necesario para ejecutar la aplicación. Sin bash, sin package manager, sin utilitarios de debugging que amplíen la superficie de ataque.

  • Cero CVEs conocidos: reconstruidas diariamente; cuando aparece una vulnerabilidad el fix llega en horas, no en meses. Esto complementa (no sustituye) el escaneo continuo con herramientas como Trivy o Grype.

  • Firmadas con Sigstore: cualquier sistema de CI puede verificar la firma antes de usar la imagen.

  • SBOMs automáticos y firmados: sabes exactamente qué paquetes están dentro y en qué versión.

  • Reproducible builds: dado el mismo input, el hash de salida es determinista, en línea con los niveles de procedencia que define SLSA.

Uso típico: multi-stage Dockerfile

El patrón más común combina la variante -dev para build y la runtime para producción:

FROM cgr.dev/chainguard/node:latest-dev AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM cgr.dev/chainguard/node:latest
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/index.js"]

El resultado: ~100 MB en runtime frente a ~200-300 MB del Node oficial. Sin shell, sin npm, sin wget, sin curl en producción.

Verificación con cosign

Cualquiera puede verificar la procedencia de la imagen:

cosign verify cgr.dev/chainguard/node:latest 
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com 
  --certificate-identity-regexp='.*chainguard.*'

Esta verificación criptográfica cierra el bucle entre quién construyó la imagen y qué pipeline usó. Es compatible con las políticas de admission control de Kubernetes via Kyverno o Gatekeeper. Para integrar esta verificación en el pipeline completo, ver también devsecops con Sigstore y cosign.

Comparativa de tamaños

Stack Oficial Alpine Distroless Chainguard
Node 20 1,1 GB 180 MB 180 MB 170 MB
Python 3.12 1 GB 170 MB 200 MB 170 MB
nginx 187 MB 40 MB N/D 35 MB
Go runtime N/D N/D 70 MB 50 MB

Tamaño comparable a Distroless de Google, pero con CVE management activo diario y SBOMs incluidos.

Chainguard frente a Alpine

Aspecto Chainguard Alpine
Sistema base Wolfi (glibc) musl + BusyBox
CVE management Proactivo, diario Comunidad
SBOMs Incluidos, firmados No nativo
Compatibilidad glibc total musl (puede romper)

Alpine usa musl libc que ocasionalmente causa incompatibilidades sutiles con apps diseñadas para glibc: problemas de DNS resolution, locale handling, comportamiento de threading. Chainguard usa Wolfi con glibc estándar, lo que elimina esa clase de incidentes.

Cuándo tiene sentido adoptar Chainguard

Tiene sentido adoptar cuando:

  • La organización tiene compliance estricta (PCI-DSS, HIPAA, FedRAMP) y necesita pipelines auditables.

  • Supply chain security es una prioridad alta en el roadmap de seguridad.

  • La reducción de CVEs es una métrica de reporting ESG o de auditoría.

  • Los workloads en producción manejan datos sensibles donde el blast radius de un compromise importa.

Tiene menos sentido cuando:

  • Son proyectos personales o experimentación donde el overhead no se justifica.

  • La app tiene dependencias legacy específicas de glibc no cubiertas en el catálogo Wolfi.

  • El equipo no tiene capacidad de gestionar el ciclo de vida de imágenes pinned.

Precio y tiers

El tier público gratuito cubre las imágenes latest de los stacks más populares con actualizaciones diarias. El tier enterprise añade:

  • Imágenes con versión pinned (cgr.dev/chainguard/node:20).

  • Soporte con SLA.

  • Imágenes custom para stacks internos.

  • Variantes certificadas FIPS para entornos de gobierno.

Para la mayoría de equipos, el tier gratuito es suficiente para empezar y evaluar el impacto en el CVE count.

Este artículo también está disponible en inglés.

Conclusión

Chainguard Images representan la dirección donde va el ecosistema de contenedores enterprise: mínimo, firmado, actualizable, auditable. Para empresas con compliance o que valoran supply chain security serio, el coste de migrar se recupera rápidamente en reducción de trabajo de auditoría y en métricas de riesgo. El tier público gratuito permite evaluar sin compromiso. Contra las imágenes oficiales "latest" de Docker Hub, la diferencia en CVE count y en perfil de riesgo es tangible desde el primer escaneo.

Fuentes:

  1. Chainguard: documentación de Chainguard Images[2]
  2. Wolfi OS: repositorio de paquetes en GitHub[3]
  3. SLSA: niveles de procedencia para la cadena de suministro de software[4]

Preguntas frecuentes

¿Cómo depuro un contenedor Chainguard si la imagen no tiene shell?

No lo haces dentro de la imagen de producción, que por diseño no lleva bash, package manager ni utilitarios como wget o curl. El patrón es un Dockerfile multi-stage: la variante -dev (por ejemplo cgr.dev/chainguard/node:latest-dev) incluye las herramientas de build y sirve para compilar, y la imagen runtime cgr.dev/chainguard/node:latest solo recibe los artefactos. El resultado ronda los 100 MB frente a 200-300 MB del Node oficial.

¿Puedo usar Chainguard Images gratis en producción?

Sí, con matices. El tier público gratuito cubre las imágenes latest de los stacks más populares con reconstrucción diaria, suficiente para empezar y medir el impacto en el CVE count. Las imágenes con versión pinned como cgr.dev/chainguard/node:20, el soporte con SLA, las imágenes custom para stacks internos y las variantes certificadas FIPS son del tier enterprise. Si tu equipo no puede gestionar el ciclo de vida de imágenes pinned, el gratuito puede ser limitante.

¿Qué ventaja tiene Chainguard sobre Alpine si ambas son imágenes mínimas?

La libc y el CVE management. Alpine usa musl y BusyBox, y musl causa ocasionalmente incompatibilidades sutiles con aplicaciones diseñadas para glibc: resolución DNS, locales o threading. Chainguard se basa en Wolfi con glibc estándar, lo que elimina esa clase de incidentes. Además, las imágenes se reconstruyen a diario con fixes en horas, incluyen SBOMs firmados con Sigstore/Cosign y son reproducibles, mientras que en Alpine el CVE management depende de la comunidad.

Fuentes

  1. Chainguard
  2. Chainguard: documentación de Chainguard Images
  3. Wolfi OS: repositorio de paquetes en GitHub
  4. SLSA: niveles de procedencia para la cadena de suministro de software