Разработчик GNOME призвал снять запрет на ИИ-отчёты об уязвимостях

Кто такой Майкл Катандзаро и почему его позиция важна

Катандзаро непосредственно участвует в разработке GNOME – рабочего окружения и набора приложений для Linux. Он входит в команду выпуска GNOME, участвует в рабочей группе Fedora Workstation и работает в команде настольных систем Red Hat. Ранее, в компании Igalia, он занимался браузером Epiphany, движком WebKitGTK и библиотекой glib-networking.

Катандзаро остаётся одним из сопровождающих браузера GNOME Web, известного также как Epiphany. Кроме разработки, он занимался учётом проблем безопасности GNOME, запрашивал для них идентификаторы CVE и проверял сообщения участников программы вознаграждений. Поэтому приведённые им примеры связаны с работой, которую он выполнял сам.

Однако его резкие предложения о допустимости зависимостей и размещении проектов на GNOME GitLab представлены как личная инициатива. Публикация не сообщает о принятии этих предложений в качестве правил всего GNOME.

Почему он выступает против запрета ИИ-отчётов

На конференциях GUADEC в 2024 и 2025 годах Катандзаро объяснял, что даже опытные разработчики регулярно допускают опасные ошибки при работе с C, C++ и Vala. Тогда он не рассчитывал, что ИИ справится лучше человека. Теперь, по его мнению, качество анализа изменилось настолько, что поддерживать качественное ПО без поиска уязвимостей с помощью ИИ уже невозможно.

Его аргумент состоит в том, что те же инструменты доступны злоумышленникам. Если разработчики не проверяют собственный код, это могут сделать атакующие, которым ИИ также помогает создавать работающие эксплойты. Катандзаро считает, что рост аудитории Linux повышает интерес к таким атакам, а после проверки безопасности предлагает искать с помощью моделей и обычные ошибки.

В подтверждение практической пользы он ссылается на fwupd 2.0.21: разработчики этого средства обновления прошивок перенесли в выпуск исправления более 250 потенциальных проблем безопасности, обнаруженных разными ИИ-сканерами за три месяца. Формулировка «потенциальные проблемы» здесь важна: она не означает 250 подтверждённых уязвимостей с присвоенными CVE.

Похожее изменение описал разработчик curl Даниэль Стенберг в публикации от 22 апреля. После закрытия программы денежных наград качество сообщений выросло, хотя их поток оставался большим. При этом подтверждёнными уязвимостями оказывались около 15–16% отчётов: качественное описание проблемы и подтверждение её опасности остаются разными критериями.

По словам Катандзаро, некоторые проекты GNOME запрещают ИИ-контент не только в коде и документации, но и в сообщениях об ошибках. Он уже критиковал такой подход 8 июня. В новой публикации он предлагает:

• Пересмотреть правила участия и разрешить отчёты об уязвимостях, подготовленные с помощью ИИ.
• Считать проекты, сохраняющие такой запрет, неподходящими зависимостями для GNOME и предложить им вести разработку за пределами GNOME GitLab.

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

Требование полностью переписать отчёт своими словами он тоже считает непрактичным. Проверить, например, 100 найденных проблем, сообщить о них разработчикам и подготовить исправления – уже большая работа. Дополнительная переработка всех текстов может заставить исследователя переключиться на другой проект или опубликовать результаты в другом месте. Краткое изложение допустимо, но оно не всегда сохраняет полезные подробности полного отчёта.

Число CVE в GNOME выросло, но статистика требует оговорок

Катандзаро приводит собственный подсчёт CVE для проблем, о которых сообщили команде GNOME Security. В 2023 году таких записей было 13, в 2025 году – 97, а к 30 сентября 2026 года – уже 141. Основную причину роста он видит в использовании ИИ, хотя отмечает и улучшение внутреннего учёта: разработчики стали чаще передавать сведения о проблемах для регистрации.

В этой таблице год определяется датой сообщения о проблеме в GNOME, а не годом внутри номера CVE. Поэтому часть идентификаторов CVE-2026 автор учитывает в строке за 2025 год. Проблемы, ещё не получившие CVE, и записи, о которых не сообщили GNOME Security, в подсчёт не входят.

Хотя срез датирован 30 сентября, из-за задержек регистрации Катандзаро считает данные практически полными лишь примерно до 1 сентября. Последняя строка получена умножением значений 2026 года на 4/3: 141 × 4/3 = 188, а 74 × 4/3 после округления дают 99. Это условное приведение неполного периода к годовому масштабу, а не фактический итог или надёжный прогноз.

У дальнейшей статистики есть ещё одно ограничение. С 1 октября Катандзаро прекратил централизованно отслеживать новые проблемы безопасности GNOME, а добровольца для продолжения этой работы не нашлось. В отдельной публикации о запросах CVE он уточнил, что до конца октября продолжит следить за сентябрьскими сообщениями, и предложил сопровождающим самостоятельно обращаться в Red Hat Product Security.

Изменение связано с его планируемым уходом из Red Hat 30 октября. Поэтому ожидаемое им снижение числа новых CVE после прекращения учёта само по себе не будет доказывать, что ошибок стало меньше.

В WebKitGTK основную прибавку дали встроенные библиотеки

Для WebKitGTK автор приводит другую статистику: здесь CVE распределены по году публикации бюллетеня безопасности, а не по времени сообщения в GNOME. За неполный 2026 год он насчитал 305 записей – с учётом бюллетеня WSA-2026-0006 от 29 сентября.

По объяснению Катандзаро, резкий рост целиком связан с ИИ-анализом Skia и ANGLE. WebKit включает эти библиотеки в собственную сборку, поскольку они не рассчитаны на установку в качестве обычных системных библиотек. Поэтому автор учитывает их проблемы наравне с ошибками самого WebKit.

Если исключить Skia и ANGLE, остаётся только 21 CVE за 2026 год – заметно меньше прежних годовых значений. Но такой подсчёт скрывал бы проблемы кода, который всё равно поставляется пользователям в составе движка.

Кроме того, число CVE не равно числу исправленных уязвимостей. По словам Катандзаро, Apple обычно регистрирует CVE для находок внешних исследователей и значительно реже – для ошибок, обнаруженных разработчиками WebKit. Поэтому большой объём исправлений безопасности может не отражаться в этом показателе. Причины прежнего снижения числа CVE и низкого значения за 2016 год автор не устанавливает.

Программу вознаграждений закрыли из-за потока сообщений

Особенно показателен опыт GNOME Bug Bounty Program на платформе YesWeHack. Её финансировала программа Sovereign Tech Resilience немецкого агентства Sovereign Tech Agency. Точную дату открытия Катандзаро не называет, но первая заявка поступила 27 июня 2024 года.

Изначально принимали сообщения только о GLib, glib-networking и libsoup. Ограниченный список должен был помочь справиться с первой для GNOME программой такого рода. Расширить её на остальные проекты не удалось: даже эти компоненты обеспечили слишком большой поток находок.

В 2026 году 122 сообщения поступили менее чем за два месяца. Катандзаро попросил завершить программу, поскольку перестал справляться с ИИ-отчётами. Последнюю заявку подали 23 февраля, но разбор накопившихся сообщений продолжался ещё несколько месяцев: последние отчёты приняли в сентябре, а последнюю награду выплатили 2 октября.

Даже предварительная проверка специалистами YesWeHack не сняла нагрузку с разработчика. В итоге программа выплатила 183 900 евро за 71 уязвимость: 45 в libsoup, 23 в GLib и три в glib-networking. Размеры наград составляли от 500 евро – таких выплат было 16 – до 7500 евро, которые выплатили дважды.

В исходной публикации указан средний размер награды 2662,99 евро, однако он не согласуется с приведёнными общей суммой и числом уязвимостей. Деление 183 900 на 71 даёт 2590,14 евро. Причину этого расхождения автор не поясняет.

Из 298 отчётов 30 закрыли как дубли, ещё 197 отклонили. При этом статус принятой заявки не гарантировал качества текста: некоторые отчёты требовали нескольких раундов исправлений. И наоборот, часть отклонённых сообщений всё же указывала на реальные проблемы безопасности.

Катандзаро связывает низкое качество многих заявок с финансовой мотивацией. По его наблюдению, сообщения без ожидания выплаты, поступающие через обычные трекеры и форму GNOME Security, в целом значительно лучше. Это объясняет, почему он одновременно поддерживает ИИ-аудит и признаёт неудачу конкретной программы вознаграждений.

Что показали проверки libsoup и GLib

По словам Катандзаро, libsoup оказалась заметно менее защищённой, чем он ожидал. Чтобы уменьшить поток заявок и лучше учитывать риск для пользователей GNOME, из программы сначала исключили ошибки отказа в обслуживании, а затем серверный компонент SoupServer.

Во втором случае причиной стали многочисленные ошибки HTTP request smuggling – неоднозначной обработки HTTP-запросов. Автор поясняет, что эти серверные сценарии не представляли угрозы для пользователей GNOME. Но и после сужения условий отчёты продолжали поступать. При этом он считает libsoup теперь существенно более защищённой; обычный трекер продолжает принимать находки без денежных наград.

С GLib оценка сложнее. Многие сообщения показывают, что тестовая программа передаёт API формально допустимые, но маловероятные значения и вызывает сбой. Реальность ошибки не всегда означает доказанную возможность атаки на обычное приложение.

Значительную часть находок составляли переполнения целых чисел, способные привести к переполнению буфера. Для поиска таких проблем Катандзаро предлагает внимательнее использовать предупреждения компилятора:

-Wconversion
-Wint-conversion
-Wsign-compare

Это предложенные им средства выявления подозрительных преобразований и сравнений, а не обещание автоматически устранить все переполнения. По его оценке, некоторые проекты GNOME уже используют -Wsign-compare, тогда как -Wconversion и -Wint-conversion распространены мало.

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

118 находок ИИ в GLib не означают 118 уязвимостей

Отдельный эксперимент провела Red Hat, заказав AISLE Research ИИ-сканирование нескольких проектов GNOME. Более 40% всех результатов пришлось на GLib. Катандзаро предполагает, что это может быть связано с большим числом публичных API, принимающих потенциально недоверенные данные, но не утверждает, что причина установлена.

Сканирование, отнесённое к GLib, выдало 118 предполагаемых уязвимостей. Часть результатов оказалась дублями, и окончательное устранение повторов ещё не завершено. Кроме того, 46 находок относятся к gobject-introspection, преимущественно к обработке typelib.

Typelib описывает, как программа вызывает функции библиотеки, поэтому такие данные изначально должны быть доверенными. По объяснению автора, вредоносная typelib способна вызвать опасное поведение даже без ошибок в её обработчике. Обнаруженные дефекты реальны и заслуживают исправления, но сопровождающие не считают их уязвимостями безопасности.

Только эта группа составляет около 39% от 118 результатов; Катандзаро округляет долю ложных срабатываний до 40%. Вычитать 46 и объявлять оставшиеся 72 подтверждёнными уязвимостями тоже нельзя: проверка остальных сообщений и удаление дублей продолжаются.

Несмотря на это, автор доволен качеством полученных отчётов. Большинство ошибочных классификаций связано с одним неверным пониманием границы доверия, а сами сообщения пригодны для исправления обычных дефектов. Для других результатов он ожидает дальнейших назначений CVE. Ценность эксперимента он видит и в том, что поставщик Linux заранее искал проблемы, вместо того чтобы ждать сообщений внешних исследователей.

Человеческая проверка остаётся необходимой

Катандзаро признаёт типичные недостатки ИИ-отчётов: чрезмерную длину, завышенную оценку опасности, нерелевантные утверждения и отдельные фактические ошибки. Иногда модели даже создают вымышленные трассировки стека; автор приводит такой пример из трекера GEGL. Подготовленный исследователь способен заметить и исправить большую часть этих проблем, но неопытные авторы нередко просто копируют ответ модели.

Нагрузка сохраняется и при корректных находках. Каждую нужно проверить, а предложенное исправление – изучить перед включением в проект. Поэтому полезные отчёты в большом количестве тоже могут перегрузить добровольцев.

Помимо программы наград, Sovereign Tech Resilience финансировала аудит Codean Labs, охвативший проекты GNOME, Flatpak и xdg-desktop-portal. Он выявил в том числе два случая выхода из песочницы Flatpak. Катандзаро не уверен, что ИИ смог бы самостоятельно обнаружить самые важные из этих проблем, и не рекомендует полагаться только на автоматизированное сканирование.

Один из примеров – атака через справочную программу Yelp. Приложение из песочницы могло запустить установленный вне неё Yelp со специально подготовленным файлом справки и передать файлы основной системы на веб-сервер. Автор подчёркивает, что ошибка находилась не в самом Flatpak: значение имело взаимодействие изолированного приложения с программой за пределами песочницы.

При поддержке ИИ-анализа Катандзаро также хочет общаться с людьми, которые понимают свои сообщения. В качестве отправной точки для обсуждения, а не готовой политики, он предлагает:

• Начинающим разработчикам осторожно использовать ИИ для написания кода, чтобы не подменять им обучение.
• Писать необходимые комментарии к коду самостоятельно: по его оценке, современные модели часто создают плохие комментарии.
• Самостоятельно составлять сообщения коммитов. Он допускает, что ИИ может писать их лучше человека, но хочет видеть собственное объяснение автора изменений.
• Не публиковать сгенерированные ответы в обсуждениях ошибок и запросов на слияние так, будто это собственные слова разработчика.

Почему даже Rust не отменяет аудит

Катандзаро распространяет требование принимать ИИ-отчёты и на проекты на Rust. Он признаёт, что язык устраняет большинство проблем безопасности памяти, за исключением возможных ошибок в unsafe-коде, и ожидает на порядок меньше уязвимостей, чем в сопоставимом проекте на C, C++ или Vala. Это его оценка, а не результат приведённого сравнительного исследования.

При этом логические ошибки и другие классы уязвимостей сохраняются. Отдельно он критикует риски цепочки поставок при загрузке зависимостей через Cargo: в проект может попасть библиотека с вредоносным кодом. Такой риск он связывает с менеджерами пакетов языков программирования в целом и считает лучшим доступным подходом отказ от их использования.

Автор идёт дальше и предполагает, что риск вредоносных зависимостей может перевесить пользу от безопасности памяти. Из-за сильной зависимости Rust-кода GNOME от Cargo он рекомендует не выбирать Rust для новых программ GNOME. Это спорная личная рекомендация Катандзаро: она не означает обнаружения вредоносного пакета в GNOME, изменения правил проекта или доказанного превосходства C над Rust по безопасности.

Что эти цифры означают для пользователей

Рост числа зарегистрированных уязвимостей показывает, сколько проблем удалось обнаружить и учесть. По приведённым данным нельзя заключить, что GNOME стал во столько же раз опаснее: на статистику влияют новые инструменты поиска, регистрация CVE и включение сторонних библиотек.

Сам Катандзаро считает фишинг и троянские программы более значимыми повседневными угрозами для пользователей. Это его оценка, но практическая граница понятна: исправление ошибок в библиотеке не защищает от передачи пароля мошенническому сайту или сознательного запуска вредоносного файла.

При этом он признаёт, что раньше недооценивал некоторые проблемы безопасности памяти. Теперь создание эксплойтов с помощью ИИ стало доступнее, и особого внимания, по его мнению, заслуживают ошибки времени жизни объектов и запись за пределами выделенной памяти.

Катандзаро не требует, чтобы добровольцы лично устраняли каждую уязвимость или всегда ставили её выше других задач. Указанные им сроки в закрытых отчётах обозначают дату раскрытия информации, а не обязанность выпустить исправление к этому дню. Работа над безопасностью требует ресурсов, особенно когда код используют крупные компании, не участвующие в его сопровождении.

Обнаружение и исправление ошибок остаётся обычной частью развития GNOME. Например, в обновление GNOME 50.5 включили Epiphany 50.6 с исправлениями внедрения JavaScript при автозаполнении и обхода пути при установке расширений. Эти исправления показывают практическую пользу аудита, но сами по себе не устанавливают, каким инструментом нашли каждую ошибку.

Вывод

Опыт GNOME показывает, что ускорение поиска ошибок увеличивает потребность в людях, которые проверяют результаты и готовят исправления. Пользователям важны качество исправлений и их появление в используемом ПО; число CVE без контекста не даёт полной оценки безопасности. Предложение Катандзаро ставит перед проектами конкретную задачу: принимать полезные находки ИИ и организовать их проверку так, чтобы она оставалась посильной для разработчиков.