През последните шест месеца Chainguard удвои производството си от 500 милиона до повече от 1 милиард манифеста за състоянието на софтуерни компилации. Също така преминахме границата от 3 000 уникални изображения на контейнери и 675 000 версии на изображения в нашия каталог. Това са водещите числа, но искам да споделя какво всъщност стои зад тях. Самото число е по-малко интересно от системата, която го е произвела, и защо трябваше фундаментално да преосмислим тази система, за да стигнем дотук.

Какво всъщност представлява манифестът за състоянието на софтуерна компилация

Нека бъдем точни отново за това какво броим. Как дефинираме „манифест за състоянието на софтуерна компилация“? Мислете за него като за всеки път, когато Chainguard Factory произвежда нов, проверим артефакт: свежо изображение за go:1.26.5, повторно компилиране на nginx, задействано от корекция за сигурност в libc, нов вариант на архитектурата, повторно генериран SBOM след промяна в зависимост — всички тези събития предизвикват нова компилация и следователно нови артефакти.

При нашия мащаб един отделен проект като Python може да има десетки поддържани версии, всяка с множество компилации за различни архитектури, всяка прекомпилирана неколкократно при промени в изходния код, при отстраняване на уязвимости в зависимостите и при допълнително укрепване на базовото изображение. Този брой показва как целият ни каталог остава актуален във всеки един момент във всеки проект, който поддържаме.

Тази разлика е разграничението между каталог, който е защитен в деня, в който изтегляте изображение, и такъв, който е защитен всеки ден след това. Повечето системи за управление на уязвимости са изградени около първото, но ние изграждаме инфраструктура за второто.

Как компилираме

Всичко започва с Chainguard OS, нашата специално създадена операционна система Linux. Chainguard OS е проектирана за модерни, облачно-ориентирани работни товари и ни дава пълен контрол върху веригата за доставки на софтуер. За разлика от традиционните Linux дистрибуции, Chainguard OS е проектирана за непрекъсната софтуерна интеграция и доставка, както и за бързи нано-обновявания и повторни компилации. Ние прихващаме всички актуализации за сигурност, функционалност и производителност, създадени от общността с отворен код, и ги доставяме на клиентите възможно най-бързо. Не пускаме версия на всеки шест месеца, оставяйки дистрибуцията да остарява. Chainguard OS използва модел на непрекъснати обновления (rolling release) и нови артефакти се доставят целодневно, всеки ден.

Chainguard Factory е инфраструктурата и интелигентният двигател, който задвижва тази доставка. Всеки артефакт, който излиза от фабриката, има слоеве на защита и е изграден от изходен код със SLSA Level 3 произход, Sigstore подписи и пълни SBOM структури.

Мащабът на фабриката и нейната архитектура правят повторната компилация в такъв обем възможна. Тъй като компилациите са декларативни и възпроизводими, можем да генерираме отново изображение, без да се притесняваме за скрито състояние или разминаване между това, което възнамерявахме да доставим, и това, което действително е доставено. Но само възпроизводимостта не може да ви доведе до милиард манифеста за посочения период от време. Скоростта изисква нещо друго: да знаете кога да компилирате отново и да можете да реагирате на този сигнал незабавно, сред хиляди взаимозависими проекти, без човешка намеса за всяко решение.

Защо изградихме Factory 2.0

Оригиналната Chainguard Factory автоматизираше механиката на компилиране. Тя вземаше дефиниция на пакет, разрешаваше зависимостите, компилираше пакета, подписваше го и го доставяше. Но тази архитектура беше традиционна система, управлявана от събития, и с нарастването на каталога ни нейните ограничения станаха невъзможни за пренебрегване. Тя се превърна в това, което вътрешно наричахме „каскаден хаос“. SRE инженерите се удавяха в известия за събития, опашките станаха нестабилни, а дублиращите се грешки при компилиране и конфликтите между работни задачи бяха ежедневие. Всеки път, когато дадена задача успяваше само частично или срещаше непредвиден проблем, беше необходима човешка намеса за отстраняването му. Трябваше да се справяме с „порочния кръг на CVE“: колкото и здраво да работеше екипът, инфраструктурата постоянно се бореше с конфигурационни разминавания и разпад, вместо да изпреварва събитията.

Factory 2.0, задвижвана от това, което наричаме DriftlessAF, е нашият отговор на този проблем. Това е самокоригираща се система за компилиране, която добавя интелигентно AI съгласуване над съществуващата ни детерминирана автоматизация. Конкретно това означава:

  • Цикъл на съгласуване: Вместо да реагира на отделни събития, DriftlessAF непрекъснато сравнява желаното състояние с действителното състояние и работи за затваряне на празнината всеки път, когато се съобщи за CVE, появи се нова версия на пакет, внедри се нова добра практика или дефинираме нови критерии като желани.
  • Непрекъсната работна опашка: Голям брой ботове за съгласуване непрекъснато получават задачи от споделена опашка, съгласувайки откритото състояние от хранилищата с код, емисиите за сигурност и други източници спрямо целевото ни състояние.
  • Изградена с излишност по дизайн: Тъй като всяка задача работи за постигане на дефинирано крайно състояние, а не изпълнява еднократна операция, неуспешна задача може simplement да бъде отхвърлена или повторена. Система в крайна сметка постига правилния резултат, вместо да изисква всяка стъпка да успее от първия път.
  • AI там, където наистина помага: Ботовете за съгласуване използват изкуствен интелект конкретно за справяне с неструктурирани субективни преценки, с които традиционната автоматизация не можеше да се справи — като преценка за новодобавен компонент в минорна версия или пренасяне на корекция за сигурност на CVE към по-стара версия на пакет и език — докато все още работят чрез строго структурирани, проверими инструменти, за да се предотврати халюцинирането на цикъла до лош резултат. Освен това системата се учи от предишни успехи, като например отстраняване на уязвимост в по-стара версия на библиотека, която преминава теста за пренасяне. Тя използва това знание, за да подпомогне бъдещи корекции за сигурност на други по-стари версии. С течение на времето системата става все по-независима и мощна при справяне с комплексни задачи.

Стойността тук е, че AI поема рутинната оперативна работа — прости преценки, подробен триаж и хиляди малки решения — които преди бяха тесното място за скоростта на повторно компилиране.

Стек DriftlessAF от облачната инфраструктура до агентите и ботовете

Защо скоростта е важна

Моделът на заплахите се промени и скоростта в мащаб е всичко. Атакуващите все повече се възползват от същите AI инструменти за откриване на уязвимости, създаване на експлоати и комплексно верижно свързване на експлоати за ефективни атаки. AI може да сканира графи от зависимости, да свързва слабости във верига и да генерира работещ експлойт много по-бързо, отколкото човек атакуващ би могъл. Когато цикълът на атакуващия се съкращава, цикълът на защитника трябва да се съкрати поне със същата стойност.

Общ преглед на взаимодействията между компонентите за компилиране на контейнери в Chainguard Factory

Скоростта на повторно компилиране е това, което поддържа каталога защитен. Всеки час, който спестяваме между промяна в изходния код и повторно компилирано, подписано и проверено изображение, е час, с който киберпрестъпникът не разполага за работа. Удвояването на нашата продукция от 500 милиона на 1 милиард манифеста за състоянието на софтуерни компилации за шест месеца е доказателство, че цикълът на съгласуване работи с темпове, които реално могат да се съревновават с посоката, в която се развива пейзажът на заплахите.

Автоматизираният характер на Chainguard Factory също така позволява на нашия инженерния екип да действа като експерт за агентите, да арбитрира предложените промени и да се фокусира върху по-нататъшни подобрения на инфраструктурата на фабриката, качеството на резултатите и общия обхват на всичко, което Chainguard Factory поддържа. Това включва Chainguard Libraries, Chainguard Agent Skills, Chainguard Actions и други.

Какво следва

Не възнамеряваме да намаляваме темпото. Екипът продължава да разширява DriftlessAF, нашата основна рамка от ботове с отворен код в Chainguard Factory, с повече ботове за съгласуване, повече източници, захранващи работната опашка, и по-голяма част от каталога, преминаваща през самовъзстановяващия се цикъл вместо през стария път, управляван от събития. И тъй като ядрото на DriftlessAF вече е с отворен код, други екипи, изправени пред свои собствени проблеми с автоматизация в гигантски мащаби, могат да надграждат върху това, което научихме, вместо да започват от нулата.

Ако искате да видите какво всъщност съдържа каталогът днес, нашият каталог с изображения на контейнери е най-доброто място за преглед. А ако искате да разгледате самата система, можете да проверите DriftlessAF, включително документацията и останалите ресурси.

Забележка: Тази статия е професионално написана от Мат Мур, съосновател и технически директор (CTO) на Chainguard.