1 октября 2026 года GitHub объявил об изменениях в закрытой отправке сообщений об уязвимостях — Private Vulnerability Reporting. Платформа добавила структурированные формы и ограничения на число новых отчётов. Обе меры относятся к публичным репозиториям, в которых владельцы включили этот канал связи. Их задача, по объяснению GitHub, — помочь сопровождающим проектов разбирать сообщения, в том числе на фоне роста числа низкокачественных автоматических отчётов.
Какие сведения теперь запрашивает форма
В анонсе структурированных форм от 1 октября GitHub перечисляет четыре обязательных поля стандартного шаблона: краткое описание, подробности, подтверждение воспроизводимости и влияние проблемы. Для поля с подтверждением воспроизводимости установлен минимум в 150 символов. Ответы объединяются в описание закрытого уведомления об уязвимости, чтобы участники обсуждения получали сведения в одном месте.
Сопровождающие могут настроить собственную форму через файл .github/VULNERABILITY_REPORT.yml в основной ветке репозитория. Общий шаблон также можно разместить в специальном репозитории .github организации или учётной записи. Если пользовательская форма некорректна, применяется стандартная. Это позволяет задавать требования к первичному сообщению, не оставляя исследователя без рабочего способа его отправить.
Среди дополнительных настроек — требование указать категорию CWE. В интерфейсе появляется отметка об использовании ИИ при поиске проблемы или составлении отчёта. Это сообщение самого автора, а не автоматическое заключение о качестве исследования. Пользовательские формы проверяются и при отправке через REST API; стандартная форма на API не распространяется ради совместимости существующих интеграций.
Как устроены ограничения на новые отчёты
Отдельный анонс лимитов Private Vulnerability Reporting описывает дневные ограничения для одного отправителя. Они действуют на уровне конкретного репозитория и GitHub в целом. После достижения лимита автору предлагается повторить попытку позднее. В сообщении компании не названа универсальная численная квота, поэтому считать какое-либо количество отчётов общим стандартом нельзя.
Администраторы репозитория могут дополнительно установить собственный общий дневной предел входящих сообщений. Для доверенных исследователей предусмотрен список исключений: такие отправители не подпадают под ограничения. Настройка находится в разделе Advanced Security рядом с параметрами закрытого сообщения об уязвимостях.
Важная граница изменений: лимиты затрагивают создание новых отчётов, но не комментарии в уже существующих закрытых обсуждениях. Значит, достижение дневной квоты само по себе не должно обрывать переписку о ранее заявленной проблеме. GitHub связывает введение ограничений с нагрузкой от автоматических сообщений; это объяснение платформы, а не доказательство того, что каждый отчёт с участием ИИ недостоверен.
Кому доступны изменения и что проверить владельцу проекта
В обоих анонсах указаны тарифы GitHub Free, Pro, Team и Enterprise Cloud. Обязательное условие — публичный репозиторий с включённым Private Vulnerability Reporting. Нельзя автоматически переносить объявленные правила на любые закрытые корпоративные проекты или считать, что новый канал уже активирован у всех владельцев открытого кода.
Документация GitHub по настройке репозитория описывает включение функции владельцем или администратором через параметры безопасности. После активации исследователь может отправить закрытое сообщение из раздела уведомлений о безопасности. Для получения извещений сопровождающим также нужно проверить подписку на активность или оповещения безопасности и настройки уведомлений своей учётной записи.
Практический смысл обновления — заранее определить состав необходимых сведений и управлять входящим потоком. Структурированная форма и лимиты не заменяют техническую проверку: сопровождающим по-прежнему предстоит оценить воспроизводимость и влияние каждого сообщения. Дата описанного события — 1 октября 2026 года; материал опубликован 2 октября.
