Grundlage der Bauprozesse ist Chainguard OS, ein eigens entwickeltes Linux-Betriebssystem für cloud-native Workloads, das dem Unternehmen die vollständige Kontrolle über die Software-Lieferkette geben soll. Anders als etablierte Distributionen setzt es auf kontinuierliche Integration und Auslieferung sowie auf schnelle Nano-Updates und Neubauten. Statt eines Releases alle sechs Monate, das anschließend altert, verfolgt Chainguard OS ein Rolling-Release-Modell: Neue Artefakte gehen den ganzen Tag über raus.
Die Chainguard Factory ist die Infrastruktur, die diese Auslieferung antreibt. Jedes Artefakt wird aus dem Quellcode gebaut und trägt SLSA-Level-3-Provenance, Sigstore-Signaturen und vollständige SBOMs. Weil die Builds deklarativ und reproduzierbar sind, lässt sich ein Image neu erzeugen, ohne verstecktem Zustand oder einer Abweichung zwischen Soll und Ist nachjagen zu müssen.
Reproduzierbarkeit allein reicht laut Moore aber nicht für dieses Tempo. Entscheidend sei, zu wissen, wann neu gebaut werden muss, und dieses Signal sofort umzusetzen – über Tausende voneinander abhängige Projekte hinweg, ohne dass für jede Entscheidung ein Mensch eingreift.
Genau daran scheiterte die ursprüngliche Factory. Sie automatisierte zwar die Mechanik des Bauens – Paketdefinition einlesen, Abhängigkeiten auflösen, bauen, signieren, ausliefern –, war aber ein klassisches ereignisgetriebenes System. Mit wachsendem Katalog wurde daraus intern ein „kaskadierendes Chaos“: SREs versanken in Ereignismeldungen, Warteschlangen wurden brüchig, doppelte Build-Fehler und Konflikte bei Arbeitsaufträgen häuften sich. Sobald eine Aufgabe nur teilweise gelang oder auf Unvorhergesehenes traf, musste ein Mensch eingreifen. Moore beschreibt das Ergebnis als „CVE-Endlosschleife“: Die Infrastruktur kämpfte permanent gegen Konfigurationsabweichung und Verfall, statt ihnen zuvorzukommen.
Die Antwort darauf ist Factory 2.0 auf Basis von DriftlessAF – ein selbstkorrigierendes Bausystem, das eine agentische, KI-gestützte Abgleichsschicht über die bestehende deterministische Automatisierung legt. Die KI übernimmt dabei die operative Fleißarbeit: einfache Ermessensentscheidungen, detaillierte Triage und Tausende kleiner Entscheidungen, die zuvor den Engpass für die Neubau-Geschwindigkeit bildeten.
Moore begründet das mit einem veränderten Bedrohungsmodell: Angreifer nutzten dieselben KfI-Werkzeuge zunehmend für das Auffinden von Schwachstellen, das Erstellen von Exploits und das Verketten komplexer Angriffsketten. KI könne Abhängigkeitsgraphen durchsuchen, Schwächen verketten und einen funktionierenden Exploit deutlich schneller erzeugen als ein menschlicher Angreifer. Verkürze sich die Zykluszeit des Angreifers, müsse die des Verteidigers mindestens im selben Maß mitziehen. Jede Stunde zwischen einer Änderung stromaufwärts und einem neu gebauten, signierten und verifizierten Image, die eingespart werde, sei eine Stunde weniger für Angreifer.
Durch den agentischen Betrieb kann das Engineering-Team laut Chainguard als Fachinstanz für die Agenten auftreten, vorgeschlagene Änderungen abwägen und sich auf die Weiterentwicklung der Factory-Infrastruktur, die Qualität der Ergebnisse und den Umfang des Gebauten konzentrieren – darunter Chainguard Libraries, Chainguard Agent Skills und Chainguard Actions.
DriftlessAF, das quelloffene agentische Kernframework der Factory, soll weiter ausgebaut werden: mit mehr Abgleich-Bots, mehr Quellen, die die Arbeitswarteschlange speisen, und einem größeren Teil des Katalogs, der durch die selbstheilende Schleife statt über den alten ereignisgetriebenen Pfad läuft. Weil der Kern offen liegt, können andere Teams mit ähnlichen Automatisierungsproblemen darauf aufsetzen.