GitHub объявил о введении дневных лимитов на количество приватных отчетов об уязвимостях, которые один аккаунт может отправить в репозиторий. Изменение, опубликованное в официальном changelog 1 октября 2026 года, направлено на борьбу с растущим потоком низкокачественных и автоматизированных сабмишенов, которые забивают очередь мейнтейнеров open-source проектов.
«Это помогает защитить вас от массовых и автоматизированных отправок, в то время как легитимные исследователи все еще могут связаться с вами», — говорится в анонсе GitHub.
Проблема спама в баг-баунти и open-source
Проблема, которую решает GitHub, не нова. Мейнтейнеры популярных open-source репозиториев регулярно получают десятки и сотни отчетов об уязвимостях, значительная часть которых оказывается ложными срабатываниями, автоматически сгенерированными скриптами, или откровенным спамом. Это создает высокую когнитивную нагрузку на мейнтейнеров, которые вынуждены вручную фильтровать входящие заявки, отвлекаясь от разработки и реальных уязвимостей.
Введение rate limits — это прагматичное, хотя и не лишенное противоречий, решение. С одной стороны, оно снижает шум. С другой — может ограничить исследователей, которые используют автоматизированные инструменты для первичного скрининга и массового поиска уязвимостей в экосистеме.
Как это работает
Согласно документации, лимиты применяются к количеству новых приватных отчетов, которые один аккаунт может отправить за день. Ограничение действует как на уровне отдельного репозитория, так и на уровне всего GitHub. Точные числовые значения лимитов в changelog не раскрываются — предполагается, что они могут динамически корректироваться платформой для баланса между защитой мейнтейнеров и доступностью для исследователей.
Настройка доступна в разделе Advanced Security настроек репозитория. Для ее изменения необходимо перейти в Settings, выбрать Advanced Security и нажать Settings рядом с опцией «Private vulnerability reporting».
Функция доступна для публичных репозиториев с включенным приватным репортингом уязвимостей на всех тарифных планах GitHub: Free, Pro, Team и Enterprise Cloud. Это означает, что даже небольшие open-source проекты, не имеющие платной подписки, получают защиту от спама.
Контекст: безопасность open-source экосистемы
Введение лимитов — лишь один из элементов более широкой стратегии GitHub по повышению безопасности цепочки поставок ПО. Платформа уже предлагает ряд инструментов, входящих в пакет GitHub Code Security: сканирование кода с помощью CodeQL, Copilot Autofix для автоматического исправления уязвимостей, AI Scan для поиска уязвимостей в языках, не покрываемых CodeQL, и автоматические триажные правила для Dependabot.
Одновременно с этим растет роль независимых инструментов оценки безопасности, таких как OpenSSF Scorecard, который позволяет автоматически оценивать репозитории по ряду хейристик безопасности (от поддержки до проверки подписей коммитов) и присваивать им оценку от 0 до 10. Введение rate limits на приватные репорты можно рассматривать как еще один шаг к снижению «шума» и повышению эффективности этих процессов.
Что это значит для мейнтейнеров и исследователей
Для мейнтейнеров open-source проектов изменение означает снижение операционной нагрузки. Вместо того чтобы тратить время на отсев автоматических заявок, они могут сосредоточиться на верификации и исправлении реальных уязвимостей. Это особенно критично для проектов с одним-двумя активными мейнтейнерами, где каждый час на счету.
Для исследователей безопасности, особенно тех, кто использует автоматизированные сканеры и фаззеры, изменение может потребовать пересмотра тактики. Массовый прогон инструментов с автоматической отправкой отчетов на все публичные репозитории GitHub станет менее эффективным. Вместо этого придется либо использовать более целенаправленные методы, либо интегрироваться с другими каналами коммуникации, например, через issue трекеры или прямые контакты.
Практическая проверка: если вы мейнтейнер репозитория, рекомендуем зайти в настройки Advanced Security и проверить, включена ли опция Private vulnerability reporting, а также ознакомиться с текущими лимитами. Если вы исследователь — стоит протестировать, как новые лимиты влияют на ваши рабочие процессы, и при необходимости адаптировать скрипты для более редкой и качественной отправки отчетов.
Ограничения и неопределенности
На данный момент GitHub не опубликовал точные числовые значения rate limits, что затрудняет их независимую верификацию. Остается неясным, как лимиты будут применяться к аккаунтам организаций и команд, а также будут ли они различаться для репозиториев с разным уровнем активности. Также не раскрыт механизм апелляций для исследователей, которые могут случайно превысить лимит при легитимной работе над крупным проектом.
Тем не менее, направление движения понятно: платформы стремятся к балансу между открытостью для исследователей и защитой мейнтейнеров от информационного шума, который становится все более серьезной проблемой по мере роста популярности open-source.
