15 мая агентство CISA (Cybersecurity and Infrastructure Security Agency) начало внутреннее расследование после того, как журналист сообщил об обнаружении ключей доступа к облачной среде AWS GovCloud в открытом репозитории кода. Информацию журналисту передал сотрудник компании, которая непрерывно сканирует публичные репозитории на предмет утечек. Ведомство немедленно отреагировало: репозиторий был удалён, среда разработки отключена, учётные записи контрактора, допустившего утечку, деактивированы.
Как выяснилось в ходе разбора, репозиторий не относился к официальному GitHub-аккаунту CISA - он принадлежал одному из контракторов. Тот скопировал в свой личный репозиторий код для автоматизированного развёртывания инфраструктуры (Infrastructure as Code), а также административные и сборочные учётные данные. После изъятия копии репозитория и анализа логов CISA установила, что утёкшие ключи не использовались за пределами её среды, а данные клиентов и миссионно-критическая информация не пострадали.
Тем не менее последствия для операционной деятельности оказались ощутимыми. CISA провела ротацию всех учётных данных во всех средах, где контрактор имел права администратора, а не только скомпрометированных. Были обновлены списки разрешённых и запрещённых репозиториев, а также ограничена возможность пользователей загружать код в публичные хранилища. Среда разработки вернулась в строй только после завершения этих мер.
Инцидент привлёк внимание к нескольким системным проблемам, с которыми сталкиваются даже регуляторы кибербезопасности. CISA признала, что у неё отсутствовал специализированный плейбук для реагирования на инциденты, связанные с GitHub и облачными средами, - его пришлось создавать в первые часы после обнаружения. Это замедлило начальные этапы и стало одним из ключевых уроков для других организаций.
Одновременно расследование подтвердило эффективность подхода Zero Trust (модель безопасности без доверия по умолчанию) и детального логирования. Благодаря тому, что система управления событиями безопасности (SOC) CISA имела полные логи по всем средам, удалось быстро подтвердить отсутствие внешнего доступа через утёкшие ключи. Агентство также выявило дополнительные возможности для улучшения логирования и уже внедрило их.
Отдельно CISA остановилась на проблеме управления секретами (учётными данными, ключами, паролями) в репозиториях. Несмотря на то, что репозиторий был личным, сам факт попадания ключей в код разработки говорит о недостаточном контроле ещё на этапе коммитов. Для мониторинга загрузок в публичные репозитории CISA решила использовать EDR-решения (класс продуктов для обнаружения и реагирования на конечных точках) - это позволяет разработчикам забирать код из открытых источников, но блокирует выгрузку чувствительного контента. Все секреты в частных репозиториях CISA были ротированы, а план по управлению ключами пересмотрен.
Не менее важным оказался аспект каналов связи с исследователями. Исследователь, обнаруживший ключи, был вынужден отправлять уведомления по нескольким адресам: напрямую контрактору, через платформу CISA для сообщений об уязвимостях (которая предназначена для уязвимостей продуктов сторонних вендоров, а не для внутренних инцидентов) и, в конечном итоге, через журналиста. CISA признала, что такая путаница могла бы привести к задержке реагирования в более критическом сценарии, и пообещала упростить каналы, разместив инструкции в нескольких очевидных местах, включая стандартный файл security.txt.
Ещё один вывод касается криптографической гибкости. Ротация ключей заняла больше времени, чем ожидалось, из-за сложности инфраструктуры CISA и её интеграций с федеральными и отраслевыми партнёрами. Агентство призвало заранее отрабатывать сценарии массовой смены ключей и поддерживать зрелые процессы управления криптографическими материалами.
Опубликовав детальный отчёт, CISA сделала редкий для государственного регулятора шаг - полностью раскрыла обстоятельства собственного инцидента, включая ошибки и улучшения. Агентство подчеркнуло, что подобная прозрачность помогает другим организациям учиться на чужом опыте и быстрее закрывать аналогичные пробелы в своей безопасности. Инцидент CISA показал, что уязвимости, связанные с человеческим фактором и контролем доступа к репозиториям, могут возникнуть у любого - и лучший способ минимизировать ущерб - это сочетание Zero Trust, качественного логирования, правильных плейбуков и упрощённых каналов для тех, кто сообщает о проблемах.
