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
latestmás populares; versiones pinned y soporte SLA son enterprise. - Distroless sin shell es la variante de producción; la variante
-devañ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:
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 | — | 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.