GitHub обновляет правила программы bug bounty, чтобы повысить качество заявок, уточнить границы ответственности и скорректировать вознаграждения за малозначимые находки. Как подчёркивает компания, цель изменений — усилить защиту платформы и поддержать исследователей, которые проводят глубокий анализ.
По данным GitHub, за последний год объём отчётов о уязвимостях значительно вырос, в том числе за счёт использования ИИ-инструментов. Это привело к наплыву сообщений без подтверждённого влияния на безопасность: без работающего proof-of-concept, с чисто теоретическими сценариями атак или с проблемами, которые уже перечислены в списке неподлежащих вознаграждению.
Компания подчёркивает, что не возражает против применения ИИ в исследованиях. GitHub сам использует ИИ в собственных программах безопасности и поддерживает внешних экспертов, которые делают то же самое. Ключевое требование остаётся прежним: каждая находка должна быть проверена исследователем, воспроизведена и сопровождается рабочим proof-of-concept. Автоматический вывод ИИ или сканера без валидации и демонстрации реального воздействия не будет считаться полноценной заявкой.
GitHub просит делать отчёты краткими и структурированными. В «идеальный» отчёт должны входить: краткое описание проблемы, чёткие шаги для воспроизведения с доказательствами и объяснение влияния уязвимости — что именно может сделать атакующий. Длинные теоретические описания, большой объём фона или текст, сгенерированный ИИ без фактической нагрузки, затрудняют разбор и замедляют реакцию команды.
Отдельно GitHub поясняет границы безопасности платформы. Многие отчёты описывают ситуации, когда пользователь самостоятельно взаимодействует с заведомо подозрительным контентом: клонирует потенциально вредоносный репозиторий, открывает специально подготовленный файл или просит ИИ проанализировать непроверенный код. В таких случаях точкой разграничения ответственности выступает решение пользователя доверять этому контенту, и подобные сценарии обычно не считаются обходом защитных механизмов GitHub.
Компания напоминает, что использует автоматические и ручные механизмы для обнаружения и обработки вредоносного контента, однако платформа строится на модели разделения ответственности. Пользователи обязаны оценивать риск при работе с чужим кодом и материалами. При этом, если исследователь находит способ обойти фактический контроль безопасности без активного доверия со стороны жертвы, такие случаи считаются самыми ценными находками.
GitHub призывает опытных исследователей продолжать текущую практику: для них по сути меняются только сроки обработки заявок — они должны сократиться за счёт фильтрации «шума». Новым участникам программы рекомендуют внимательно изучить описание охвата, список неподходящих для выплаты случаев и подготовить рабочий proof-of-concept перед отправкой отчёта.
От тех, кто сейчас делает упор на количество отчётов, GitHub ожидает перехода к глубине анализа. По словам компании, одна хорошо проработанная и подтверждённая уязвимость ценится выше, чем десяток предположительных находок. Наибольшие выплаты получают исследователи, которые уходят в детали и демонстрируют серьёзное влияние на безопасность.
GitHub уточняет подход к малозначимым, но полезным находкам. Если отчёт не показывает серьёзный риск, но приводит к улучшению кода или документации, вместо денежного вознаграждения компания будет благодарить исследователей фирменным мерчем. Это позволит сфокусировать бюджет программы на уязвимостях с максимальным воздействием, при этом сохранить признание вклада за усиление защиты и уточнение документации.
В GitHub заявляют, что стремятся сделать свою bug bounty программу одной из самых сильных в индустрии — как для исследователей, так и для безопасности платформы. Для этого компания обещает ускорить разбор отчётов, улучшить коммуникацию и гарантировать, что валидные находки получают должное внимание и справедливое вознаграждение. При этом GitHub подчёркивает, что работа исследователей напрямую повышает безопасность более чем 180 млн разработчиков, использующих платформу, и компания высоко ценит этот вклад.
Источник: материалы компании GitHub.
