GitHub меняет правила bug bounty GitHub: часть находок, которые не тянут на заметный риск, теперь будут вознаграждать не деньгами, а фирменным мерчем. Для русскоязычной IT-аудитории сигнал простой: эпоха, когда можно было принести платформе «почти баг» и рассчитывать хотя бы на небольшой чек, заканчивается.
О новых правилах 15 мая написал GitHub, а как пишет The New Stack, причина не только в желании подкрутить экономику программы. Платформа прямо говорит о резком росте потока слабых и непроверенных репортов, в том числе сгенерированных или оформленных с помощью ИИ. На языке команд, которые и так живут в очередях из тикетов, это означает одно: triage захлебывается, а полезный сигнал тонет в красивом, но пустом тексте.
Что именно меняет GitHub
Суть нововведения не в том, что GitHub отказывается платить багхантеру как классу. Денежные выплаты никуда не исчезают: публично в программе по-прежнему фигурируют награды до 30 тысяч долларов и выше за критические уязвимости. Меняется другое: если репорт не показывает существенного security impact, но все же приводит к исправлению кода или документации, автору дадут не bounty payout, а swag. Проще говоря, худи вместо долларов.
Параллельно GitHub повышает требования к самим отчетам. Теперь компания жестче оценивает три вещи: рабочий proof of concept, демонстрацию реального воздействия и предварительную валидацию находки до отправки. Формула предельно практичная: покажите, что именно можно сломать, какой рубеж безопасности реально преодолевается и почему это не теоретическая конструкция на три экрана текста. Отчеты в стиле «это может привести к...» без воспроизводимого сценария GitHub считает неполными.
Отдельно компания проговаривает позицию по ИИ, и она интереснее, чем привычное «запрещаем нейросети». GitHub не против AI-инструментов в security research и называет их усилителем для исследователя. Но ответственность за качество отчета остается на человеке. Если баг найден с помощью модели, отлично; если в программу прилетает невалидированный вывод сканера или чат-бота, это уже не автоматизация, а мусор, который кто-то должен разбирать вручную.
Почему это важно не только багхантерам
История шире, чем спор о том, платить деньгами или футболками. GitHub пишет, что за последний год объем сабмитов по рынку заметно вырос, а новые инструменты, включая ИИ, снизили порог входа в security research. Звучит демократично, но у любого снижения порога есть обратная сторона: количество людей, умеющих генерировать правдоподобные гипотезы, растет быстрее, чем число специалистов, способных подтвердить их руками. В итоге узким местом становится не поиск уязвимостей, а разбор очереди.
На рынке это уже не теория. В 2026 году проект cURL закрыл свою bug bounty-программу на фоне наплыва AI slop: команда устала тратить время на правдоподобные, но бесполезные отчеты. HackerOne весной тоже приостанавливал прием новых сообщений в рамках Internet Bug Bounty, объясняя решение дисбалансом между числом находок и способностью maintainers их чинить. GitHub на этом фоне выглядит не самым жестким игроком: он не сворачивает программу, а пытается отфильтровать пограничные кейсы экономическим стимулом.
Есть и еще один важный момент: GitHub довольно подробно очертил границу собственной ответственности. Компания напоминает, что платформа живет по модели shared responsibility. Если пользователь сознательно клонирует вредоносный репозиторий, кормит LLM недоверенным контентом или запускает код из сомнительного источника, это не всегда баг платформы. Для исследователей это неприятная, но полезная фиксация правил игры: не вся технически корректная атака будет считаться уязвимостью GitHub, если ключевой шаг делает сам пользователь, добровольно доверяя контенту.
Для разработчиков и продуктовых команд вне GitHub здесь есть вполне прикладной урок. Программы bug bounty больше нельзя проектировать по старой логике, где главным дефицитом был поиск багов. Теперь дефицитный ресурс — внимание команды, которая должна отделить реальную уязвимость от теоретической фантазии, красиво упакованной ИИ. Значит, в правилах программы придется заранее описывать ineligible-категории, требовать PoC, жестко формулировать, где проходит security boundary, и, возможно, по-разному вознаграждать баги и hardening suggestions.
bug bounty GitHub в новой версии — это, по сути, попытка вернуть экономике bug bounty здравый смысл. Деньги оставляют для уязвимостей с реальным ущербом, а все остальное переводят в режим «спасибо, вот мерч». Вопрос теперь в том, станет ли такой подход отраслевым стандартом: если поток AI-assisted отчетов продолжит расти, у многих программ выбор будет небогатый — либо резать выплаты за низкорисковые находки, либо расширять команды triage до размеров, которые финансовый отдел быстро сочтет уязвимостью уже в собственном бюджете.