В анонсе предварительного выпуска ядра Linux 7.1-rc4 Линус Торвальдс выступил с жесткой критикой в адрес исследователей безопасности, использующих инструменты на базе искусственного интеллекта. Разработчик призвал не направлять автоматически сгенерированные отчеты об уязвимостях в приватный список рассылки «security@kernel.org».
Торвальдс отметил, что массовое использование типовых AI-алгоритмов привело к наплыву однотипных жалоб. Поскольку исследователи не имеют доступа к общей базе уже поданных заявок, они отправляют множество дубликатов. Подобная практика создает критическую нагрузку на сопровождающих проекта, делая процесс обработки уязвимостей практически неуправляемым.
Почему автоматические отчеты — это проблема:
- Растрата ресурсов: Сопровождающие тратят время на отсеивание повторов, а разработчики — на глубокий анализ проблем, о которых кто-то другой мог сообщить ранее.
- Отсутствие прозрачности: Список «security@kernel.org» закрыт, поэтому отправители не могут самостоятельно проверить, не обсуждался ли аналогичный баг другими участниками.
- Бессмысленная имитация: Линус подчеркнул, что приватный разбор подобных «автоматических» находок является пустой тратой времени для всей команды ядра.
Теперь исследователям предписано сообщать об уязвимостях, выявленных с помощью нейросетей, исключительно через публичные списки рассылки. Исключение составляют лишь критические проблемы, требующие оперативного закрытого обсуждения.
Торвальдс дал рекомендации по «ответственному» использованию ИИ в информационной безопасности:
- Не заниматься бездумной пересылкой результатов работы AI-ассистентов.
- Предварительно самостоятельно анализировать проблему и подтверждать её реальное существование.
- Изучать документацию по отправке отчетов об ошибках и по возможности прикладывать готовый патч.
- Тщательно проверять актуальную кодовую базу: зачастую ошибка, найденная «умным» инструментом, могла быть исправлена сообществом еще несколько недель назад.
По мнению создателя ядра, искусственный интеллект — мощный инструмент, но он должен приносить реальную пользу, упрощая разработку, а не создавать дополнительную «головную боль» и имитацию бурной деятельности для сопровождающих проекта.
