Сопровождающий стабильных ядер Linux Грег Кроа-Хартман в докладе «Security in the LLM age» на конференции Kernel Recipes 2026 показал, сколько пользы ИИ-инструменты дают при поиске уязвимостей в реальном системном коде. Примером стал автоматический аудит Mythos, заявивший 79 проблем в ядре: после строгой мейнтейнерской проверки подтверждаемыми оказались лишь около двадцати, а итогом всей пачки стали «10 настоящих багфиксов». Для индустрии это редкий замкнутый пример, где сырые цифры ИИ-аудита можно сравнить с вердиктом человека, определяющего, что попадёт в стабильные релизы.

image

Что произошло

Грег Кроа-Хартман, Fellow Linux Foundation и сопровождающий стабильных ядер Linux (а также подсистем USB и driver core), выступил 22 сентября 2026 года на конференции Kernel Recipes 2026 с докладом «Security in the LLM age» о том, как на практике выглядит привлечение больших языковых моделей к поиску уязвимостей; запись появилась на официальном YouTube-канале конференции 29 сентября 2026 года. Центральным примером стал разбор прогона автоматического аудита Mythos по коду ядра, и приведённый в обсуждении на Hacker News фрагмент слайда раскладывает все 79 заявленных уязвимостей по категориям: 24 не имели деталей («что-то упало»), 14 вовсе не были багами, 3 содержали полностью выдуманные данные, а 15 уже были исправлены в последнем релизе — 11 из них другими разработчиками и 4 компанией Anthropic. Реально требовали исправлений 20 пунктов, причём в основном с оговорками вроде «предположим вредоносный образ файловой системы» или «предположим возможность инъекции пакета в середину сетевого стека». Итоговый вердикт мейнтейнера по всей пачке — «10 настоящих багфиксов».

Контекст

Кроа-Хартман отвечает за приём исправлений в стабильные ветки ядра, поэтому разбор сторонних отчётов безопасности для него повседневная работа, а его вердикт — та человеческая проверка, которой обычно недостаёт публичным заявлениям о «найденных ИИ уязвимостях». Ценность кейса в том, что он замкнут: известен полный знаменатель заявленных находок и известен результат строгого триажа, тогда как вендорские цифры ИИ-аудитов чаще всего публикуются до всякой проверки. Часть потока имеет прозаическое объяснение: отчёты о находках, уже исправленных к моменту проверки, — типичный симптом устаревшего снапшота кода, на котором работала система, и тривиальная сверка с git-историей до отправки сняла бы почти пятую часть потока почти бесплатно. Ещё часть находок держится на расширенных допущениях модели угроз: формально такие заявки валидны, но практически неприменимы, и именно их в первую очередь отсекает строгий триаж.

Почему это важно для индустрии

Для индустрии доклад переводит давнюю жалобу мейнтейнеров в измеренную величину: генерация списка находок стала дешёвой, дефицитом вместо неё стал человеческий триаж, и честная метрика пайплайна — не количество находок, а доля принятых отчётов в пересчёте на потраченные часы эксперта. Продукт вида «прогнали код через LLM — получили список уязвимостей» в чистом виде в таком разрезе не работает: до статуса завершённых исправлений доходила лишь небольшая часть списка, и это прямое указание, что продавать покупателю следует проверяемый вклад, а не сырой счётчик. В то же время ИИ-компании апстрим действительно двигают фиксы: среди уже исправленных находок со слайда фигурирует компания Anthropic, просто масштаб такого вклада скромнее публичных заявлений о найденных уязвимостях. Разумным ответом отрасли выглядит предвалидация до человека — обязательные шаги воспроизведения, дедупликация против git-истории и релизов, указание модели и версии снимка кода, — а также ожидаемый сдвиг метрик от «найдено N уязвимостей» к «принято апстримом после проверки».

Почему это важно для пользователей

Читателю кейс даёт измеренный повод для скепсиса: заголовки вида «ИИ нашёл N уязвимостей в ядре Linux» разумно читать с вопросом «сколько из этого прошло триаж эксперта», потому что на публичном примере сырой счётчик сжался в разы ещё до вопроса о внесённых исправлениях. Тем, кто сам использует LLM для поиска уязвимостей, стоит добавить в пайплайн входные фильтры до передачи отчётов человеку: обязательные шаги воспроизведения, сверку с уже исправленными версиями и явно заданную модель угроз, иначе находки уйдут в ту же категорию формальных допущений. Тем, кто отправляет отчёты в open-source проекты, урок касается репутации: поток недодетализированных и устаревших заявок расходует время мейнтейнеров и обесценивает следующие отчёты того же отправителя. Основным источником для проверки любых пересказов остаётся полная запись доклада на YouTube.

Что пока неизвестно / ограничения

Все цифры относятся к одному наблюдению: один прогон одной системы Mythos по одной кодовой базе, и выборка из 79 находок слишком мала, чтобы переносить кратность «заявлено — подтверждено» на весь класс ИИ-аудитов. Методология прогона — какая модель использовалась, какими промптами, были ли повторы и на какой версии снимка кода работал аудит — из доступных материалов не известна, поэтому строгие сравнения точности делать рано. Слайд с раскладкой находок известен по фрагменту из обсуждения на Hacker News, и проценты стоит перепроверять по полной записи доклада, а не по пересказам. Итоговая оценка числа внесённых исправлений — формулировка самого Кроа-Хартмана по итогам триажа, а не независимая проверка. Ожидания, что вендоры перейдут на метрику «принято апстримом» и появятся общепринятые входные фильтры для ИИ-отчётов, — это интерпретация доклада, а не свершившееся.

Источники

Автор

Look at AI, редакция