GitHub представила специализированную модель для поиска секретов в программном коде. Новый классификатор анализирует не только форму подозрительной строки, но и окружающий контекст, поэтому способен распознавать пароли и внутренние ключи без характерного префикса.

Главная особенность разработки — скорость. Модель на базе ModernBERT проверяет набор кандидатов менее чем за две миллисекунды. Этого достаточно, чтобы включить контекстный анализ непосредственно в путь отправки изменений и остановить утечку до того, как секрет попадёт в историю репозитория.

Почему шаблонов стало недостаточно

Многие токены имеют узнаваемый формат: фиксированный префикс, длину и допустимый набор символов. Такие значения удобно искать регулярными выражениями. Внутренний пароль базы данных или произвольный ключ может выглядеть как обычная строка, и без контекста надёжно отличить его от тестового заполнителя невозможно.

Классификатор рассматривает окружающие элементы — адрес подключения, имя переменной, структуру файла конфигурации или инструкцию сборки. Он может посчитать значение подозрительным внутри URL базы данных, Kubernetes-манифеста или Dockerfile, но пропустить очевидный пример вроде нейтральной заглушки.

Модель не генерирует код и текст. Она решает узкую задачу классификации, что снижает задержку и стоимость проверки. GitHub утверждает, что новый подход точнее прежних конвейеров на больших языковых моделях и способен более чем вдвое увеличить число секретов, которые можно остановить до публикации.

Объём кода растёт быстрее ручной проверки

По данным платформы, новый секрет появляется в публично видимом коде примерно раз в две секунды. Количество проверенных публичных отправок с середины 2024-го до середины 2026 года выросло с 202 до 574 миллионов за квартал. Число отправок с учётными данными увеличилось сопоставимым темпом, поэтому заметного роста доли ошибок на одну отправку компания не обнаружила.

Проблема заключается в масштабе. Даже неизменная вероятность ошибки даёт больше инцидентов, когда объём изменений почти утраивается. При этом разработчики стали реже сознательно обходить блокировку: доля переопределённых предупреждений снизилась с 6,63 до 3,93 процента.

После попадания секрета в открытый репозиторий работа резко усложняется. Его приходится отозвать, заменить во всех сервисах и проверить журналы доступа. Среднее время ручного отзыва, приведённое GitHub, держится около сорока дней, а примерно каждый пятый секрет оставался действующим более девяноста дней.

Где появится новая проверка

Организации, уже использующие ИИ-оповещения о паролях, автоматически переводятся на новую модель. Такие проверки после отправки кода остаются частью GitHub Secret Protection и GitHub Advanced Security без отдельной платы.

Контекстная проверка во время отправки изменений сейчас находится в закрытом предварительном доступе. Позднее в октябре её планируют открыть организациям на GitHub Enterprise Cloud и GitHub Team при наличии лицензии Secret Protection или Advanced Security. Администратор должен включить функцию явно, а проверки будут расходовать ИИ-кредиты.

GitHub Enterprise Server 3.23 получит обнаружение ИИ-секретов в публичном предварительном режиме. Это позволит использовать классификатор в изолированных корпоративных сетях. Вариант блокировки непосредственно при отправке изменений в этот серверный выпуск не входит.

Ещё одна точка применения — команда проверки безопасности в Copilot CLI и приложении Copilot. Перед фиксацией или запросом ревью разработчик сможет проверить активные изменения, получить приоритетный список замечаний, исправить подтверждённые проблемы и повторить анализ. Новые проверки секретов будут подключаться отдельно и также потребуют ИИ-кредитов.

Автоматическая блокировка важнее быстрого уведомления

GitHub сотрудничает более чем со 150 поставщиками сервисов, чтобы распознавать их учётные данные и сообщать об открытых утечках. Во втором квартале 2026 года система передавала партнёрам в среднем 26 совпадений в секунду с учётом повторных наблюдений. Некоторые провайдеры могут автоматически отозвать токен после уведомления.

Однако отзыв не возвращает утраченный секрет обратно. Разработчику всё равно приходится выпускать новый и обновлять конфигурацию. Поэтому проверка на границе отправки ценнее: она останавливает изменение до появления в истории и превращает инцидент в локальное исправление.

Сейчас защита при отправке предотвращает около 30 процентов новых обнаруженных секретов; остальные находятся уже после попадания в репозиторий. Контекстная модель должна сдвинуть баланс в сторону профилактики, сохранив низкую задержку и приемлемое число ложных срабатываний.

Главный итог: защита кода переходит от поиска известных форматов к пониманию окружения. Узкая быстрая модель не заменяет ротацию ключей и контроль доступа, но способна перенести обнаружение на самый дешёвый этап — до публикации. Это особенно важно в разработке с ИИ-агентами, где скорость создания изменений растёт быстрее возможности человека просмотреть каждую строку.