За последние шесть месяцев компания 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 использует модель «роллинг-релиз», и новые артефакты поставляются круглосуточно, каждый день.
Chainguard Factory — это инфраструктура и агентный движок, обеспечивающий такую доставку. Каждый артефакт, выходящий из фабрики, имеет несколько уровней защиты и собирается из исходного кода с прослеживаемостью уровня 3 по стандарту SLSA, подписями Sigstore и полными списками компонентов (SBOM).
Масштаб фабрики и её архитектура делают возможной пересборку в таких объёмах. Поскольку сборки являются декларативными и воспроизводимыми, мы можем повторно сгенерировать образ, не беспокоясь о скрытом состоянии или расхождениях между тем, что мы намеревались выпустить, и тем, что было фактически выпущено. Но одной воспроизводимости недостаточно, чтобы достичь миллиарда манифестов сборок в те сроки, о которых мы говорим. Для обеспечения высокой скорости требуется ещё кое-что: понимание того, когда необходимо выполнить пересборку, и способность немедленно реагировать на этот сигнал в тысячах взаимозависимых проектов, без участия человека в принятии каждого решения.
Первоначальная Chainguard Factory автоматизировала механику сборки. Она принимала определение пакета, разрешала зависимости, собирала пакет, подписывала его и отправляла. Но эта архитектура представляла собой традиционную систему, управляемую событиями, и по мере роста нашего каталога её ограничения стало невозможно игнорировать. Система превратилась в то, что мы внутри компании называли «каскадным хаосом». Специалисты по надежности и эксплуатации (SRE) тонули в уведомлениях о событиях, очереди становились неустойчивыми, а повторяющиеся сбои сборки и конфликты рабочих элементов стали обычным явлением. Всякий раз, когда задача выполнялась лишь частично или сталкивалась с чем-то непредвиденным, требовалось вмешательство человека для исправления ситуации. Нам приходилось иметь дело с «порочным кругом CVE»: как бы усердно ни работала команда, инфраструктура постоянно боролась с отклонениями в конфигурации и деградацией, вместо того чтобы опережать их.
Factory 2.0, основанная на технологии, которую мы называем DriftlessAF, — это наш ответ на эту проблему. Это самокорректирующаяся система сборки, которая накладывает агентное согласование на основе искусственного интеллекта на нашу существующую детерминированную автоматизацию. Конкретно это означает:
- Цикл согласования: вместо того чтобы реагировать на отдельные события, DriftlessAF непрерывно сравнивает желаемое состояние с фактическим и работает над устранением разрыва всякий раз, когда поступает сообщение о CVE, в исходном репозитории появляется новая версия пакета, внедряется новая рекомендация или мы определяем какие-либо другие новые критерии по мере необходимости.
- Непрерывная очередь задач: большому количеству ботов-реконцилиаторов постоянно назначаются задачи из общей очереди; они приводят состояние, обнаруженное в репозиториях кода, каналах безопасности и других источниках, в соответствие с нашим целевым состоянием.
- Избыточность по замыслу: поскольку каждая задача направлена на достижение определённого конечного состояния, а не на выполнение разового действия, неудавшийся рабочий элемент можно просто отбросить или повторить попытку. Система в конечном итоге достигает нужного результата, и не требуется, чтобы каждый шаг был выполнен успешно с первой попытки.
- ИИ там, где он действительно нужен: боты-реконцилиаторы используют ИИ именно для решения неструктурированных задач, с которыми не справляется традиционная автоматизация — например, анализ вновь добавленного компонента в незначительном релизе или обратное портирование исправления CVE в более старый пакет и версию языка — при этом по-прежнему работая через строго структурированные, поддающиеся проверке инструменты, чтобы цикл не привел к нежелательному результату из-за ошибочных выводов. Кроме того, система учится на предыдущих успехах, таких как исправление старой версии библиотеки, прошедшее тест на обратную портировку. Она использует эти знания для создания будущих исправлений для других старых версий. Со временем система становится всё более независимой и мощной в решении сложных задач.
Ценность здесь заключается в том, что ИИ берет на себя оперативную рутинную работу — простые субъективные оценки, детальный отбор и тысячи мелких решений — которая раньше была «узким местом», сдерживающим скорость пересборки.
Модель угроз изменилась, и скорость в любом масштабе — это самое главное. Злоумышленники всё чаще используют те же инструменты ИИ для обнаружения уязвимостей, создания эксплойтов и построения сложных цепочек эксплойтов для проведения эффективных атак. ИИ может сканировать графы зависимостей, объединять уязвимости в цепочки и создавать рабочий эксплойт гораздо быстрее, чем это когда-либо смог бы сделать злоумышленник-человек. Когда время цикла злоумышленника сокращается, время цикла защитника должно сокращаться как минимум на ту же величину.
Именно скорость пересборки обеспечивает безопасность каталога. Каждый час, который мы сокращаем между изменением в исходном коде и получением пересборённого, подписанного и проверенного образа, — это час, которым злоумышленник не может воспользоваться. Удвоение объёма нашей продукции с 500 миллионов до 1 миллиарда манифестов сборок за шесть месяцев — доказательство того, что цикл сверки работает с такой скоростью, которая вполне может идти в ногу с тем, куда движется ландшафт угроз.
Агентный и автоматизированный характер Chainguard Factory также позволяет нашей инженерной команде выступать в роли экспертов по агентам, выносить решения по предлагаемым изменениям и сосредоточиться на дальнейшем совершенствовании инфраструктуры фабрики, качестве результатов и общем объёме всего, что создаёт и поддерживает Chainguard Factory. Сюда входят библиотеки Chainguard, навыки агентов Chainguard, действия Chainguard и многое другое.
Мы не собираемся сбавлять обороты. Команда продолжает расширять DriftlessAF — наш основной агентный фреймворк с открытым исходным кодом в Chainguard Factory — за счет добавления новых ботов-реконцилиаторов, дополнительных источников, пополняющих очередь задач, а также включения большего числа элементов каталога в цикл самовосстановления вместо прежнего событийно-ориентированного подхода. А поскольку ядро DriftlessAF теперь является открытым исходным кодом, другие команды, сталкивающиеся со своими собственными проблемами автоматизации в крупных масштабах, могут опираться на наш опыт, а не начинать с нуля.
Если вы хотите увидеть, что на самом деле находится в каталоге сегодня, лучшее место для этого — наш каталог образов контейнеров. А если вы хотите глубже изучить саму систему, можете ознакомиться с DriftlessAF, включая документацию и другие ресурсы.
Примечание: эта статья была профессионально написана и предоставлена Мэттом Муром, соучредителем и техническим директором компании Chainguard.