Токен истекает. Ключ — нет.
Аутентификация GitHub App основана на private key, который генерирует JSON Web Token (JWT) с максимальным сроком жизни 10 минут. Этот JWT затем запрашивает токен доступа к установке (installation access token), действительный до одного часа. GitHub строго контролирует истечение этих вторичных токенов, создавая иллюзию временного доступа.
Однако корневой private key, являющийся источником этих учетных данных, не имеет встроенного времени жизни (TTL). Он может бесконечно создавать новые токены, пока его явно не отзовут. Этот фундаментальный архитектурный выбор означает, что скомпрометированный или забытый ключ остается постоянной угрозой, в отличие от кратковременных токенов, которые он создает.
Хотя некоторые утверждают, что это повторяет поведение SSH-ключей, у которых также часто отсутствует принудительное истечение срока действия на уровне платформы, масштаб разрешений GitHub App значительно повышает риск. Приложения часто обладают широким доступом к нескольким репозиториям, включая:
- Административные привилегии организации
- Права на запись в закрытый код
- Управление self-hosted runners и выполнением рабочих процессов (workflow execution)
Исследование GitGuardian выявило 474 активных ключа, 44 из которых предоставляли полные права администратора организации. Один ключ, связанный с CDC США, предоставлял доступ на запись к закрытому коду в течение 17 месяцев после утечки. Это подчеркивает, почему неуправляемые ключи GitHub App представляют собой значительный и долгосрочный риск управления, выходящий далеко за рамки обычного SSH-ключа.
474 утекших ключа все еще открывали дверь
Недавнее исследование GitGuardian выявило суровую реальность: из более чем 500 000 раскрытых RSA-ключей 4 802 были связаны с GitHub App ID. Поразительно, но 474 из этих ключей все еще проходили аутентификацию, представляя 440 различных приложений, несмотря на то, что они были публично раскрыты. Это демонстрирует критическую уязвимость в цепочке безопасности.
Последствия этих постоянных утечек серьезны. Сорок четыре действительных приложения имели полный доступ администратора организации, в то время как 72% могли читать закрытые репозитории. Кроме того, 207 приложений обладали правами на запись, открывая путь к произвольному внедрению кода и отравлению конвейера (pipeline poisoning), что является значительным риском для безопасности цепочки поставок.
Проблема стойкости вызывает беспокойство. Один ключ Crusher.dev был публичным с 2020 года и оставался активным. Ключ, связанный с CDC США, по сообщениям, оставался действительным в течение 17 месяцев после утечки. Другое широко используемое приложение, "Access Tokens for GitHub Actions", допустило утечку private key в январе 2024 года, затронув около 300 организаций, включая оборонного подрядчика Sierra Nevada Corp.
Эти примеры подчеркивают опасность private keys для GitHub App: в отличие от кратковременных JWT и токенов доступа к установке, которые они создают, сами корневые private keys не имеют встроенного срока действия. Этот архитектурный недосмотр превращает единичную утечку в постоянную угрозу безопасности, требующую немедленного внимания и надежных стратегий ротации ключей.
Забытое приложение может стать плацдармом для атаки на цепочку поставок
Забытое приложение представляет собой значительный плацдарм для атаки на цепочку поставок. Утекшие ключи могут позволить злоумышленнику читать закрытый код, записывать данные в репозитории, манипулировать рабочими процессами или управлять self-hosted runners. Такой доступ напрямую способствует подделке кода, компрометации CI/CD и, в конечном итоге, захвату организации.
Устаревшие интеграции легко упустить из виду. GitGuardian обнаружил, что 59% из 440 различных приложений с активными ключами имели только одну установку, часто для разовой автоматизации. Когда инженеры увольняются или проекты забрасываются, владение этими приложениями часто теряется, что создает постоянную уязвимость. Ключ приложения Crusher.dev, скомпрометированный с 2020 года, оставался активным спустя годы после прекращения поддержки проекта.
Например, у организации US Centers for Disease Control and Prevention (CDC) в течение 17 месяцев был скомпрометирован закрытый ключ с правами записи в частные репозитории, что обеспечивало доступ к ее инфраструктуре Microsoft Azure. Аналогичным образом, широко используемое приложение "Access Tokens for GitHub Actions" допустило утечку закрытого ключа, что поставило под угрозу около 300 организаций.
Хотя наличие действительного ключа не является автоматическим доказательством активной эксплуатации, оно означает постоянную угрозу. Получив действительный ключ, злоумышленники могут в любое время действовать с правами, предоставленными приложению. Для получения дополнительной информации об этих постоянных угрозах см. исследование GitGuardian: GitHub App Private Keys: 474 Leaked Keys Still Work. Это подчеркивает острую необходимость строгого управления закрытыми ключами GitHub App и связанными с ними разрешениями для снижения рисков цепочки поставок.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Ротация без простоев — и удаление того, что никому не принадлежит
Владельцы приложений должны внедрить надежную стратегию ротации ключей. Создайте новый закрытый ключ, разверните и проверьте его функциональность, а затем отзовите старый. GitHub позволяет иметь до 25 активных закрытых ключей для одного приложения, что позволяет выполнять поэтапную ротацию без прерывания обслуживания.
Установите документированный график ротации, протоколы безопасного хранения ключей и интегрируйте сканирование секретов во всех репозиториях, включая публичные форки, принадлежащие разработчикам. Обеспечьте доступ по принципу наименьших привилегий, ограничивая разрешения приложений только теми репозиториями и действиями, которые строго необходимы для их работы. Это минимизирует радиус поражения при любом потенциальном взломе.
Администраторы организаций сталкиваются с критически важной задачей по аудиту установленных приложений. Определите и назначьте ответственных владельцев для каждой интеграции. Оперативно удаляйте заброшенные или неподдерживаемые приложения, так как они становятся главными целями для злоумышленников, ищущих постоянный плацдарм.
Наконец, убедитесь, что все оставшиеся приложения работают с минимально необходимым набором разрешений. Проверка и ужесточение этих элементов управления доступом уменьшает поверхность атаки, предотвращая превращение забытого приложения в открытую дверь к наиболее конфиденциальным активам вашей организации.
Часто задаваемые вопросы
Истекает ли срок действия закрытых ключей GitHub App автоматически?
Нет. Закрытые ключи GitHub App не имеют встроенного срока действия, поэтому владельцы должны ротировать и отзывать их самостоятельно.
Как можно использовать неистекший ключ GitHub App?
Он может подписывать кратковременный JWT, который можно обменять на токен доступа к установке, действующий до одного часа.
Сколько закрытых ключей GitHub App может быть активно одновременно?
GitHub позволяет использовать до 25 закрытых ключей для одного приложения, что позволяет командам развертывать замену перед удалением старого ключа.
Что должна делать организация с приложениями, которые никто не поддерживает?
Проводите аудит установленных GitHub Apps, удаляйте устаревшие или бесхозные интеграции и ограничивайте разрешения и репозитории, предоставленные тем, которые остались.