Chainguard alcanza mil millones de build manifests con Factory 2.0 y su motor de IA DriftlessAF

Mil millones de build manifests

Chainguard ha duplicado en seis meses su producción de manifiestos de build hasta superar los mil millones. También ha pasado de 500 millones a más de 1.000 millones, y su catálogo incluye ahora más de 3.000 imágenes de contenedor y 675.000 versiones. La compañía lo celebra y explica qué ha cambiado en su infraestructura para que un crecimiento así fuera posible.

¿Qué es exactamente un build manifest?

Cada vez que Chainguard Factory produce un artefacto verificable cuenta como un build manifest. Por ejemplo, una nueva imagen para go:1.26.5, una reconstrucción de nginx por un parche en libc, una arquitectura adicional o un SBOM regenerado tras un cambio de dependencia.

La cantidad de versiones mantenidas por proyecto es enorme: Python, por ejemplo, tiene decenas de versiones, cada una para varias arquitecturas, y cada una se reconstruye continuamente según cambian las dependencias o las políticas de hardening. La idea es que el catálogo no se quede obsoleto: un pull de hoy es seguro hoy y mañana también.

Chainguard OS y Factory: cómo se construye

Todo empieza con Chainguard OS, una distribución Linux creada para cargas cloud-native y con un modelo de rolling release. En lugar de lanzar un release cada seis meses y dejarlo envejecer, los artefactos se generan a diario, con firma Sigstore, SBOM completo y provenance SLSA nivel 3.

El primer intento de automatizar todo esto fue Factory, pero su arquitectura basada en eventos acabó generando lo que llaman internamente un "cascading mess": los SRE se ahogaban en notificaciones, las colas se volvían frágiles y abundaban los fallos duplicados y los conflictos entre tareas. El sistema se pasaba más tiempo apagando fuegos que avanzando.

Factory 2.0 y DriftlessAF

Factory 2.0 introduce un motor llamado DriftlessAF, disponible como proyecto open source. En lugar de reaccionar a eventos, es un bucle de reconciliación continuo: compara el estado deseado con el real y trabaja para cerrar la brecha cuando aparece una CVE, un paquete nuevo o un nuevo criterio interno.

El trabajo se organiza en una cola continua que reparten decenas de robots reconciliadores. Como cada tarea busca un estado final definido, cualquier fallo se puede reintentar sin consecuencias: el sistema converge al objetivo sí o sí.

La IA entra donde hace falta juicio: razonar si un componente nuevo en una versión menor requiere un rebuild o decidir cómo portar un parche de CVE a una versión antigua de un lenguaje. Todo eso se hace con herramientas verificables para que la IA no pueda desviarse. Además, el motor aprende de sus propios aciertos: si un port de parche funciona para una versión, lo aplica a otras parecidas.

Con este diseño, Chainguard dice haber eliminado el cuello de botella operativo que limitaba la velocidad de reconstrucción. Las cifras son suyas y no hay verificación externa, pero la arquitectura es lo suficientemente concreta como para merecer un vistazo.

Por qué importa

La velocidad ya no es solo una ventaja: es una necesidad si los atacantes usan IA para descubrir y explotar vulnerabilidades más rápido. Un catálogo que se reconstruye de forma continua, sin esperar a un release trimestral, es la diferencia entre una imagen segura el día que la descargas y una que lo sigue siendo durante toda su vida útil.