Chainguard has surpassed 1 billion container build manifests, doubling production from 500 million in six months as it expands its AI-assisted software supply-chain security platform.
The company now maintains more than 3,000 unique container images and 675,000 image versions. The milestone reflects more than raw build volume.
Each build manifest represents a newly generated, verifiable container artifact, including fresh application images, rebuilt packages following a libc patch, architecture-specific variants, or regenerated software bills of materials (SBOMs) after a dependency update.
For projects with multiple supported versions and architectures, such as Python or Go, these rebuilds can multiply rapidly. Every upstream release, dependency fix, hardening improvement, or security advisory can trigger new builds.
Chainguard Hits 1 Billion Build Manifests
Chainguard said the approach is intended to ensure container images remain secure beyond the moment they are initially pulled by customers. At the foundation of the platform is Chainguard OS, a Linux distribution designed for cloud-native workloads and continuous delivery.
Rather than relying on traditional long-lived distribution releases, Chainguard OS uses a rolling-release model that enables updated artifacts to be shipped throughout the day.
Chainguard Factory builds the company’s container artifacts from source and attaches security metadata, including SLSA Level 3 provenance, Sigstore signatures, and complete SBOMs.
The factory is designed to generate reproducible builds, reducing the risk of configuration drift or inconsistencies between the intended artifact and the image ultimately delivered to users.
However, reproducibility alone could not support rebuilds at billion-manifest scale. The company needed a system capable of identifying when thousands of dependent components required remediation and initiating builds without relying on manual intervention.
Chainguard addressed that challenge with Factory 2.0, powered by its open-source DriftlessAF framework. The system replaces a largely event-driven model with a self-correcting reconciliation process.
Under the previous architecture, individual events could generate cascading work items, duplicate build failures, brittle queues, and operational overhead for site reliability engineers.
Partial failures often required manual remediation, slowing down the response to CVEs and other package changes. Factory 2.0 instead continuously compares the intended software state with the catalog’s actual state.
When a new vulnerability, upstream package release, dependency update, or security requirement appears, reconciler bots identify the difference and work toward restoring the desired state.
The system uses a shared work queue and redundant tasks, meaning failed jobs can be retried or discarded without preventing the overall platform from converging on the intended secure outcome.
AI is used for tasks that traditional deterministic automation struggles to handle, including evaluating newly introduced components, assessing package changes, and backporting vulnerability fixes to older software versions.
Chainguard said the agents still operate through structured and verifiable tooling to reduce the risk of unsafe AI-generated changes. The company argues that rebuild velocity is now central to supply-chain defense.
Attackers can increasingly use AI to map dependency graphs, identify weaknesses, and accelerate the development of exploits. Defenders therefore need to reduce the time between an upstream security change and a newly rebuilt, signed, and verified container image.
By expanding DriftlessAF and moving more of its catalog into self-healing reconciliation loops, Chainguard aims to automate security maintenance at a scale that traditional event-driven build systems struggle to achieve.
Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.
