Chainguard превысила 1 млрд манифестов сборки контейнеров
Chainguard за последние шесть месяцев нарастила выпуск манифестов сборки контейнеров с 500 млн до более чем 1 млрд. Каталог компании также превысил 3 тыс. уникальных контейнерных образов и 675 тыс. версий образов. Речь идёт о результатах работы Chainguard Factory, которая выпускает проверяемые артефакты для облачных нагрузок.
Под манифестом сборки компания понимает каждый новый артефакт, созданный фабрикой: образ для конкретной версии Go, пересборку nginx после исправления libc, вариант для другой архитектуры или обновлённый SBOM после изменения зависимости. Один проект может включать десятки поддерживаемых версий, несколько архитектур и многократные пересборки по мере обновлений.
От периодических релизов к постоянной пересборке
Основой процесса служит Chainguard OS — Linux-дистрибутив для облачных нагрузок. Он использует модель rolling release: новые артефакты выпускаются в течение дня, а не привязаны к редким крупным релизам. Компания заявляет, что это позволяет быстро доставлять исправления безопасности, функциональные и производительные обновления из open source-проектов.
Каждый артефакт Chainguard Factory собирается из исходного кода и сопровождается происхождением SLSA Level 3, подписями Sigstore и полным SBOM. Декларативные и воспроизводимые сборки, по описанию Chainguard, помогают повторно генерировать образы без скрытого состояния и расхождений между ожидаемым и фактически выпущенным результатом.
Почему прежняя архитектура перестала справляться
Первая версия Chainguard Factory автоматизировала стандартный путь: получала определение пакета, разрешала зависимости, собирала и подписывала пакет, затем выпускала его. Однако событийная архитектура стала создавать сложности по мере роста каталога: очереди становились хрупкими, возникали дублирующиеся ошибки сборки и конфликты задач, а частично выполненные операции требовали вмешательства инженеров.
Для замены этого подхода компания разработала Factory 2.0 на базе DriftlessAF — агентного фреймворка с механизмом самокоррекции. Вместо реакции на отдельное событие система непрерывно сравнивает целевое и фактическое состояние. Поводом для устранения расхождения могут стать новая CVE, версия пакета у разработчика, новая практика безопасности или иной заданный критерий.
Роль агентов и ИИ
Задачи из общей очереди получают многочисленные боты-согласователи. Они используют сведения из репозиториев кода, лент безопасности и других источников, чтобы приблизить состояние каталога к заданной цели. Если отдельная задача завершается неудачно, её можно отбросить или повторить: система ориентирована на достижение конечного состояния, а не на обязательный успех каждого единичного шага.
ИИ в DriftlessAF применяется для неструктурированных решений, которые не покрывала прежняя автоматизация: например, оценки нового компонента в минорном релизе или переноса исправления CVE в старую ветку пакета и языка. При этом агенты работают через структурированные проверяемые инструменты. Компания также указывает, что система использует знания об успешных исправлениях при обработке похожих задач.
Для бизнеса важна не только ширина каталога, но и способность поставщика быстро выпускать подписанные и проверяемые обновления образов после изменений в цепочке зависимостей. Метрики Chainguard показывают масштаб такого процесса, а при выборе контейнерных образов стоит отдельно проверять происхождение артефактов, наличие SBOM и практику регулярных пересборок.