GitHub Enterprise Cloud получил функцию экспорта полного реестра учётных данных, которые могут использоваться для доступа к enterprise. Обновление опубликовано в GitHub Changelog 21 сентября 2026 года. Теперь владельцы enterprise могут получить сводную инвентаризацию ключей и токенов, принадлежащих участникам и приложениям, вместо проверки разных типов доступа по отдельности.
Нововведение рассчитано прежде всего на администраторов и команды безопасности. Оно пригодится при регулярном аудите доступа, расследовании инцидентов и подготовке списка учётных данных, которые нужно дополнительно проверить, отозвать или заменить.
Какие учётные данные попадают в реестр
Согласно описанию GitHub, экспорт охватывает несколько категорий credentials:
- SSH-ключи;
- классические и fine-grained personal access tokens;
- токены доступа OAuth App;
- токены GitHub App user-to-server;
- установочные токены GitHub App, или installation tokens.
Таким образом, в одной инвентаризации собираются как ключи и токены пользователей, так и credentials, связанные с приложениями. Это особенно важно для enterprise-сред, где доступ к коду и автоматизированным процессам распределён между людьми, интеграциями и приложениями.
GitHub описывает функцию как единое представление учётных данных на уровне enterprise. При этом опубликованный анонс не утверждает, что CSV содержит сами секретные значения токенов или приватные ключи. Поэтому экспорт следует воспринимать как перечень и набор доступных для аудита сведений, а не как резервную копию секретов.
Где находится экспорт CSV
Настройка «Export CSV» доступна владельцу enterprise в разделе:
Settings → Authentication Security → Credentials
Кнопка находится рядом с разделом «Overview». GitHub также указывает, что просматривать и экспортировать сведения могут участники, которым выдано детализированное разрешение View enterprise credentials.
Это означает, что доступ к самому реестру должен рассматриваться как административное полномочие. CSV может содержать чувствительные сведения о владельцах credentials, типах доступа и состоянии учётных записей. GitHub в анонсе не приводит полный перечень полей экспорта, поэтому перед передачей файла в систему аналитики или команде реагирования стоит проверить его фактическое содержимое и правила хранения.
Практическая проверка для администратора проста: после появления функции нужно открыть страницу Credentials, убедиться, что учётная запись имеет необходимое разрешение, и сопоставить количество и типы записей с известными в enterprise ключами, токенами и приложениями. Такая сверка поможет понять, какие объекты действительно попадают в новый реестр.
REST API для автоматизации аудита
Помимо ручной выгрузки GitHub представил новые REST API endpoints для программного формирования отчётности и автоматизации. Через API организации смогут встроить инвентаризацию в собственные процессы безопасности, внутренние панели мониторинга или процедуры реагирования на инциденты.
Возможные сценарии использования — регулярное получение списка credentials, сравнение выгрузок во времени и передача результатов ответственным администраторам. Например, команда может отслеживать появление новых токенов между двумя проверками или запускать дополнительную ручную проверку после обнаружения неожиданной записи.
Однако сам факт наличия токена не доказывает, что он скомпрометирован или используется злоумышленником. Реестр отвечает на вопрос о том, какие credentials существуют и могут иметь доступ к enterprise. Для расследования активности потребуется сопоставлять эти данные с журналами аудита, настройками разрешений и другими сигналами безопасности GitHub.
В анонсе также не приведён полный перечень параметров API, правила фильтрации и ограничения частоты запросов. Эти детали нужно проверять в документации GitHub перед подключением интеграции к рабочим системам.
Зачем это нужно при инциденте
При подозрении на утечку токена первая задача команды безопасности — определить масштаб потенциального воздействия. Для этого необходимо знать, какие credentials были доступны, кому или какому приложению они принадлежат и какие из них могли использоваться в затронутой среде.
GitHub указывает, что новый реестр помогает быстрее оценить поверхность риска и спланировать дальнейшие действия на основе выявленного набора потенциально скомпрометированных токенов. Это не автоматическое устранение инцидента: функция не отзывает credentials и не определяет причину компрометации. Она сокращает начальный этап сбора сведений.
После получения CSV или данных через API администратору всё равно нужно отдельно решить:
- какие ключи и токены относятся к затронутым пользователям или приложениям;
- какие разрешения связаны с конкретными credentials;
- требуется ли отзыв, ротация или повторная выдача доступа;
- где ещё сохранены зависимости от заменяемого токена;
- нужно ли уведомить владельцев приложений и команды, использующие автоматизацию.
Особое внимание стоит уделить GitHub Apps и интеграциям CI/CD. Установочный токен приложения может участвовать в автоматизированном процессе и не быть очевидным при проверке только пользовательских personal access tokens. Новый единый реестр позволяет включить такие credentials в ту же процедуру инвентаризации, но не заменяет проверку конфигураций, где они используются.
Доступность для Enterprise Cloud и Server
Функция уже доступна в GitHub Enterprise Cloud. Для GitHub Enterprise Server GitHub заявляет поддержку в будущих выпусках, но в опубликованном сообщении не называет конкретную версию или дату.
Поэтому владельцам self-hosted-инсталляций не стоит считать, что функция автоматически доступна после обновления интерфейса или документации Cloud. Им потребуется проверить примечания к выпуску своей версии Enterprise Server и отдельно убедиться в наличии соответствующих API endpoints.
Главное ограничение текущего анонса — отсутствие подробной спецификации формата CSV и полного состава данных, которые возвращает REST API. До внедрения регулярного экспорта в процессы DevSecOps стоит протестировать права доступа, обработку файла, срок его хранения и то, не передаются ли результаты в системы, которым не нужен полный перечень enterprise credentials.