20 октября 2026 года GitHub сообщил об изменениях Secret Scanning. Самое важное для интеграций аудита пока запланировано: 12 ноября поле business в затронутых событиях будет содержать slug предприятия вместо отображаемого имени. На Mentoring.digital разбираем, что нужно подготовить, не выдавая будущий переход за уже состоявшийся.
Где проверить фильтры
Анонс касается событий secret_scanning_alert.* и secret_scanning_push_protection.bypass. Тип business остаётся строковым. Числовой business_id и имена событий не меняются. GitHub рекомендует до перехода принимать оба представления или использовать business_id.
Если интеграция сравнивает business с названием из интерфейса, после изменения совпадение может исчезнуть. Редакционный следующий шаг: найти такую проверку в своей обработке аудита, сохранить обезличенный пример и проверить новое представление отдельно. Одно успешное чтение журнала ещё не подтверждает работу всех фильтров.
Что уже улучшено в обработке событий
Webhook запросов закрытия предупреждений получил exemption_request.number. Для сопоставления нужно использовать номер вместе с репозиторием. Исправлены и некоторые ответы API, связанные с метаданными обхода защиты и конфигурацией проверяющих.
При недопустимых аргументах Custom Pattern API теперь возвращает 422 вместо 500. Обработчик должен отличать ошибку входных данных от сбоя сервера. Это конкретное изменение, а не утверждение, что любой ответ 422 во всех API GitHub имеет одинаковую причину.
Как подготовить изменение без реального секрета
Для проверки интеграции используйте безопасную модель события и подставные идентификаторы. Не создавайте настоящий утекший токен ради демонстрации и не копируйте его в журналы. Зафиксируйте, какой вариант поля принят и как сопоставлены репозиторий и запрос.
При необходимости разобрать контракт и обработку отказов можно выбрать наставника по API. Итогом подготовки должен быть понятный набор проверок вашей интеграции до 12 ноября, а не только обновлённый текст документации.
