По данным свежего отчета GitGuardian State of Secrets Sprawl 2026, проблема хардкоженных секретов в коде и инфраструктуре не просто сохраняется, а ускоряется. В 2025 году на публичном GitHub было обнаружено 29 млн новых секретов, что означает прирост на 34% за год и самый крупный скачок за весь период наблюдений.
Утечки секретов в коде: рост на фоне ИИ и DevOps
С 2021 года объем утекших секретов вырос на 152%, тогда как база публичных разработчиков GitHub увеличилась на 98%. Это отражает сочетание двух факторов: большего количества разработчиков и массового использования ИИ-инструментов генерации кода, которые нередко воспроизводят или генерируют небезопасные шаблоны работы с секретами.
Отдельно выделяется сегмент ИИ-сервисов: в 2025 году GitGuardian зафиксировал 1 275 105 утечек секретов, связанных с AI, что на 81% больше, чем в 2024-м. Восемь из десяти самых быстрорастущих категорий ключей были связаны именно с ИИ. Речь идет не только о токенах OpenAI или Anthropic: основной рост приходится на инфраструктуру LLM — retrieval-API (например, Brave Search, +1255%), оркестрацию (Firecrawl, +796%) и управляемые бекенды (Supabase, +992%). Каждый новый AI-интеграционный слой порождает новую «машинную» идентичность и расширяет поверхность атаки.
Внутренние репозитории и корпоративные инструменты как главный риск
Пока основное внимание часто сосредоточено на публичном GitHub, наиболее ценные учетные данные живут во внутренних системах. Исследование GitGuardian показало, что 32,2% внутренних репозиториев содержат хотя бы один хардкоженный секрет, тогда как среди публичных репозиториев таких всего 5,6%. Внутри — не тестовые ключи, а токены CI/CD, облачные креденшалы и пароли к БД, то есть именно те активы, которые атакующие используют после первичного проникновения.
Секреты все чаще выходят за пределы исходного кода. В 28% инцидентов в 2025 году утечки происходили исключительно в корпоративных инструментах: Slack, Jira, Confluence и аналогичных платформах. Такие инциденты оказываются более критичными: 56,7% секретов, найденных только в коллаборативных сервисах, были отнесены к критическим против 43,7% для утечек, ограниченных репозиториями. Причина проста: команды активно обмениваются креденшалами при разборе инцидентов, отладке и онбординге, зачастую без каких-либо технических ограничений.
Контейнеры, GitLab и размытая граница периметра
В 2025 году GitGuardian обнаружил тысячи случайно открытых self-hosted GitLab и Docker Registry. Сканирование этих систем выявило около 80 000 секретов, из которых 10 000 оставались валидными. Особое беспокойство вызывают контейнерные образы: 18% просканированных Docker-образов содержали секреты, и 15% из них были действующими. Для сравнения, в репозиториях GitLab секреты были найдены в 12% случаев, и столько же (12%) оставались актуальны.
Контейнерные секреты особенно опасны тем, что они максимально близки к production-средам и часто встраиваются в образы «однажды и навсегда». Это демонстрирует, насколько периметр между «приватным» и «публичным» стал проницаемым: конфиденциальные реестры и репозитории регулярно оказываются доступными извне по ошибке конфигурации.
Проблемы ремедиации: почему секреты живут годами
Выявление секрета не означает его нейтрализацию. При повторном тестировании секретов, признанных валидными еще в 2022 году, GitGuardian установил, что 64% из них остаются эксплуатируемыми спустя четыре года. Это говорит о том, что ротация и отзыв ключей по-прежнему не автоматизированы и не встроены в рутинные процессы.
Секреты, вшитые в пайплайны сборки, переменные CI, контейнерные образы и интеграции с вендорами, сложно заменить без риска простоя production. Для многих команд «ничего не делать» оказывается менее рискованным с бизнес-точки зрения, чем агрессивная ротация, — и этим активно пользуются злоумышленники.
Supply chain-атаки, ИИ-агенты и новая поверхность атаки
Цепочки поставок ПО остаются важным каналом утечек. Во время атаки Shai-Hulud 2 исследователи получили редкий доступ к тому, как выглядят секреты на скомпрометированных рабочих станциях разработчиков. На 6 943 системах было найдено 294 842 вхождения секретов, соответствующих 33 185 уникальным значениям. В среднем каждый активный секрет встречался в 8 разных местах на одной машине: в .env-файлах, истории командной строки, конфигурациях IDE, кешированных токенах и артефактах сборки. Показательно, что 59% скомпрометированных систем оказались раннерами CI/CD, а не персональными ноутбуками.
Более недавняя supply chain-атака на пакет LiteLLM показала аналогичную картину: вредоносный код собирал SSH-ключи, облачные креденшалы и токены API с машин разработчиков, где сегодня сосредоточены инструменты ИИ-разработки.
Отдельное направление риска — развитие Model Context Protocol (MCP) и похожих фреймворков для «агентного ИИ». В 2025 году в MCP-конфигурациях на публичном GitHub было обнаружено 24 008 уникальных секретов, из которых 2 117 были подтверждены как валидные. По мере распространения AI-агентов практика размещения ключей в config-файлах, флагах запуска и локальных JSON будет только расширяться.
От поиска секретов к управлению нефизическими идентичностями
Современные программы кибербезопасности упираются в три базовых вопроса: сколько нефизических (machine) идентичностей существует в инфраструктуре, кто за них отвечает и к каким ресурсам они имеют доступ. Традиционный подход «сканировать публичные репозитории и надеяться на соблюдение правил» перестал работать.
Организациям, внедряющим ИИ и интенсивный DevOps, требуется стратегический переход от точечной детекции к непрерывному управлению нефизическими идентичностями (Non-Human Identities, NHI). Ключевые элементы такого подхода включают: по максимуму отказ от долгоживущих статических секретов, переход к краткоживущему доступу на основе идентичности, использование секрет-волтов как стандартного девелоперского паттерна и управление жизненным циклом каждой сервисной учетной записи, CI-задачи и ИИ-агента как полноценной сущности IAM.
Секреты больше нельзя рассматривать как разовые инциденты. Они стали системным фактором риска, напрямую связанным с ростом ИИ, автоматизации и распределенной разработки. Организациям стоит уже сейчас расширять зону видимости за пределы публичных репозиториев — на внутренние системы, коллаборативные инструменты, контейнерные реестры и рабочие станции разработчиков — и выстраивать автоматизированные процессы ротации и отзыва ключей. Те, кто раньше остальных встроит управление секретами в общую стратегию NHI- и IAM-губернанса, получат не только более высокий уровень защиты, но и заметное преимущество в устойчивости к будущим волнам атак.
