Секреты CISA, случайно размещённые в открытом доступе, превратились из неловкой ошибки в серьёзный риск безопасности.
По данным KrebsOnSecurity, подрядчик CISA опубликовал ключи AWS GovCloud и другие внутренние данные агентства на публичном аккаунте GitHub. Конгресс требует выяснить, как долго данные были доступны, и убедиться, что утекшие учётные данные больше не действуют.
Ключевой момент: инцидент закрыт только после идентификации, аннулирования и замены всех секретов с последующей проверкой использования.
Как это произошло#
18 мая KrebsOnSecurity сообщил, что подрядчик с административным доступом к внутренней платформе CISA создал публичный профиль GitHub с десятками открытых секретов.
Логи коммитов показали, что встроенная защита GitHub не сработала. Архив Private-CISA, теперь недоступный, вероятно, был создан в ноябре 2025 года.
CISA признало инцидент, заявив, что “нет признаков компрометации чувствительных данных”, но неизвестно, как долго данные оставались открытыми и обновлены ли все секреты, когда законодатели начали проверки.
Сенатор Маргарет Хассан запросила разъяснения у исполняющего обязанности директора CISA. Демократы комитета по внутренней безопасности Палаты представителей отметили слабую культуру безопасности и недостаточный контроль подрядчиков.
Главное — проверить, насколько хорошо CISA управляет киберрисками. Публичная утечка собственных ключей стала тестом этих мер.
Почему это критично#
Публичные репозитории отслеживают как защитники, так и злоумышленники. TruffleHog ищет приватные ключи, но те же методы используют преступники и государственные операторы.
Один утекший RSA-ключ дал доступ к корпоративной учетной записи CISA на GitHub. С его помощью можно было читать приватный код, запускать rogue self-hosted runners, воздействовать на CI/CD, получать секреты репозиториев и менять настройки branch protection, webhooks и deploy keys.
CISA отозвало ключ после уведомления 20 мая, но другие критические учётные данные оставались активными.
Сложность в том, что речь идёт о множественном раскрытии секретов в разных системах и рабочих процессах. Радиус воздействия зависит от доступа к каждому секрету и качества логирования.
Практические шаги#
- Найти все утекшие секреты в истории репозитория.
- Аннулировать старые ключи перед заменой. Новый ключ не снижает риск, если старый остаётся активным.
- Проверить логи использования каждого секрета, чтобы понять, был ли он применён.
- Проверить CI/CD: GitHub app keys, права runners, deploy keys, webhooks и настройки защиты веток.
- Учитывать доступ подрядчика как часть границ безопасности: админ-доступ к коду означает контроль над инфраструктурой, особенно если репозитории содержат код деплоя или секреты окружения.
Для команд по безопасности open source урок не “не использовать GitHub”, а применять сканирование секретов, принудительную защиту пушей, минимальные права приложений и проверенную ротацию ключей.
Связанные материалы GigaTap: OpenSSF в апреле — сделать артефакты безопасности операционными; 100% тестовое покрытие пакетов — цель, а не лозунг; безопасность open source требует больше, чем код.
Чего не стоит утверждать#
Публичные данные не подтверждают использование секретов иностранными противниками. CISA сообщает об отсутствии компрометации — это важно, но не доказательство полной безопасности.
Открытый репозиторий с активными секретами вызывает серьёзные опасения даже без подтверждённого использования. Без логирования нельзя считать отсутствие событий доказательством защиты.
CISA пережила серьёзный инцидент: часть ключей оставалась активной после уведомления, законодатели проверяют, способствовали ли ошибки контроля сбоям.
Следующие шаги: определить количество утекших ключей, доступ к системам, когда каждый ключ отозван, был ли доступ извне и изменялись ли настройки CI/CD.
Без этих данных инцидент остаётся открытым и служит проверкой способности CISA превратить утечку публичных ключей в контролируемую ситуацию.