In de afgelopen zes maanden heeft Chainguard zijn productie verdubbeld van 500 miljoen naar meer dan 1 miljard containerbuild-manifesten. We hebben ook de grens van 3.000 unieke containerafbeeldingen en 675.000 afbeeldingsversies in onze catalogus overschreden. Dat zijn de belangrijkste cijfers, maar ik wil delen wat er feitelijk achter zit. Het getal zelf is minder interessant dan het systeem dat het heeft voortgebracht, en waarom we dat systeem fundamenteel moesten heroverwegen om hier te komen.
Wat een bouwmanifest eigenlijk vertegenwoordigt
Laten we precies zijn over wat we tellen. Hoe definiëren we een “build manifest”? Zie het als elke keer dat de Chainguard Factory een nieuw, verifieerbaar artefact produceert: een nieuwe image voor go:1.26.5, een herbouw van nginx getriggerd door een libc-patch, een nieuwe architectuurvariant, een geregenereerde SBOM na een verandering van afhankelijkheid – al deze gebeurtenissen veroorzaken een nieuwe build en dus nieuwe artefacten.
Op onze schaal kan een enkel project als Python tientallen ondersteunde versies hebben, elk met meerdere architectuurbuilds, elk herhaaldelijk herbouwd als upstream-wijzigingen, als patch voor afhankelijkheden, en naarmate we het basisimage verder verharden. De telling laat zien hoe onze hele catalogus op elk moment actueel blijft tijdens elk project dat we ondersteunen.
Dat onderscheid is het verschil tussen een catalogus die veilig is op de dag dat u een afbeelding ophaalt, en een catalogus die elke dag daarna veilig is. Het meeste kwetsbaarheidsbeheer is rond het eerste gebouwd, maar voor het laatste bouwen we infrastructuur.
Hoe wij bouwen
Alles begint met Chainguard OS, ons speciaal gebouwde Linux-besturingssysteem. Chainguard OS is ontworpen voor moderne, cloud-native workloads en geeft ons volledige controle over de software-toeleveringsketen. In tegenstelling tot oudere en bestaande Linux-distributies is Chainguard OS ontworpen voor continue software-integratie en -levering, evenals snelle nano-updates en herbouwingen. We leggen alle beveiligings-, functionele en prestatie-updates vast die door de open source-gemeenschap zijn gebouwd en leveren deze zo snel mogelijk aan klanten. We snijden niet elke zes maanden een release uit en laten de distro dan verouderen. Chainguard OS maakt gebruik van een rolling release en nieuwe artefacten worden de hele dag, elke dag verzonden.
Chainguard Factory is de infrastructuur en de agentische motor die deze levering mogelijk maakt. Elk artefact dat uit de fabriek komt, heeft verdedigingslagen en is vanaf de bron opgebouwd met SLSA Level 3-herkomst, Sigstore-handtekeningen en volledige SBOM’s.
De fabrieksschaal en de architectuur maken herbouw op dit volume mogelijk. Omdat builds declaratief en reproduceerbaar zijn, kunnen we een afbeelding regenereren zonder ons zorgen te hoeven maken over de verborgen status of het verschil tussen wat we wilden verzenden en wat er daadwerkelijk is verzonden. Maar reproduceerbaarheid alleen brengt je niet tot een miljard build-manifesten in het tijdsbestek waar we het over hebben. Snelheid vereist iets anders: weten wanneer om opnieuw op te bouwen, en om onmiddellijk op dat signaal te kunnen reageren, in duizenden onderling afhankelijke projecten, zonder dat bij elke beslissing een mens betrokken is.
Waarom we Factory 2.0 hebben gebouwd
De oorspronkelijke Chainguard Factory automatiseerde de mechanica van het bouwen. Er is een pakketdefinitie nodig, de afhankelijkheden worden opgelost, het pakket wordt gebouwd, ondertekend en verzonden. Maar die architectuur was een traditioneel, door gebeurtenissen aangedreven systeem, en naarmate onze catalogus groeide, werden de grenzen ervan onmogelijk te negeren. Het veranderde in wat we intern een ‘cascading puinhoop’ noemden. SRE’s raakten verdronken in meldingen van gebeurtenissen, wachtrijen werden broos en mislukte dubbele builds en conflicten tussen werkitems kwamen vaak voor. Wanneer een taak slechts gedeeltelijk slaagde of iets onvoorziens tegenkwam, was er een mens nodig om in te grijpen en het probleem op te lossen. We hadden te maken met de ‘CVE doom loop’: hoe hard het team ook werkte, de infrastructuur was voortdurend bezig met het bestrijden van configuratiedrift en -verval in plaats van erop vooruit te lopen.
Factory 2.0, mogelijk gemaakt door wat wij DriftlessAF noemen, is ons antwoord op dat probleem. Het is een zelfcorrigerend bouwsysteem dat agentische, door AI aangedreven afstemming op onze bestaande deterministische automatisering legt. Concreet betekent dat:
- Een verzoeningslus: In plaats van te reageren op individuele gebeurtenissen, vergelijkt DriftlessAF voortdurend een gewenste toestand met de werkelijke toestand, en probeert het de kloof te dichten telkens wanneer een CVE wordt gerapporteerd, een nieuwe pakketversie stroomopwaarts belandt, een nieuwe best practice wordt geïmplementeerd, of we naar wens een aantal andere nieuwe criteria definiëren.
- Een continue werkwachtrij: Een groot aantal reconciler-bots krijgt voortdurend werk toegewezen vanuit een gedeelde wachtrij, waarbij de status die is ontdekt uit codeopslagplaatsen, beveiligingsfeeds en andere bronnen wordt afgestemd op onze doelstatus.
- Redundant door ontwerp: Omdat elke taak naar een gedefinieerde eindtoestand toewerkt in plaats van een eenmalige actie uit te voeren, kan een mislukt werkitem eenvoudigweg worden verwijderd of opnieuw worden geprobeerd. Het systeem komt uiteindelijk tot de juiste uitkomst, in plaats van elke stap nodig te hebben om de eerste keer te slagen.
- AI waar het zijn plaats verdient: Reconciler-bots gebruiken AI specifiek om de ongestructureerde beoordelingsgesprekken af te handelen die traditionele automatisering niet aankan (zaken als redeneren over een nieuw toegevoegd onderdeel in een kleine release of het backporteren van een CVE-herstel naar een ouder pakket en een oudere taalrelease), terwijl ze nog steeds werken met zeer gestructureerde, verifieerbare tools om te voorkomen dat de lus zich een weg naar een slecht resultaat hallucineert. Bovendien leert het systeem van eerdere successen, zoals het patchen van een oudere bibliotheekversie die de backport-test doorstaat. Het gebruikt die kennis om toekomstige patches voor andere oudere versies te informeren. Na verloop van tijd wordt het systeem steeds onafhankelijker en krachtiger in het aanpakken van complexe taken.
De waarde hier is dat AI het operationele werk op zich neemt – de eenvoudige beoordelingsgesprekken, gedetailleerde triage en duizenden kleine beslissingen – die vroeger het knelpunt vormden bij de wederopbouwsnelheid.
Waarom de snelheid ertoe doet
Het dreigingsmodel is veranderd en snelheid op schaal is alles. Aanvallers profiteren steeds vaker van dezelfde AI-tools voor het ontdekken van kwetsbaarheden, het creëren van exploits en het koppelen van complexe exploits voor effectieve aanvallen. AI kan afhankelijkheidsgrafieken scannen, zwakke punten aan elkaar koppelen en een werkende exploit produceren, veel sneller dan een menselijke aanvaller ooit zou kunnen. Wanneer de cyclustijd van de aanvaller korter wordt, moet de cyclustijd van de verdediger met minstens dezelfde hoeveelheid korter worden.
De snelheid van het opnieuw opbouwen is wat de catalogus veilig houdt. Elk uur dat we de tijd tussen een upstream-wijziging en een opnieuw opgebouwde, ondertekende, geverifieerde image afschaven, is een uur waarmee een aanvaller niet hoeft te werken. Het verdubbelen van onze productie van 500 miljoen naar 1 miljard build manifests in zes maanden is het bewijs dat de verzoeningslus in een tempo werkt dat plausibel gelijke tred kan houden met de richting waarin het dreigingslandschap zich ontwikkelt.
Het agentische en geautomatiseerde karakter van Chainguard Factory stelt ons engineeringteam ook in staat om als experts voor de agenten op te treden, voorgestelde wijzigingen te arbitreren en zich te concentreren op verdere verbeteringen van de fabrieksinfrastructuur, de kwaliteit van de resultaten en de algehele reikwijdte van alles wat Chainguard Factory bouwt en onderhoudt. Dit omvat Chainguard-bibliotheken, Chainguard-agentvaardigheden, Chainguard-acties en meer.
Wat is het volgende
Vanaf hier vertragen we niet. Het team gaat door met het uitbreiden van DriftlessAF, ons belangrijkste open source agentische raamwerk in Chainguard Factory, met meer verzoeningsbots, meer bronnen die de werkwachtrij voeden en een groter deel van de catalogus loopt via de zelfherstellende lus in plaats van het oude, door gebeurtenissen aangedreven pad. En omdat de kern van DriftlessAF nu open source is, kunnen andere teams die met hun eigen grootschalige automatiseringsproblemen worden geconfronteerd, voortbouwen op wat we hebben geleerd in plaats van helemaal opnieuw te beginnen.
Als u wilt zien wat er vandaag de dag in de catalogus staat, is onze catalogus met containerimages de beste plek om te kijken. En als je je in het systeem zelf wilt verdiepen, kun je DriftlessAF bekijken, inclusief documentatie en andere bronnen.
Opmerking: Dit artikel is vakkundig geschreven en bijgedragen door Matt Moore, medeoprichter en CTO, Chainguard.
