Разработчик одной из самых распространенных утилит в мире открытого ПО – cURL – решил закрыть программу денежных вознаграждений за найденные уязвимости. Причина не в отсутствии интереса исследователей к безопасности и не в экономии бюджета, а в лавине бессмысленных отчетов, сгенерированных нейросетями. Поток «автоматизированного бреда» оказался настолько объемным, что команда больше не видит смысла продолжать Bug Bounty в прежнем виде.
Что такое cURL и почему это вообще важно
cURL – это консольная утилита и библиотека для работы с сетевыми протоколами. Она позволяет отправлять запросы к серверам по HTTP(S), FTP, LDAP, SMTP и множеству других протоколов, используя URL-синтаксис.
Фактически, cURL можно встретить почти везде: в подавляющем большинстве дистрибутивов Linux, в macOS, в Windows 10 и 11. Миллионы скриптов, интеграций, CI/CD-пайплайнов и приложений завязаны на libcurl – библиотеку, которая является сердцем проекта. Сам бинарник curl выступает как обертка над libcurl и предоставляет удобный интерфейс командной строки.
Исходный код и библиотеки распространяются по свободной лицензии curl, что обеспечивает прозрачность разработки и дает возможность включать cURL в огромное количество коммерческих и некоммерческих решений.
Как работала программа Bug Bounty для cURL
Программа по выплатам за найденные уязвимости (Bug Bounty) была запущена в апреле 2019 года. Через нее независимые специалисты по безопасности и разработчики могли сообщать о найденных дырах в безопасности cURL и получать за это денежное вознаграждение.
Общение с исследователями шло через специализированную платформу, где принимались отчеты, проводилась верификация проблем, принимались решения о размере выплат, а также велась история найденных уязвимостей.
За первые годы работы программы было выплачено более 70 тысяч долларов, а к маю 2025 года общая сумма вознаграждений достигла примерно 86 тысяч долларов. Для проекта с открытым кодом, который не стоит за крупной корпорацией, это весьма значимая сумма.
К началу 2024 года разработчики получили 415 отчетов об уязвимостях. Из них:
- 64 действительно относились к реальным и впоследствии подтвержденным проблемам безопасности;
- 77 описывали полезные баги, не влияющие напрямую на безопасность, но все равно важные для стабильности и качества продукта;
- остальные около 66% оказались совершенно бесполезными – либо содержали ошибки понимания, либо описывали несуществующие угрозы, либо повторяли уже известную информацию.
Каждый такой отчет требовал ручной проверки и анализа. И это – время ключевых разработчиков, без которых проект не развивается.
Нейросети изменили правила игры – и сломали баланс
Ситуация резко ухудшилась с массовым распространением генеративных моделей. Современные языковые модели научились «по запросу» генерировать развернутые отчеты об уязвимостях, снабжая их псевдо-техническими деталями, примерами эксплойтов и сложной терминологией.
На бумаге такие отчеты выглядят солидно. На деле же многие из них – продукт так называемых «галлюцинаций» ИИ: модель уверенно описывает несуществующие уязвимости, некорректно понимает логику работы кода или придумывает конфигурации, которые в реальности невозможны.
Глава проекта cURL Даниэль Стенберг впервые публично обратил внимание на эту проблему в начале 2024 года. Он тогда жаловался, что доля отчетов, очевидно сгенерированных ИИ, быстро растет, а их качество крайне низкое. Тем не менее Стенберг не спешил рубить с плеча: к середине 2025 года он уже всерьез задумывался о закрытии Bug Bounty, но отложил решение, поскольку среди ИИ-помощи все же стали попадаться несколько действительно ценных находок. Часть исследователей использовала нейросети грамотно – как вспомогательный инструмент, а не как автоматический генератор спама.
«Последняя капля»: неделя из семи ложных тревог
Перелом наступил в январе 2026 года. По словам Стенберга, всего за одну неделю в рамках программы поступило семь отчетов, ни один из которых нельзя было классифицировать как реальную уязвимость. Все они потребовали от него ручного анализа и «довольно много времени», хотя в итоге оказались либо ошибочными, либо бессодержательными.
Именно после этого он принял окончательное решение: программу Bug Bounty для cURL нужно закрывать. В середине января он сообщил об этом в рассылке проекта, объяснив, что текущий поток низкокачественных багрепортов создает неприемлемую нагрузку на команду безопасности.
А уже позже Стенберг закрепил решение технически: на GitHub в репозитории cURL появился коммит с файлом `BUG-BOUNTY.md` и однозначным заголовком: «we stop the bug-bounty end of Jan 2026». Это означает, что с февраля 2026 года исследователи больше не смогут рассчитывать на денежное вознаграждение за находки в cURL в рамках прежней программы.
Что именно хочет отсечь разработчик
Стенберг подчеркивает: цель – не наказать добросовестных специалистов и не закрыться от внешней помощи, а избавиться от огромного слоя «шума». Речь идет о тех, кто:
- массово генерирует отчеты с помощью нейросетей без понимания кода;
- не проводит реальных проверок и воспроизведения описываемой «уязвимости»;
- шлет в проект абстрактные или очевидно ошибочные сценарии просто ради потенциального вознаграждения.
Закрытие Bug Bounty, по его замыслу, должно уменьшить мотивацию таких людей и оставить в поле только тех, кто действительно заинтересован в качестве продукта и готов тратить время на глубокий анализ.
ИИ: инструмент или источник проблем?
Показательно, что Стенберг изначально не выступал против использования ИИ как такового. Он признавал, что нейросети могут быть полезны:
- в подготовке черновиков отчетов;
- в анализе логов и структур данных;
- в помощи с пониманием чужого кода;
- в генерации тест-кейсов и сценариев проверки.
Но – только если человек остается в центре процесса, проверяет каждый вывод модели, воспроизводит уязвимости вручную и берет на себя ответственность за конечный результат. Когда же ИИ становится единственным «автором» бага, а человек лишь нажимает «отправить», качество неизбежно обрушивается.
Проблема cURL наглядно демонстрирует этот конфликт: машинная генерация масштабирует не только реальную продуктивность, но и «высокотехнологичный спам».
Почему разработчики не могут просто «игнорировать» плохие багрепорты
Стороннему наблюдателю может показаться, что решение простое: если отчет явно плохой – не тратить время, отклонять сразу. Но в сфере безопасности так не работает.
Любой отчет потенциально может скрывать редкий, но критический кейс, упущенная проверка которого обернется серьезной уязвимостью. Именно поэтому команды безопасности вынуждены:
- внимательно читать каждый репорт;
- проверять указанные версии, параметры компиляции, окружение;
- воспроизводить сценарии, указанные в отчете;
- документировать выводы для истории и внутренних процессов.
Даже откровенно слабый и «подозрительный» отчет все равно съедает часы человека, который мог бы в это время исправлять реальные ошибки, развивать функциональность или заниматься архитектурой безопасности.
Когда доля таких отчетов среди всех поступающих сообщений переваливает за две трети – как это случилось в cURL – программа Bug Bounty из инструмента повышения безопасности превращается в фактор торможения развития.
Что будет с безопасностью cURL без Bug Bounty
Отказ от денежных выплат не означает отказ от исправления уязвимостей. Проект по‑прежнему открыт для сообщений об ошибках и проблемах безопасности. Разработчики продолжают принимать отчеты, но теперь это будет происходить без формализованной системы вознаграждений.
Скорее всего, акцент сместится:
- в сторону внутренних процессов аудита кода;
- на взаимодействие с проверенными исследователями, которые уже зарекомендовали себя;
- на реагирование на сообщения от разработчиков и компаний, интегрирующих cURL в свои продукты.
Такой подход может сократить поток случайных и низкокачественных обращений, оставив только тех, кому действительно важна стабильность и безопасность проекта.
Возможные альтернативы: что могли бы сделать иначе
Ситуация вокруг cURL поднимает более широкий вопрос: как адаптировать программы Bug Bounty к эпохе ИИ? Теоретически у проекта было несколько альтернатив:
1. Ввести пороговый фильтр
Например, требовать обязательного минимального доказательства: рабочий exploit, PoC-код, дампы памяти, логи воспроизведения. Но и это не гарантировало бы защиты от ИИ, который тоже способен генерировать «правдоподобный» код.
2. Ограничить количество отчетов от одного участника
Это снизило бы поток массового спама, но ударило бы и по активным исследователям, которые находят много реальных уязвимостей.
3. Перевести выплаты в формат «по приглашению»
Платить вознаграждения только проверенным экспертам. Однако такой подход частично убивает открытую природу Bug Bounty и рискован тем, что «новые звезды» могут остаться за бортом.
4. Добавить автоматизированные предфильтры
Парадоксально, но бороться с ИИ мог бы помочь другой ИИ – например, модель, обученная на реальных и фейковых багрепортах, способная отсекать заведомо бессмысленные. Но разработка и поддержка такой системы тоже требует ресурсов, которых у небольшого опенсорс-проекта может не быть.
Стенберг выбрал самый радикальный, но наименее затратный в моменте вариант – полностью закрыть программу выплат.
Чему эта история учит разработчиков и исследователей
История с cURL демонстрирует несколько важных тенденций, которые неизбежно затронут почти все крупные проекты с открытым кодом:
- ИИ уже сейчас меняет экосистему безопасности, но не всегда в лучшую сторону. Если не выстроить правильные фильтры и процессы, количество мусорных отчетов будет расти.
- Ресурс человеческого времени – ключевой. Даже самый важный и широко используемый проект может отказаться от полезного инструмента (Bug Bounty), если он начнет отнимать слишком много внимания у разработчиков.
- Качество выше количества. Эпоха массовых автоматических репортов может привести к переоценке ценности ручного, экспертного труда и реальной проверки гипотез.
- Добросовестным исследователям придется адаптироваться. Придется доказывать, что за отчетами стоит человек, глубокое понимание кода и реальная работа по воспроизведению багов, а не просто пара запросов в нейросеть.
Что дальше для cURL и открытого ПО
cURL – не единственный и явно не последний проект, который столкнулся с подобной проблемой. Чем популярнее продукт, тем выгоднее для охотников за вознаграждениями «атаковать» его программой Bug Bounty, используя ИИ для масштабирования своих попыток.
Можно ожидать, что:
- некоторые проекты пересмотрят условия участия в Bug Bounty, ужесточат критерии приемки отчетов и требования к доказательствам;
- появятся новые форматы сотрудничества с исследователями, где будет четко разделено: что делает машина, а за что по‑прежнему отвечает человек;
- роль устойчивых, хорошо выстроенных внутренних процессов безопасности возрастет, чтобы не зависеть исключительно от внешнего поиска уязвимостей.
Для пользователей же главный вывод один: несмотря на закрытие программы Bug Bounty, cURL остается живым, активно развиваемым и крайне важным компонентом современной ИТ-инфраструктуры. Но эпоха легких денег за «сырой» отчет, написанный в помощь нейросетью без реальной проверки, судя по всему, подходит к концу.
