Chainguard heeft de afgelopen zes maanden een indrukwekkende mijlpaal gehaald: het aantal build manifests is in die periode gestegen van 500 miljoen naar meer dan 1 miljard. Maar volgens het bedrijf is de echte winst niet alleen de teller zelf; het draait om het systeem dat die hoeveelheid bouwoutput überhaupt mogelijk maakt — en waarom het ontwerp volledig is omgegooid.
In dit artikel zoomen we in op wat een build manifest precies betekent, hoe Chainguard zijn leveringsproces vormgeeft en waarom een snelle, doorlopende rebuildcyclus steeds belangrijker wordt in een wereld waarin aanvallers ook sneller itereren.
Wat zijn build manifests, en wat tel je dan echt?
Om misverstanden te voorkomen, wordt eerst scherp gedefinieerd wat Chainguard telt als een build manifest. In de kern is het een registratie van elke keer dat de Factory een nieuw, verifieerbaar software-artifact produceert. Dat kan een verse container image zijn, maar ook een rebuild die wordt getriggerd door iets dat upstream verandert.
Voorbeelden uit de beschrijving zijn onder meer:
- een nieuwe image voor een specifieke Go-versie, zoals go:1.26.5;
- een rebuild van een bestaande component (zoals nginx) wanneer een onderliggende library of patch (bijvoorbeeld libc) wijzigingen doorvoert;
- varianten voor een andere hardware-architectuur;
- een opnieuw gegenereerde SBOM nadat een dependency is aangepast.
Op catalogusniveau betekent dit dat een project, zoals Python, vaak meerdere ondersteunde versies en architectuurvarianten heeft. Daarnaast ontstaan er doorlopende rebuilds wanneer leveranciersupdates, security patches of aanvullende verhardingsmaatregelen doorwerken. De telling laat dan zien dat de hele set artifacts “vers” blijft gedurende de tijd dat klanten images ophalen en gebruiken.
Van ‘veilig op de dag van ophalen’ naar ‘veilig elke dag’
Het verschil dat Chainguard benadrukt, is opvallend. Veel beveiligingsbeheer kijkt primair naar de situatie op het moment dat iemand een image downloadt. Dat is nuttig, maar het dekt niet volledig wat er gebeurt tussen die momenten in.
Chainguard positioneert zijn aanpak als: niet alleen zorgen dat een catalogus veilig is wanneer je hem opent, maar dat de catalogus continu blijft aansluiten op nieuwe patches, wijzigingen in dependencies en actuele security-inzichten. Met andere woorden: de catalogus moet blijven meebewegen met de werkelijkheid in plaats van te wachten tot de volgende cyclus.
Chainguard OS en de regie over de software supply chain
Volgens de beschrijving begint alles bij Chainguard OS, een besturingssysteem dat is ontworpen voor moderne cloud-native workloads. Het bedrijf stelt dat het hiermee volledige controle wil hebben over de software supply chain.
In de uitleg wordt het contrast gemaakt met meer traditionele Linux-distributies die werken met periodieke release-cycli. Chainguard OS werkt volgens een rolling release model: nieuwe artifacts kunnen de hele dag door verschepen worden, in plaats van te wachten tot een vast moment. Ook wordt genoemd dat het systeem is gericht op snelle nano-updates en rebuilds.
Chainguard geeft aan updates te benutten die in de open-source community ontstaan, en die zo snel mogelijk te leveren aan klanten. Daardoor ontstaat er minder tijd waarin een catalogus achterloopt op upstream wijzigingen.
Factory en verifieerbare output: SLSA, Sigstore en SBOM’s
De Chainguard Factory fungeert als de infrastructuur en “engine” achter de levering. De output wordt volgens de bron beschreven als gebouwd met lagen van beveiliging en met herleidbare herkomstdata.
Concreet wordt genoemd dat artifacts worden gebouwd uit broncode en daarbij gebruikmaken van:
- SLSA Level 3 provenance om de herkomst en betrouwbaarheid van build-stappen te onderbouwen;
- Sigstore signatures om te zorgen voor ondertekende verificatie;
- volledige SBOM’s (Software Bill of Materials) voor inzicht in dependencies en componenten.
Een belangrijk praktisch voordeel dat wordt genoemd is reproducibility: omdat builds declaratief en reproduceerbaar zijn, kan Chainguard volgens de tekst afbeeldingen regenereren zonder te hoeven vertrouwen op “verborgen state” of drift. Dat helpt om te voorkomen dat wat bedoeld was om te leveren, afwijkt van wat uiteindelijk is geproduceerd.
Waarom Factory 2.0 nodig was: het oude model liep vast
De eerste versie van de Factory automatiseerde vooral de bouwmechanica: een package definition, dependency-resolving, bouwen, signeren en verschepen. Maar naarmate de catalogus groter werd, werd het oorspronkelijke event-driven ontwerp volgens het bedrijf steeds moeilijker beheersbaar.
Chainguard beschrijft dit intern als een “cascading mess”. SRE’s zouden verdrinken in eventmeldingen, wachtrijen groeiden en werden kwetsbaar, en duplicate build failures of conflicten kwamen vaker voor. Daarnaast moest bij gedeeltelijke mislukking of onverwachte situaties vaak alsnog een mens ingrijpen.
Daar komt nog een tweede pijnpunt bij: de zogenoemde “CVE doom loop”. Het idee is dat de infrastructuur niet alleen bezig is met vooruitgaan, maar constant moet reageren op drift en decay. Daardoor blijft er een permanente spanningsboog tussen het bijhouden van security en het herstellen van veroudering in plaats van continu te verbeteren.
DriftlessAF: zelfcorrigerend bouwen met een continue reconciliatielus
Factory 2.0 draait volgens de bron om DriftlessAF (een self-correcting build-systeem). Het combineert deterministische automation met een reconciliatie-achtige laag die agentic en AI-gedreven is.
De kern zit in een set concrete bouwblokken:
- Reconciliation loop: in plaats van te reageren op losse gebeurtenissen vergelijkt het systeem een gewenst eindresultaat met de werkelijke toestand. Zodra er bijvoorbeeld een CVE wordt gemeld, een upstream versie verandert of een nieuwe best practice wordt gedefinieerd, probeert het de kloof te dichten.
- Continu werkqueue: veel reconciler-bots krijgen continu taken toegewezen vanuit een gedeelde queue. Ze halen informatie uit code-repositories, security feeds en andere bronnen om naar de gewenste target state te werken.
- Redundant by design: omdat de bots werken richting een gedefinieerd eindpunt, is één mislukte taak minder kritisch. Het systeem kan een faalrun droppen of opnieuw proberen; uiteindelijk convergeert het op het juiste resultaat.
- AI op plekken waar het logisch is: de bots gebruiken AI specifiek voor “ongestructureerde” oordeelsmomenten die traditionele automatisering niet goed kon vastpakken. Denk aan het redeneren over een nieuw component in een minor release of het backporten van een CVE-remediatie naar oudere packages of language releases.
Volgens de tekst blijft de loop tegelijk verifieerbaar: de bots werken met gestructureerde, aantoonbare tooling zodat het systeem niet “op gevoel” kan besluiten. Daarnaast wordt genoemd dat het systeem leert van eerdere succesvolle patch-gevallen, bijvoorbeeld wanneer een oudere library versie door een backport-test komt. Die kennis kan later helpen bij vergelijkbare aanpassingen.
Het uiteindelijke doel is helder: AI moet vooral de operationele last absorberen. Chainguard benoemt daarbij expliciet de tijdrovende, menselijke triage en de duizenden kleine besluitmomenten die rebuild-velocity vroeger zouden vertragen.
Waarom snelheid zo’n groot beveiligingsverschil maakt
De bron legt uit dat het dreigingsmodel veranderd is. Aanvallers gebruiken steeds vaker dezelfde AI-achtige capaciteiten voor zaken als kwetsbaarheidsonderzoek, exploitontwikkeling en het combineren van zwakheden tot een bruikbare keten.
Als aanvallers hun cyclus verkorten, moet de verdediging minstens zo snel mee. In dit verhaal is rebuild speed daarom geen technische luxe, maar een directe security parameter. Elke verkorting tussen een upstream verandering en een opnieuw gebouwde, ondertekende en geverifieerde image betekent volgens Chainguard minder tijd waarin een aanvaller kan proberen met bekende zwakheden.
Het feit dat de output van 500 miljoen naar 1 miljard build manifests in zes maanden gaat, wordt in de uitleg gezien als bewijs dat de reconciliatielus kan opschalen naar tempo dat realistisch kan blijven in een agressief veranderend landschap.
Wat dit betekent voor teams en voor de volgende stap
Naast de snelheid benoemt de beschrijving ook dat agentic automatisering de engineeringteams niet vervangt, maar anders positioneert. De bron stelt dat engineers de agents als experts kunnen aansturen, voorgestelde wijzigingen kunnen arbitreëren en zich kunnen focussen op verbeteringen aan de Factory, de kwaliteit van output en de bredere scope van wat er wordt gebouwd en onderhouden.
Voor de toekomst geeft Chainguard aan niet te willen vertragen. Er wordt gewerkt aan verdere uitbreiding van DriftlessAF: meer reconciler bots, meer bronnen die de work queue voeden en meer van de catalogus die via de zelf-healing loop draait in plaats van de oude event-driven route.
Daarnaast wordt genoemd dat de kern van DriftlessAF open source is. Dat biedt andere teams volgens de tekst de mogelijkheid om te profiteren van wat is geleerd, in plaats van opnieuw vanaf nul te beginnen met vergelijkbare schaalproblemen.
Praktische blik: waar je de catalogus en de aanpak kunt bekijken
Chainguard verwijst naar de container image catalog als plek om te zien wat er momenteel in de catalogus zit. Voor wie vooral geïnteresseerd is in de onderliggende automatiseringslogica, noemt het bedrijf ook DriftlessAF met documentatie en aanvullende resources.
Voor organisaties die worstelen met de beveiliging van container-ecosystemen en de snelheid waarmee updates moeten doorwerken, is de boodschap in de bron eenvoudig: als je build- en rebuildprocessen op grote schaal niet continu kunt bijsturen, ontstaat er al snel achterstand. Met een reconciliatiegedreven systeem en verifieerbare artifacts probeert Chainguard precies dat gat te verkleinen.
Conclusie
Chainguard’s sprong naar meer dan 1 miljard build manifests laat zien hoe ver build- en security-automatisering kan opschalen wanneer je niet alleen bouwt, maar ook voortdurend reconciliëert. Door Factory 2.0 en DriftlessAF te bouwen rondom een gewenste versus werkelijke toestand, wordt het mogelijk om sneller te rebuilden en zo de catalogus structureel actueel te houden.
In een tijd waarin aanvallers hun doorlooptijd verkorten, is die snelheid volgens de bron een directe veiligheidsfactor. De volgende uitdaging is nu vooral: die aanpak verder opschalen, de zelfcorrigerende loop uitbreiden en de kennis breder beschikbaar maken voor teams met vergelijkbare schaal en supply chain complexiteit.
Gerelateerd lezen: als je wilt begrijpen hoe aanvallers via kwetsbaarheden of zero-days snel kunnen profiteren van vertraagde patches, bekijk dan ook het overzicht over zero-day exploits bij Avast, CrowdStrike en Nvidia. Voor een kijkje in het belang van snelle hotfixes in netwerk- en managementsystemen is de N-central zero-day patch (CVE-2026-86218) eveneens relevant.
Bron: https://thehackernews.com/2026/09/what-it-took-to-reach-1-billion-build.html
