Chainguard за шесть месяцев удвоила выпуск и перешла отметку в 1 млрд манифестов сборки контейнеров. Для разработчиков и команд безопасности это не просто красивая цифра из презентации: компания показывает, как должна выглядеть поставка контейнерных образов, если патчи, SBOM и подписи нужны не раз в квартал, а постоянно.
По данным The Hacker News, каталог Chainguard теперь включает более 3000 уникальных контейнерных образов и 675 000 версий образов. Под манифестом сборки компания понимает каждый выпуск проверяемого артефакта: свежий образ go:1.26.5, пересборку nginx после патча в libc, вариант под другую архитектуру или обновление SBOM после изменения зависимости.
Важная деталь здесь в слове «каждый». Один проект вроде Python может иметь десятки поддерживаемых версий, несколько архитектурных вариантов и регулярные пересборки после изменений в upstream, исправлений зависимостей и усиления базового образа. Поэтому манифесты сборки в такой модели становятся не счетчиком маркетинга, а показателем того, насколько быстро каталог остается актуальным после очередной уязвимости или обновления.
Chainguard строит эту систему вокруг Chainguard OS, собственной Linux-базы для cloud-native-нагрузок. Компания делает ставку на rolling release: новые артефакты выходят весь день, а не ждут большого релиза раз в несколько месяцев. Каждый артефакт в Chainguard Factory собирается из исходников и получает SLSA Level 3 provenance, подписи Sigstore и полный SBOM. Для команд, которые уже устали объяснять аудиторам, откуда взялся конкретный слой в контейнере, это звучит почти неприлично практично.
Но воспроизводимые сборки сами по себе не дают миллиард результатов. Старый Chainguard Factory автоматизировал механику: взять описание пакета, разрешить зависимости, собрать, подписать и опубликовать. По мере роста каталога событийная архитектура начала ломаться под собственной логикой. Внутри компании это называли cascading mess: SRE получали слишком много уведомлений, очереди становились хрупкими, возникали дублирующиеся ошибки сборки и конфликты задач. Частично успешные операции часто требовали человека, а команда попадала в цикл постоянной борьбы с CVE, дрейфом конфигураций и распадом состояния.
Ответом стала Factory 2.0 и фреймворк DriftlessAF. Это не замена детерминированной автоматизации на «пусть нейросеть сама что-нибудь соберет», а слой согласования поверх нее. Система непрерывно сравнивает желаемое состояние с фактическим: появилась CVE, вышла новая версия пакета, изменился best practice, добавился новый критерий качества — значит, очередь должна привести каталог к новой цели.
Вместо реакции на одиночные события работает непрерывная очередь задач. Множество reconciler-ботов берут работу из общего потока, сверяют данные из репозиториев, security feeds и других источников, а затем пытаются привести артефакты к целевому состоянию. Если конкретная задача провалилась, ее можно отбросить или повторить: система нацелена на достижение конечного состояния, а не на безошибочное выполнение каждого шага с первого раза.
ИИ в этой схеме используется там, где обычная автоматизация раньше упиралась в мелкие инженерные решения. Например, нужно понять, как трактовать новый компонент в минорном релизе, или аккуратно перенести исправление CVE в старую версию библиотеки или языка. Боты работают через структурированные и проверяемые инструменты, чтобы не превращать supply chain в лотерею. Chainguard также пишет, что система учится на успешных патчах: если backport для старой версии библиотеки прошел проверки, этот опыт может помочь при похожих исправлениях.
Для рынка здесь важен не лозунг про agentic AI, а сдвиг операционной модели. Атакующие уже используют ИИ для поиска уязвимостей, анализа графов зависимостей и сборки цепочек эксплуатации. Если время между публикацией проблемы и рабочим эксплойтом сокращается, защитникам приходится сокращать время между upstream-изменением и пересобранным, подписанным, проверенным образом. Иначе контейнерный каталог быстро превращается в музей вчерашней безопасности.
Для российских и русскоязычных IT-команд прямой вывод простой: вопрос не только в том, какой базовый образ выбрать, а в том, как часто и насколько проверяемо он пересобирается. Если компания держит Kubernetes-кластеры, CI/CD и десятки сервисов, то SBOM, подпись и provenance полезны ровно до тех пор, пока они не отстают от реального состояния зависимостей. Chainguard своим миллиардом показывает планку: безопасность контейнеров все меньше похожа на ручную инвентаризацию и все больше — на фабрику непрерывного ремонта.
Открытый вопрос теперь в том, сколько команд смогут повторить такую модель без масштаба Chainguard и ее инженерного бюджета. DriftlessAF открыт как open source, и это делает историю интереснее: если подход приживется за пределами одного вендора, пересборка контейнеров после CVE станет не героизмом SRE в пятницу вечером, а обычной частью платформенной инфраструктуры. Подробности опубликованы в .