Инженеры Amazon Web Services (AWS) описали, как команда, обслуживающая ядро Linux для инфраструктуры EC2, обрабатывает CVE ядра. Этот процесс сочетает в себе автоматический фильтр, агента искусственного интеллекта и проверку человеком. Команда также утверждает, что ей необходимо перейти на более новые ядра с долгосрочной поддержкой (LTS), поскольку старые ветки собирают исправления, которые никогда не передаются обратно.
Дилан Джонсон и Жюстин Бурон выступили с докладом на конференции Linux Plumbers Conference в Праге в начале этого месяца. В начале записи Джонсон объясняет, что команда поддерживает ядро, используемое в инфраструктуре EC2. Это отдельно от Amazon Linux и ядер, которые клиенты запускают на своих виртуальных машинах.
После того, как в феврале 2024 года проект ядра стал органом нумерации CVE, команда видела около двух CVE ядра за неделю до 2024 года и около 16 через день, из них 848 было опубликовано 15 августа 2026 года. В документации CVE ядра говорится, что проект не может знать, как данная система использует ядро, поэтому пользователи должны решить, какие CVE к ним применимы.
На первом этапе процесса AWS ИИ не используется. Бурон объяснил, что записи CVE ядра публикуются в формате JSON и содержат список затронутых версий и исходных файлов. Сценарий отбрасывает CVE, если версия ядра находится за пределами затронутого диапазона или если ни один из перечисленных файлов не встроен в образ. В среде AWS это удаляет около 70% CVE, хотя Бурон говорит, что эта цифра сильно зависит от конфигурации ядра.
Остальные CVE передаются ИИ-агенту. Он получает дерево исходного кода ядра AWS, конфигурацию для каждой платформы, описание среды и модели угроз, а также категорию серьезности. Агент создает таблицу, в которой записана затронутая подсистема, тип уязвимости и вектор атаки. Бурон сказал, что команда игнорирует оценки CVSS, поскольку они не специфичны для ее среды.
«Мы действительно используем его как очень причудливый классификатор».
Дилан Джонсон
Таблицу обычно просматривают два инженера. Судя по слайдам, на одно CVE агенту требуется около 3,4 секунды, по сравнению с минутами для человека. Бурон сказал, что проверка сейчас является самым медленным этапом процесса, и что команда не намерена ее удалять.
«Мы не хотим полностью зависеть от результатов работы агента LLM».
Жюстиниан Бурон
Отвечая на вопрос о точности, Бурон подсчитал, что от 5% до 10% решений агента были проблематичными. Это была неофициальная оценка, и в докладе не описывалась формальная оценка.
Команда также отключила ненужные функции ядра, чтобы уменьшить количество применимых CVE. Бурон назвал этот подход «обманчиво сложным». На слайдах перечислено более 32 000 вариантов конфигурации, и удаление неправильного варианта может привести к ошибкам или снижению производительности, которые появятся спустя несколько месяцев.
Данные команды также показывают, что старые ветки LTS получают исправления позже и содержат больше неисправленных CVE. Для CVE, затронувших все шесть изученных ветвей, среднее время от основного исправления до выпуска LTS составило 31,8 дня для Linux 5.10 и 18,1 дня для Linux 6.18. По состоянию на 16 сентября в версии 5.10 было не исправлено 1709 известных CVE по сравнению с 229 в версии 6.18. Это подсчеты для каждой ветки, и они не показывают, сколько из них влияет на собственное ядро AWS.
Резервное копирование исправлений собственными силами сопряжено с определенными рисками. Бурон отметил, что в записях CVE часто упоминается только окончательный коммит исправления. Команда, которая не выполнила необходимые коммиты, все равно может оставаться уязвимой после применения указанного исправления.
AWS сократила свои собственные обновления. Джонсон сказал, что переход с версии 4.19 на версию 5.10 занял около двух лет, считая от начала работ по переносу до полного развертывания производства. Следующее обновление заняло около года, а переход на 6.18 занял около полугода. Во время обновления с 5.10 до 6.12 43% отслеживаемых проблем были исправлены в пользовательском пространстве, где рабочие нагрузки зависели от поведения старого ядра. Джонсон сказал, что теперь команда будет тестировать стабильные ядра в течение года и перемещать парк при появлении каждой новой версии LTS.
Команда Microsoft Azure Linux описала аналогичный конвейер на той же конференции. Вердикты сортировки исходят из таблицы правил, а ИИ лишь предлагает входные данные для нее. Команда использует агентов для резервного копирования и сообщает, что цикл обратной связи по сборке и тестированию повысил показатель успеха примерно с 50% до 80%. CodeMender от Google DeepMind, о котором InfoQ рассказал в октябре 2025 года, фокусируется на написании исправлений. В объявлении говорилось, что исследователи-люди проверяют каждый патч перед его отправкой в исходную версию.
Беренд де Бур, технический директор Process Focus, прокомментировал в LinkedIn работу, связанную с запуском облачной инфраструктуры. Он перечислил исправления хостов и CVE для Linux среди работ, которые организации берут на себя при создании собственного облака. «Сосредоточьтесь на том, что делает ваш бизнес ценным для ваших клиентов», — написал он.
AWS не выпустила эти инструменты. Отвечая на вопрос об их открытом исходном коде, Джонсон сказал, что команда хотела бы изучить возможность совместного использования инструмента фильтрации. Он также признал, что внутренним пользователям AWS проще отключать функции, чем при распространении общего назначения.
