Похоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного Хаоса. Об этом в своём блоге пишет Daniel Stenberg - создатель и ведущий разработчик проекта curl. В конце прошлого года он показывал статистику багрепортов на HackerOne: подтверждённых уязвимостей становилось меньше, а общее число репортов при этом росло, в основном за счёт низкокачественной AI-генерёнки. Ситуация усугубилась в начале 2026 года до той степени, что 1 февраля curl закрыли свою баг-баунти программу на HackerOne и начали принимать репорты только на GitHub. Но спустя месяц они вернулись на HackerOne ("как только поняли, что GitHub недостаточно хорош") и обнаружили, что характер сдаваемых репортов о проблемах безопасности изменился:
📈 Больше объём, выше качество. Проблема со slop-ом больше не актуальна. Частота поступления репортов выше, чем когда-либо. В последнее время она примерно в два раза выше, чем в 2025 году, который и так более чем вдвое превышал предыдущие годы. Качество выше. Доля подтверждённых уязвимостей вернулась на уровень до эпохи AI в 2024 году и даже превысила его примерно на 15-16%. Кроме того, значительно выросла доля репортов с багами, а не с уязвимостями.
🤖 Почти каждый репорт сейчас в той или иной степени формируется с использованием AI. Это видно по формулировкам, стилю изложения и по тому, что даже повторные репорты об уже известной проблеме выглядят тщательно проработанными ("and also by the fact that they now easily get very detailed duplicates"). Люди вручную не могут так писать. Однако разница по сравнению с прошлым в том, что сейчас большинство таких репортов очень высокого качества.
📊 Такая картина не только с curl. Daniel Stenberg провёл быстрый неформальный опрос в Mastodon, чтобы выяснить, наблюдают ли другие open source проекты аналогичные тенденции. И, как оказалось, да. Представители ряда проектов подтвердили, что также фиксируют данный тренд. Речь о Apache HTTP Server, BIND, curl, Django, Elasticsearch Python client, Firefox, git, glibc, GnuTLS, GStreamer, Haproxy, Immich, libssh, libtiff, Linux kernel, OpenLDAP, PowerDNS, python, Prometheus, Ruby, Sequoia PGP, strongSwan, Temporal, Unbound, urllib3, Vikunja, Wireshark, wolfSSL… Разумеется, конкретные показатели и масштабы различаются, однако это указывает на то, что явление не является специфичным для какого-либо одного проекта. Daniel Stenberg предполагает, что этот список проектов - просто случайная выборка тех, кто увидел его опрос. Проектов наверняка больше.
💥 Взрывной рост количества уязвимостей. Когда команда curl выпустит curl 8.20.0, в конце апреля 2026 года, там пофиксят как минимум шесть новых уязвимостей. Если предположить, что тренд сохранится хотя бы до конца года, а Daniel Stenberg считает это разумным предположением, то в этом году проект curl пофиксит рекордное количество CVE. В 2026 году может быть опубликовано около 50 уязвимостей curl. Что-то подобное должно ожидаться и в других проектах, т.к. тренд универсальный.
Что будет дальше?
🔻 Уязвимости в коде продолжат активно выявлять, т.к. разработчики продолжат косячить при исправлении багов и добавлении новой функциональности.
🔻 Некоторые эксперты предполагают, что с AI ресёрчем и репортингом через несколько лет наступит плато, как было с фаззинг-тестированием. В настоящее время остаётся лишь наблюдать за дальнейшей эволюцией этого процесса.
🔻 Данная лавинообразная динамика, вероятно, ещё больше усилит нагрузку на мейнтейнеров. Ряду проектов будет сложно справляться с ростом бэклога без привлечения дополнительной поддержки.
🔻 Можно предположить, что в текущих условиях это также создаёт благоприятные возможности для злоумышленников: используя аналогичные инструменты, они могут находить значительное количество проблем быстрее, чем у проектов появятся ресурсы для их устранения.
🔻 В дальнейшем всем пользователям потребуется обновляться до новых исправленных версий пакетов, что, как ожидается, может занять значительное время.
Таким образом, отрасль, вероятно, ожидает период повышенной нестабильности.
От себя могу добавить, что рост количества исправляемых CVE в Linux-софте (не только в ядре!) виден и в рамках Linux Patch Wednesday. В апреле количество CVE было максимальным (1035) за всё время (май 2024 года исключаем, там высокое значение было связано с изменением алгоритма). Будем наблюдать и анализировать. 😉