В сентябре Canonical объявила, что будет выпускать апдейты для ядра Linux в Ubuntu каждую неделю. Одна из причин — инструменты на основе ИИ помогают находить все больше уязвимостей, и разработчикам приходится быстрее доставлять исправления пользователям. Впрочем, на статистику повлияли и новые правила учета ошибок в Linux. Чтобы справиться с нагрузкой, компания перестраивает график подготовки пакетов, сохраняя время на их проверку. Давайте посмотрим, как это будет работать и насколько полезными оказались нейросети в поиске проблем с безопасностью.
Неделя вместо месяца?
Сначала вспомним план, которого команда Ubuntu придерживалась с августа 2023 года. Обычные исправления собирали в четырехнедельный цикл Stable Release Updates, сокращенно SRU. Каждые две недели предусматривался дополнительный выпуск для срочных проблем безопасности и других критичных неполадок. Поэтому представлять старую схему как месяц ожидания при любых обстоятельствах было бы неправильно. Кроме того, при необходимости пакет могли пересобрать внутри текущего цикла, например из-за обнаруженной регрессии.
В новом варианте плана для каждого апдейта по-прежнему отводят 2 недели. В течение первой разработчики собирают пакет и проверяют, что ядро загружается и работает без явных сбоев. Вторая нужна для проведения подробных тестов, в том числе на совместимость с оборудованием. Подготовку следующего выпуска начинают не дожидаясь завершения предыдущего цикла. Получается, что работа над несколькими обновлениями идет одновременно, а готовые пакеты выходят каждую неделю. Стоит уточнить, что здесь речь об исправлениях для ядра в поддерживаемых версиях Ubuntu, а не о переходе на новую версию Linux каждые 7 дней.
Переходить на новый график решили постепенно. Сначала разработчики запланировали 2 выпуска, выделив на каждый по 2 недели: первый цикл начался 28 сентября, второй — 12 октября 2026 года. На этом этапе работу еще вели последовательно: сначала заканчивали одно обновление, затем брались за следующее. С 26 октября подготовку новых пакетов планируют начинать каждую неделю, пока предыдущие проходят проверку.
А нейросети действительно что-то находят?
Да, и для этого необязательно поручать чат-боту прочитать весь репозиторий и написать заключение. Один из рабочих вариантов — использовать языковую модель при подготовке тестов для фаззинга. Такой инструмент многократно подает программе разнообразные, в том числе некорректные, данные и наблюдает за результатом. Но до нужной функции еще надо добраться, правильно вызвав ее и создав подходящее окружение. Написание этой обвязки требует времени, а качество заготовки влияет на то, какие участки вообще удастся проверить.
Google показала такой подход в OSS-Fuzz в ноябре 2024 года. Созданные с помощью LLM тестовые обвязки позволили обнаружить 26 новых уязвимостей в проектах, которые уже долго проверяли обычными средствами. Среди прочих «поймали» CVE-2024-9143 в OpenSSL — по оценке исследователей, она могла оставаться незамеченной около 20 лет. Модель помогла расширить набор проверяемых ситуаций, а наличие дефекта подтверждалось запуском программы. Так что польза от ИИ есть, и она немалая.
Есть и пример с Firefox, о котором Anthropic рассказала в марте 2026 года. За 2 недели работы Claude Opus 4.6 обнаружила 22 уязвимости, из которых Mozilla отнесла 14 к высокой степени опасности. Всего спецы отправили 112 отдельных отчетов. Первую «находку» сотрудники воспроизвели в изолированной виртуальной машине до передачи разработчикам. Уже потом стороны договорились о массовой отправке результатов, то есть речь шла о согласованной совместной работе.
Здесь важно, что найденные ошибки проверяли специалисты, а разработчики Firefox подтвердили их опасность и выпустили исправления. К сожалению, не все, кто ищет уязвимости с помощью ИИ, утруждают себя такой проверкой. Иногда сгенерированное описание сразу отправляют авторам программы, оставляя им разбираться, существует ли проблема вообще. Для небольшого проекта поток таких сообщений может стать серьезной нагрузкой. Именно с этим столкнулась команда curl.
Когда помощь оказывается медвежьей услугой
У curl история получилась другой: 31 января 2026 года проект закрыл программу денежных вознаграждений за уязвимости. За время ее работы исследователи помогли подтвердить 87 проблем, получив более 100 тысяч долларов. Но затем доля полезных обращений резко сократилась: по словам Даниэля Стенберга, с 2025 года она упала ниже 5%. Причиной он называет поток сгенерированных ИИ материалов и общее снижение качества сообщений. Читать присланное команда продолжила, вот только толку от этого было немного.
По словам Стенберга, к разбору одного сообщения в curl подключались 3–4 человека, и каждый мог потратить от получаса до нескольких часов. При этом некоторые участники команды могут уделять проекту совсем немного времени. Получается, все это время уходит на проверку чужого сообщения, которое отправитель даже не потрудился чекнуть.
Отмена выплат стала попыткой убрать стимул использовать ИИ для «коврового бомбометания» по разработчикам в плане «авось да окажется реальной угрозой». Прием сообщений о безопасности сохранили, переведя его в закрытые обращения на GitHub. Полезность исследования по-прежнему определяется содержимым: как воспроизвести сбой, при каких условиях он возникает, чем грозит пользователю.
Что в итоге?
Перед выпуском исправление нужно проверить на тех версиях ядра, которые используются в Ubuntu. Они отличаются от исходного Linux: в них уже есть доработки Canonical и ранее перенесенные изменения. Поэтому готовый патч может потребовать адаптации. После этого разработчики проверяют, что он устраняет уязвимость и не мешает системе. Успешной сборки здесь недостаточно: ядро может собраться без ошибок, но вызвать сбои при загрузке или работе оборудования.
Если ждать окончания всех проверок некогда, предварительную сборку можно взять из репозитория -proposed. Туда пакеты попадают после первой недели подготовки, до детальных тестов Canonical. Например, администратор сможет раньше проверить исправление на тестовом сервере со своими настройками и приложениями. Но выяснять, подходит ли такая сборка для рабочих машин, придется самостоятельно. Для обычного обновления системы лучше дождаться проверенного выпуска в основном репозитории.
Для администраторов серверов новый график означает, что апдейты придется проверять и устанавливать чаще. Если делать это по-прежнему раз в месяц, исправления будут ждать своей очереди, хотя Canonical уже выпустила их. Поэтому стоит заранее выделить время на тесты и обслуживание рабочих машин. На случай сбоев нужен и способ вернуться к предыдущему ядру, иначе еженедельный выпуск пакетов сам по себе не сократит срок, в течение которого сервер остается уязвимым. Так что имейте в виду.