A Billion Build Manifests
On September 3, 2026, container security vendor Chainguard announced it had surpassed 1 billion unique container build manifests — the artifacts generated every time an image in its catalog is built, updated, or patched. That's double the 500 million manifests the company had produced just six months earlier.
What's Behind the Numbers
Alongside the manifest count, Chainguard's catalog has grown to:
- 3,000+ unique container images covering widely used runtimes and frameworks — Go, NGINX, PostgreSQL, Python, Java, and more
- 675,000+ image versions, driven largely by architecture-specific builds
Each build manifest represents a distinct, verifiable artifact: a fresh application image, a package rebuilt after a libc patch, an architecture-specific variant, or a regenerated software bill of materials (SBOM) following a dependency update. For projects that support multiple versions and architectures — Python and Go being prime examples — a single upstream release, dependency fix, or security advisory can trigger a cascade of rebuilds.
The Engine: Factory 2.0
Chainguard Factory builds container artifacts directly from source and attaches security metadata — SLSA Level 3 provenance, Sigstore signatures, and complete SBOMs — while aiming for reproducible builds that reduce configuration drift. But reproducibility alone doesn't scale to a billion manifests. Chainguard needed a system that could automatically identify which of thousands of dependent components required remediation and kick off rebuilds without manual intervention.
That system is Factory 2.0, built on Chainguard's open-source DriftlessAF framework, which handles the dependency-graph analysis and automated triggering behind the scale-up.
Why It Matters
Chainguard frames the milestone as evidence that its automated software factory is keeping pace with how fast software supply chain attacks are evolving — particularly as AI-assisted tooling accelerates both attack and defense timelines. The underlying goal: ensure container images stay current with patches and provenance data well beyond the moment a customer first pulls them, rather than going stale the day after release.
Takeaways for Security Teams
- Evaluate whether current base-image pipelines rebuild automatically on upstream CVE disclosure, or rely on manual patch cycles
- Check that pulled container images carry SLSA provenance and SBOMs, not just a vendor's word on patch status
- Factor rebuild cadence into vendor risk assessments for any hardened/minimal container image supplier