Основатель и ведущий разработчик Curl Даниэль Стенберг объявил о поэтапном закрытии bug bounty-программы Curl и libcurl на платформе HackerOne. Причина — неконтролируемый рост числа низкокачественных отчетов об уязвимостях, значительная доля которых, по его оценке, сгенерирована с помощью систем искусственного интеллекта.
Почему решение Curl показательно для всей индустрии кибербезопасности
Curl и libcurl — критически важные open source‑компоненты, используемые в огромном количестве приложений, от встроенных устройств до облачных сервисов. Поэтому качество процесса раскрытия уязвимостей вокруг этого проекта напрямую влияет на безопасность экосистемы в целом. Решение отказаться от bug bounty на крупной платформе отражает более широкий тренд: ИИ-генерация отчетов начинает подрывать эффективность традиционных программ вознаграждения.
Как будет закрываться bug bounty-программа Curl на HackerOne
Стэнберг объявил, что закрытие будет происходить в несколько этапов. До 31 января 2026 года проект продолжит принимать отчеты об ошибках через HackerOne, и все уже открытые на тот момент тикеты будут рассмотрены до конца. Однако начиная с 1 февраля 2026 года Curl полностью прекратит прием новых заявок на этой платформе и перейдет на прямую модель раскрытия уязвимостей через GitHub.
От ИИ-отчетов к перегрузке команды безопасности
Проблемы с так называемым «ИИ-слопом» (AI slop — поток поверхностных, слабо обоснованных материалов, сгенерированных нейросетями) в программе Curl начали активно обсуждаться еще в 2024 году. По словам Стенберга, порядка 20% всех отчетов уже тогда генерировались с помощью ИИ, а общий уровень валидности резко упал: в прошлом году .
При этом команда безопасности Curl насчитывает всего семь человек. Каждый отчет требовал участия 3–4 рецензентов и занимал от 30 минут до трех часов на верификацию. В январе 2026 года нагрузка достигла критической отметки: за первые 16 часов одной недели проект получил семь новых отчетов через HackerOne, а к середине месяца команда обработала более 20 — ни один из них не оказался валидной уязвимостью.
«Устранить стимул» для мусорных отчетов
Комментируя решение, Стенберг подчеркивает, что главная цель закрытия программы bug bounty на HackerOne — убрать финансовый стимул, провоцирующий поток бессодержательных отчетов. По его словам, не столь важно, генерируется ли отчет ИИ или пишется вручную, если он не содержит реальной ценности и лишь создает шум, выжигая ресурсы небольшой команды мейнтейнеров.
При этом разработчик трезво оценивает ситуацию и признает, что полный уход с HackerOne не остановит поступление слабых отчетов. Однако для малого open source-проекта с ограниченным числом активных участников это шаг, который он считает необходимым для сохранения работоспособности проекта и ментального здоровья команды.
Данные о всплеске отчетов и новая политика security.txt
Чтобы обосновать свою позицию, Стенберг опубликовал примеры того, что он относит к ИИ-слопу, а также данные, демонстрирующие резкий рост количества отчетов по Curl в 2025 году по сравнению с другими open source-проектами на HackerOne. В Mastodon он отмечает, что подобного скачка у ряда сопоставимых проектов не наблюдалось, что указывает на специфическую проблему именно этой программы bug bounty.
Одновременно команда обновила файл security.txt — это стандартный текстовый файл в корне сайта или репозитория, в котором описываются официальные каналы связи по вопросам безопасности. В новой версии Curl четко указано, что проект больше не выплачивает денежные вознаграждения за найденные уязвимости и не содействует получению компенсаций от третьих сторон. Более того, авторы прямо предупреждают: отправители откровенно мусорных отчетов могут быть заблокированы и публично высмеяны.
Что будет вместо HackerOne и как это повлияет на исследователей
Начиная с февраля 2026 года, разработчики предлагают переходить на прямую модель responsible disclosure через GitHub. Это означает, что исследователи будут направлять отчеты напрямую мейнтейнерам, минуя посредника в виде платформы bug bounty. Для добросовестных специалистов это, с одной стороны, уменьшает административные барьеры, с другой — убирает финансовый мотив, который для многих был ключевым.
С 2019 года через HackerOne и инициативу Internet Bug Bounty за найденные уязвимости в Curl и libcurl было выплачено более 90 000 долларов за 81 подтвержденную уязвимость. Сворачивание программы означает смену акцента: от монетизации поиска багов — к сотрудничеству ради устойчивости экосистемы, без обязательной финансовой составляющей.
Уроки для bug bounty-программ в эпоху искусственного интеллекта
История Curl иллюстрирует ключевой риск для современных bug bounty-программ: массовые ИИ-сгенерированные отчеты могут разрушить экономику процесса. Проверка каждого сообщения требует участия квалифицированных специалистов, тогда как генерация псевдоотчетов стала почти бесплатной и мгновенной. Без дополнительных фильтров и порогов входа это ведет к лавинообразному росту шума.
Практически это означает, что операторам программ — как коммерческим компаниям, так и open source-проектам — стоит внедрять механизмы предварительной фильтрации: более строгие форматы отчетов, требования к воспроизводимым PoC, минимальные критерии уязвимости, а также неочевидные для ИИ проверочные вопросы. Кроме того, все более востребованными становятся закрытые или многоуровневые программы bug bounty с допуском только проверенных исследователей.
Для сообщества кибербезопасности это сигнал к пересмотру ожиданий: ИИ способен помогать в анализе кода и поиске паттернов уязвимостей, но при отсутствии экспертизы и ответственности превращается в инструмент массового спама. Эффективная защита зависит не от количества отправленных отчетов, а от качества анализа и устойчивых процессов взаимодействия между исследователями и разработчиками.
Ситуация вокруг Curl показывает, насколько хрупки ресурсы даже у широко используемых open source-проектов. Организациям стоит внимательно оценить собственные программы bug bounty, обновить политики responsible disclosure и обучить команды работе с ИИ-инструментами так, чтобы они усиливали, а не подрывали безопасность. Следите за обновлениями Curl и другими кейсами — они дают практические ориентиры, как выстраивать устойчивые процессы кибербезопасности в новых условиях.
