Mascota Jacar — leyendo contigo Un portátil cuyos ojos siguen el cursor mientras lees.
Tecnología

Chainguard Images: imágenes mínimas y firmadas

Chainguard Images: imágenes mínimas y firmadas

Actualizado: 2026-05-03

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 — cero CVEs conocidos, SBOMs firmados, reproducible builds. 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.
  • 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.

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:

dockerfile
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:

bash
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 35 MB
Go runtime 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.

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.

¿Te ha resultado útil?
[Total: 14 · Media: 4.2]
  1. Chainguard

Escrito por

CEO - Jacar Systems

Apasionado de la tecnología, la infraestructura cloud y la inteligencia artificial. Escribe sobre DevOps, IA, plataformas y software desde Madrid.