Линус Торвальдс устал от AI-багрепортов: Linux меняет правила для охотников за уязвимостями

Линус Торвальдс резко описал новую проблему для разработчиков Linux: AI-инструменты помогают находить баги, но одновременно заваливают закрытый security-list повторными и плохо подготовленными отчётами. В еженедельном сообщении о Linux 7.1-rc4 он написал, что поток AI reports сделал список «почти полностью неуправляемым»: разные люди запускают похожие инструменты, находят одни и те же проблемы и отправляют их туда, где другие исследователи не видят уже поданные отчёты.

Смысл претензии не в том, что AI бесполезен. Наоборот, Торвальдс прямо говорит: «AI tools are great» — но только если они действительно помогают, а не создают лишнюю боль и имитацию работы. Его главный совет прост: если модель нашла баг, не отправляйте случайный отчёт без понимания. Проверьте его, прочитайте правила, подготовьте патч и добавьте ценность поверх того, что сделал инструмент.

Что меняет Linux

Новая документация ядра уточняет, какие ошибки вообще стоит считать security bugs. Закрытый security-list нужен для срочных, легко эксплуатируемых уязвимостей, которые дают атакующему новые возможности в корректно настроенной production-системе и угрожают многим пользователям. Большая часть остальных проблем должна обсуждаться публично: так шире круг ревью, быстрее находится правильный maintainer и меньше риск, что один и тот же баг будут тайно пересылать десятки раз.

Отдельный пункт касается AI-assisted reports. Документация kernel.org говорит: если баг найден с помощью AI, его обычно надо считать публичным, потому что такие находки систематически всплывают одновременно у нескольких исследователей, иногда в один день. При этом эксплойт не надо выкладывать открыто: достаточно сообщить, что воспроизведение есть, и передать детали maintainer’ам приватно по запросу.

Почему это больше, чем спор разработчиков

История важна шире Linux, потому что показывает новую цену автоматизации безопасности. Раньше узким местом был поиск ошибок. Теперь AI снижает порог входа: больше людей может прогнать код через анализатор, получить подозрительное место и назвать это уязвимостью. Но узкое место смещается в проверку: нужно понять версию ядра, условия воспроизведения, реальное влияние, границу доверия и путь исправления.

Если этой работы нет, безопасность не ускоряется. Она превращается в очередь из одинаковых писем, где maintainer’ы тратят время не на патчи, а на маршрутизацию, объяснение, что баг уже исправлен, и отделение реальных рисков от шума. Для open source это особенно болезненно: внимание опытных людей — самый дефицитный ресурс проекта.

Урок для компаний

Та же проблема будет появляться в bug bounty, внутренних red team-процессах и корпоративных сканерах кода. AI может находить больше потенциальных дыр, но отчёт без воспроизводимости и владельца исправления — это не защита, а долг в очереди triage.

Практический вывод для команд простой: покупка AI-инструмента для поиска уязвимостей не заменяет процесс. Нужны правила, какие баги считать срочными, кто проверяет результат, где хранится reproducer, как быстро назначается maintainer и когда отчёт отправляется в публичный или приватный канал. Linux сейчас формулирует это жёстко, потому что живёт на переднем крае проблемы: автоматический поиск стал массовым быстрее, чем культура ответственной подачи отчётов.