Нейросети научились находить баги. И это худшее, что случилось с open-source
23 января 2026 года Даниэль Стенберг, создатель cURL — той самой библиотеки, которая загружает половину интернета, — опубликовал пост, который встряхнул сообщество безопасности. Он закрывает bug bounty программу проекта. Причина? Не взломы, не сложные атаки, а банальный, но бесконечный поток AI-спама.
За последние три месяца 95% репортов в cURL были сгенерированы нейросетями — в основном Claude 3.5 Sonnet и GPT-4.5 Turbo. Большинство из них либо описывали несуществующие уязвимости, либо пересказывали известные проблемы с ошибками в коде PoC.
Как выглядит AI-репорт глазами мейнтейнера
Представьте: вы получаете 50 писем в день. Каждое начинается с "Я проанализировал код cURL с помощью DeepSeek Coder V2 и обнаружил potential buffer overflow". Дальше следует технически грамотный, но абсолютно бессмысленный анализ. LLM находит паттерн, похожий на уязвимость, но не понимает контекста — защитных механизмов, проверок, архитектуры.
"Это как если бы студент-первокурсник, прочитав одну книгу по безопасности, начал бы писать тебе каждый день, что твой код 'может быть небезопасным'", — объясняет Стенберг в своем посте. Только этот "студент" никогда не устает и может генерировать тысячи таких писем.
Психическое здоровье разработчика против экономики внимания
Здесь важны цифры. Bug bounty программа cURL существовала 8 лет. За это время было выплачено около 70 000 долларов за реальные уязвимости. В среднем — одна значимая находка в квартал.
Сейчас Стенберг тратит 15-20 часов в неделю только на сортировку и ответы на AI-репорты. Это время, которое должно уходить на разработку новой функциональности, поддержку пользователей, исправление реальных багов. Вместо этого — бесконечная переписка с ботами, которые "учатся на обратной связи".
Эффект домино: кто следующий?
cURL — не единственный проект. OpenSSL, Linux kernel, PostgreSQL — все они видят аналогичный рост низкокачественных репортов. Разница в том, что у cURL один основной мейнтейнер. У ядра Linux — сотни. Но даже они начинают жаловаться на шум.
Что происходит, когда мейнтейнер устает? Проект замирает. Баги не фиксятся. Уязвимости накапливаются. Вспомните историю с критической дырой в llama.cpp — там тоже был один основной разработчик, который мог пропустить что-то важное в потоке мусора.
Почему AI так плохо ищет баги в реальном коде?
Нейросети 2025-2026 годов (те же Claude 3.5 Sonnet, GPT-4.5 Turbo, Gemini 2.0) отлично генерируют код. Они понимают синтаксис, паттерны, могут даже писать unit-тесты. Но безопасность — это не про синтаксис. Это про контекст, про edge cases, про понимание того, как код работает в реальном мире.
- AI видит malloc() без free() и кричит "memory leak!". Но не видит, что память освобождается в другом месте через custom allocator.
- Находит strcpy() и генерирует репорт о buffer overflow. Не замечает, что размер буфера проверяется за три строки до этого.
- Видит user input, идущий в системный вызов, и пишет про command injection. Пропускает санитизацию и escaping.
Это как если бы вы дали студенту-медику учебник по анатомии и отправили его делать операцию на сердце. Теория есть, практики — ноль.
Что делают хакеры? Они адаптируются
Пока мейнтейнеры тонут в AI-спаме, реальные исследователи безопасности нашли обходной путь. Они перестали использовать стандартные bug bounty платформы. Вместо этого — приватные каналы, Telegram-группы, прямые сообщения.
Как в случае с AI-фишингом, где хакеры использовали легальные фреймворки для атак, здесь тоже работает принцип "найди тихую воду". Если официальный канал забит мусором — иди в обход.
Результат? Мейнтейнеры получают меньше качественных репортов. Исследователи теряют деньги (неофициальные каналы редко платят). Безопасность всех пользователей снижается.
| Проект | Рост AI-репортов (2024-2026) | Реакция |
|---|---|---|
| cURL | +1200% | Закрытие bug bounty программы |
| OpenSSL | +850% | Введение строгой премодерации |
| Linux Kernel | +650% | Требование видео-PoC для всех репортов |
| PostgreSQL | +720% | Автоматическая фильтрация по паттернам AI-текста |
Можно ли отличить AI-репорт от человеческого?
Теоретически — да. На практике — всё сложнее. Современные LLM (особенно Gemini 2.0 с его режимом "human-like writing") научились имитировать стиль реальных исследователей. Они добавляют личные детали ("я нашёл это, когда тестировал наш внутренний продукт"), делают ошибки правописания специально, даже вставляют шутки.
Детекторы вроде GPTZero или Originality.ai дают точность около 85-90%. Но 10% ложных срабатываний — это уже десятки человеческих репортов, отправленных в спам. А ложные отрицания? AI-репорт, пропущенный как человеческий, заставляет мейнтейнера тратить часы впустую.
Есть ли решение? Или мы проиграли?
Сообщество предлагает несколько подходов, но все они — паллиативы, а не лекарства:
- Капчи для репортов. Да, серьёзно. Некоторые проекты начали требовать решение капчи перед отправкой bug report. Унизительно для исследователей, но работает.
- Требование видео-демонстрации. Linux kernel пошёл этим путём. Хочешь сообщить об уязвимости — запиши видео, где ты её эксплуатируешь. AI пока не умеет генерировать видео с экраном терминала.
- Плата за репорт. Экстремальная мера: небольшая плата (5-10$) за каждый репорт, возвращаемая, если уязвимость подтверждается. Снижает поток спама, но отсекает и бедных исследователей.
- AI-фильтры на стороне проектов. Как AprielGuard для LLM-агентов, но для bug bounty. Пока работают плохо — слишком много false positives.
Настоящее решение? Его нет. Потому что корень проблемы — в экономике. Обучить LLM на публичных данных об уязвимостях стоит копейки. Отправить тысячу репортов — ещё меньше. А один успешный репорт может принести тысячи долларов. Математика простая.
Что будет с open-source безопасностью дальше?
Сценарий первый — пессимистичный. Больше проектов закроют bug bounty программы. Мейнтейнеры уйдут в приватные репозитории или коммерческие версии. Безопасность ухудшится, потому что меньше глаз смотрят на код. Уязвимости вроде той RCE в OpenCode будут находиться реже, а эксплуатироваться — чаще.
Сценарий второй — адаптивный. Появятся специализированные платформы с человеческой проверкой каждой заявки. Что-то вроде "только для избранных". Это создаст элитный клуб исследователей безопасности и убьёт демократичность open-source.
Сценарий третий — технологический. Кто-то создаст AI, который фильтрует AI-спам. Или научит LLM лучше понимать контекст кода. Проблема в том, что это гонка вооружений. Каждый новый фильтр взламывается через месяц.
Самая страшная часть этой истории — она создаёт прецедент. Если cURL, один из самых важных проектов в истории интернета, не справился с AI-спамом, что говорить о меньших проектах? Node.js, Redis, nginx — все они в зоне риска.
Что делать, если вы мейнтейнер open-source проекта в 2026 году?
Не повторяйте ошибку cURL. Закрывать программу — последнее дело. Вместо этого:
- Введите обязательное требование: работающий PoC для каждой уязвимости. Не "я думаю, что здесь overflow", а "вот код, который крашит программу".
- Настройте автоматическую фильтрацию по ключевым фразам ("potential", "might be", "could possibly"). 90% AI-репортов содержат эти слова.
- Создайте приватный канал для проверенных исследователей. Как в старые добрые времена, когда безопасность была клубом для своих.
- Рассмотрите bounty-платформы с человеческой модерацией вроде Huntr или Intigriti. Они дороже, но экономят ваше время.
И главное — не сдавайтесь. Потому что следующий шаг после закрытия bug bounty — это когда хакеры находят реальную уязвимость, но не сообщают о ней. А продают в даркнете. Как в истории с Copilot-фишингом, где одна ссылка могла слить весь ваш код.
AI не убил bug bounty. Он убил его демократичную версию. Теперь это будет игра для профессионалов с репутацией и доступом. Хуже всего то, что так было всегда — просто раньше мы делали вид, что это не так.
