28 миллионов утечек секретов за год: отчёт GitGuardian, статистика и примеры атак 2026

28,65 миллиона секретов утекли в публичные репозитории GitHub за один год. API-ключи, токены доступа, пароли к базам данных — всё в открытом доступе. Рост на 34% год к году, но это лишь видимая часть проблемы.

64% секретов, обнаруженных в 2022 году, всё ещё действуют в 2026-м — спустя четыре года после утечки. Каждый день в публичные репозитории попадает 78 000 новых учётных данных. Большинство останутся действующими годами. Некоторые уже используются атакующими прямо сейчас.

GitGuardian просканировали 1,94 миллиарда коммитов и зафиксировал критическую закономерность: утечки растут быстрее числа участников/разработчиков (+152% против +98% с 2021 года), а новые векторы (ИИ-ассистенты, MCP-конфигурации, внутренние репозитории) генерируют уязвимости со скоростью, которую команды не успевают обрабатывать. Обнаружение перестало работать как мера защиты.

В этом материале — полный разбор отчёта The State of Secrets Sprawl 2026, статистика по типам утечек, реальные кейсы атак и пошаговая стратегия защиты.

Главное

• 28,65 млн новых утечек секретов за год — рост на 34%. Утечки растут быстрее числа разработчиков: +152% против +98% с 2021 года. 64% секретов 2022 года всё ещё действуют в 2026-м — спустя четыре года.
• ИИ-инструменты ускоряют утечки в 5 раз. Утечки секретов ИИ-сервисов выросли на 81,5%. Коммиты с участием Claude Code содержали секреты в два раза чаще обычных (3,2% против 1,5%).
• 24 000 секретов в конфигурациях протокола контекста модели (MCP) — новый вектор утечек. 8,8% действующие. Большая часть официальных гайдов нормализует хардкод секретов в конфигурациях.
• Внутренние репозитории — в 6 раз опаснее публичных. 32,2% внутренних репозиториев содержат секреты против 5,6% публичных. Приватность — не мера защиты.
• 28% утечек происходят вне кода — в Slack, Jira, Confluence. Они на 13% чаще критические (56,7% против 43,7%). Сканирование только репозиториев покрывает ~72% поверхности атаки.
• 80 000 секретов в открытых экземплярах GitLab и Docker, 10 000 действующих. Частота утечек из собственной инфраструктуры в 3–4 раза выше, чем из публичного GitHub.
• Рабочие станции — хранилища секретов. На 6 943 скомпрометированных машинах найдено 33 185 уникальных секретов. Каждый действующий секрет копируется в среднем 8 раз.
• 46% критических секретов пропускаются при подходе «проверяем только то, что можем проверить». Универсальные секреты (пароли, ключи, токены) составляют 35% критических инцидентов, но игнорируются из-за невозможности автопроверки.
• Устранение отстаёт от обнаружения. Секреты остаются действующими годами, потому что ротация — комплексный процесс, который большинство организаций не автоматизировали.

Что такое расползание секретов и почему это критично

Расползание секретов (распространение секретов, secrets sprawl) — неконтролируемое распространение учётных данных (секретов) в кодовой базе, конфигурационных файлах, чатах и других системах организации.

Секреты — это любые данные аутентификации, которые предоставляют доступ к системам, сервисам или данным: API-ключи, токены доступа, пароли, приватные криптографические ключи, сертификаты, строки подключения к базам данных.

Когда секрет встраивается непосредственно в код (хардкод), а затем фиксируется в системе контроля версий, он становится частью истории репозитория. Если репозиторий публичный или становится доступным злоумышленнику, секрет превращается в постоянный путь доступа к инфраструктуре — даже после удаления из текущей версии кода.

Масштаб проблемы: в 2025 году GitGuardian обнаружил 28,65 миллиона новых секретов в публичных коммитах GitHub — это утечки за один год, а не накопленный итог. С 2021 года объём вырос с 11 до 29 миллионов, увеличившись в 2,6 раза за пять лет. При этом число активных разработчиков за тот же период выросло лишь вдвое — утечки опережают рост экосистемы на 30%.

Секреты в публичных коммитах GitHub (2021–2025)

Критичность распространения секретов определяется тремя факторами:

1. Скорость роста опережает рост числа участников. С 2021 года утечки секретов выросли на 152%, в то время как число разработчиков увеличилось на 98%. Проблема усугубляется непропорционально.
2. Секреты остаются рабочими годами. 64% секретов, обнаруженных и подтверждённых как валидные в 2022 году, всё ещё не отозваны в 2026-м — спустя четыре года после утечки.
3. Каждый секрет — потенциальная точка входа. Один утёкший API-ключ может предоставить доступ к продуктовой базе данных, CI/CD или облачной инфраструктуре. Для атакующего достаточно одного рабочего секрета.

Главные цифры 2025 года: масштаб проблемы

Данные отчёта GitGuardian за 2025 год показывают устойчивый рост по всем ключевым метрикам:

Рост числа утечек (+33,9%) опережает рост числа разработчиков (+33,2%), но существенно отстаёт от роста объёма кода (+42,7%). Это указывает на то, что объём кода — главный драйвер утечек, а не просто увеличение числа людей, пишущих код.

С 2019 года число активных участников на GitHub утроилось (с 7,6 млн до 22,8 млн), а объём публичных коммитов вырос почти в четыре раза (с 514 млн до 1,94 млрд). При этом количество обнаруженных секретов росло ещё быстрее: с 2021 по 2025 год утечки увеличились на 152%, в то время как активность — на 98%.

Как ИИ ускоряет утечки секретов

2025 год стал переломным для индустрии: ИИ-инструменты для разработки перешли из категории экспериментов в повседневную практику. По данным GitHub Octoverse 2025, 80% новичков начинают использовать GitHub Copilot (ИИ-ассистент для написания кода) в первую же неделю. Это изменило не только скорость написания кода, но и природу утечек секретов.

ИИ-стек как новая поверхность атаки

По данным GitGuardian 1,275 миллиона секретов, связанных с ИИ-сервисами, было обнаружено в 2025 году — рост на 81,5% по сравнению с 2024-м. Это самый быстрорастущий сегмент среди всех типов утечек.

Восемь из десяти типов секретов с наибольшим годовым приростом утечек связаны с ИИ-сервисами:

Критическая закономерность: инфраструктура вокруг больших языковых моделей LLM (системы контекстного поиска, управление запросами, векторные базы данных, мониторинг) «течёт» в пять раз быстрее, чем ключи от самих моделей (OpenAI, Anthropic, Google AI).

Это объясняется архитектурой современных ИИ-приложений. Одна интеграция с LLM быстро превращается в сеть из десятков сервисов:

• Интерфейсы поиска (Retrieval APIs) для подачи контекста моделям (Brave Search +1 255%, Firecrawl +796%, Perplexity +657%)
• Оркестрация для многошаговых ИИ-процессов (LangChain +108%)
• Мониторинг и эксперименты (Weights & Biases +114%)
• Векторизация и поиск (Jina +334%)
• Базы данных для хранения векторов и состояний (Supabase +992%)

Каждый слой добавляет новые учётные данные. Каждый API-ключ — новый вектор утечки.

Пример: Supabase, популярная база данных для ИИ-проектов, показала рост утечек на 992% год к году и вошла в топ-20 самых «текущих» сервисов с 248 600+ обнаруженными секретами. В 2024 году рост составлял 97% — в 2025-м он ускорился в десять раз.

Claude Code: кейс-стади ИИ-ассистента

Anthropic Claude Code — ИИ-ассистент, который может не только предлагать код, но и напрямую создавать коммиты с атрибуцией через механизм «Co-Authored-By». Это позволило GitGuardian впервые точно измерить влияние конкретного ИИ-инструмента на утечки секретов.

Ключевые данные:

• Рост использования: с 22 коммитов в январе 2025 до 2,16 миллиона в декабре (×98 000)
• Доля в общем объёме: 0,4% всех публичных коммитов
• Доля в утечках: 0,9% всех обнаруженных секретов
• Частота утечек: коммиты с участием Claude Code содержали секрет в 3,2% случаев против 1,5% для обычных коммитов — в два раза чаще

Динамика в течение года: первая половина 2025 года показала наиболее выраженный всплеск. В августе частота утечек достигла пика — 31 секрет на 1 000 коммитов, что в 2,4 раза выше базового уровня. После выхода Claude Sonnet 4.5 в конце сентября показатель начал снижаться и к декабрю достиг 13 секретов на 1 000 коммитов — практически сравнявшись с уровнем обычной разработки.

Это указывает на значительные улучшения в поведении модели или в процессе разработки, который производит коммиты с участием Claude Code.

Размер коммитов: с апреля 2025 года коммиты, созданные с помощью Claude Code, в среднем содержали в два раза больше строк кода, чем обычные коммиты. Большие коммиты означают больше возможностей для утечки секретов в одном review и одном merge. К концу года разница сгладилась, что также указывает на улучшение работы модели.

Модели улучшаются, но ответственность остаётся на разработчике. ИИ-инструменты имеют возможность переопределять предложения, игнорировать предупреждения или явно запрашивать включение чувствительной информации. Утечки секретов в конечном счёте отражают человеческие решения — будь то из-за недосмотра, нехватки времени или намеренного обхода рекомендаций по безопасности.

По мере того как ИИ-модели становятся более безопасными, соответствующая эволюция практик безопасности разработчиков и организационных политик становится не менее критичной. Решение — не просто лучший ИИ, а лучшее взаимодействие человека и ИИ с надёжной культурой защиты на каждом этапе.

MCP-конфигурации: 24 000 секретов в первый год

В начале 2025 года Model Context Protocol (MCP) стал де-факто стандартом интеграции LLM с корпоративными системами. MCP — открытый протокол для подключения больших языковых моделей к внешним инструментам, базам данных и API. По мере того как сторонние сервисы спешили предоставить доступ через этот новый канал, конфигурационные файлы MCP быстро превратились в точку высокой концентрации захардкоженных секретов.

Масштаб проблемы:

• 24 008 уникальных секретов обнаружено в MCP-конфигурациях за 2025 год
• 2 117 из них (8,8%) оставались действующими на момент обнаружения
• Пик утечек пришёлся на август 2025 — 4 209 секретов за месяц

Топ-5 типов валидных секретов в MCP-конфигурациях:

Официальные гайды — часть проблемы: документация популярных MCP-серверов часто нормализует размещение учётных данных непосредственно в конфигурационных файлах. Примеры из руководств по быстрому старту показывают API-ключи, передаваемые как аргументы командной строки внутри конфигурации MCP-сервера (например, --figma-api-key=YOUR-KEY), или хранящиеся в поле env внутри того же JSON-файла, который попадает в систему контроля версий.

Примеры с PostgreSQL включают полные строки подключения вида postgresql://username:password@... под ключом DATABASE_URI. Когда официальная документация трактует захардкоженные секреты как стандартный подход, их бесконтрольное распространение неизбежно.

Риски MCP-секретов:

1. Прямое раскрытие данных: секреты от баз данных предоставляют доступ на чтение и запись к производственным наборам данных, часто с избыточными привилегиями.
2. Злоупотребление платформами и API: утёкшие API-ключи могут быть монетизированы через мошенничество, исчерпание квот и компрометацию учётных записей.
3. Компрометация рабочих процессов: токены для сборки, развёртывания и служб мониторинга позволяют обеспечить постоянное присутствие в системе, подмену компонентов или скрытое извлечение данных непосредственно в конвейере разработки.

Лучшие практики для MCP-конфигураций:

• Никогда не храните секреты в конфигурационных файлах MCP. Используйте переменные окружения, управляемые через выделенный менеджер секретов, а не встроенные значения в JSON или аргументах командной строки.
• Клиенты, а не серверы, должны владеть секретами. MCP-серверы должны запрашивать учётные данные у клиентов во время выполнения, а не встраивать их в серверную конфигурацию.
• Исключите конфигурационные файлы из системы контроля версий. Добавьте директории с конфигурацией MCP в .gitignore и трактуйте их как конфиденциальные артефакты.
• Используйте MCP-серверы только по защищённым каналам. Убедитесь, что удалённые серверы доступны через TLS.
• Сканируйте перед отправкой в репозиторий. Инструменты вроде ggshield могут обнаруживать секреты в конфигурациях MCP до того, как они попадут в систему контроля версий.
• Обязательное участие человека для критичных действий. Требуйте ручного подтверждения перед любым действием MCP, затрагивающим производственные системы, базы данных или конвейеры развёртывания.

Внутренние системы: слепая зона безопасности

Публично обнаруженные секреты — лишь половина истории. Данные GitGuardian показывают, что внутренние репозитории компаний в шесть раз чаще содержат захардкоженные секреты, чем публичные.

Внутренние репозитории: в 6 раз больше утечек, чем в публичных

32,2% внутренних репозиториев содержат хотя бы один захардкоженный секрет против 5,6% публичных.

Причина этого разрыва — команды разработки, намеренно или нет, менее осторожны внутри закрытого периметра. Они предполагают, что раскрытие секрета во внутреннем репозитории менее опасно, потому что он не подвержен публичной проверке. Однако такой подход означает тихое накопление захардкоженных секретов, которые планируется удалить «позже».

Один утёкший секрет может стать быстрым путём для горизонтального перемещения по инфраструктуре. Фокусировка контролей исключительно на обнаружении утечек в публичном коде упускает наиболее рискованную часть проблемы утечек организации.

Что хранится во внутренних репозиториях

Внутренние репозитории, как правило, содержат самые критичные учётные данные:

• CI/CD-токены для интеграций и развёртывания
• Ключи облачных платформ с широкими привилегиями
• Учётные данные баз данных для продуктовых сред
• Токены внутренних инструментов для мониторинга, журналирования, управления секретами

Это именно те активы, на которые рассчитывают атакующие после получения первоначальной точки входа.

Пассворк разворачивается на серверах компании — все данные остаются внутри вашей инфраструктуры. Детальный контроль доступа, ролевая модель и журнал всех действий с секретами дают ИТ-отделу полную видимость того, кто, когда и к чему обращался. Протестируйте Пассворк бесплатно

Утечки за пределами кода: Slack, Jira, Confluence

Секреты утекают не только из исходного кода. Учётные данные в открытом виде также появляются в инструментах для совместной работы и повышения продуктивности — Slack, Jira, Confluence. Эти платформы упрощают вставку ключей доступа, часто для ускорения устранения неполадок, реагирования на инциденты или просто повседневной координации.

28% инцидентов в 2025 году произошли полностью вне кода, в том, что GitGuardian называет «Other Data Sources» (другие источники данных, ODS). Большинство инцидентов (68%) по-прежнему приходится на код в системах контроля версий (таких как Git). Однако пересечение секретов, найденных и в системах контроля версий, и в других источниках данных, удивительно мало: всего 4%.

Это согласуется с более широкой закономерностью, которую GitGuardian выделял в предыдущих отчётах: секреты, обнаруженные в системах контроля версий и в инструментах совместной работы, как правило, в значительной степени не пересекаются. Это означает: компании часто используют менеджеры секретов и хранилища для защиты секретов от раскрытия в коде, но те же самые секреты небезопасно передаются и утекают через каналы совместной работы.

Сканирование только кода упустит значимую часть утечек. Секреты из других источников данных (ODS) опаснее: секреты, переданные через Slack, Jira, Confluence и подобные инструменты, чаще получают рейтинг критической или высокой опасности по сравнению с секретами, найденными только в коде.

Распределение по уровню опасности (2025):

Секреты из ODS на 13 процентных пунктов чаще классифицируются как критические (56,7% против 43,7%).

Почему ODS-утечки опаснее: секреты, утёкшие из ODS, часто передаются во время срочного устранения неполадок или реагирования на инциденты. С другой стороны, в большинстве организаций почти весь исходный код проходит структурированные и многоуровневые проверки, включая процессы работы с Git и проверки при непрерывной интеграции, поэтому многие критичные утечки обнаруживаются раньше.

GitLab и Docker: 80 000 секретов в открытом доступе

Исследование GitGuardian в 2025 году выявило, что тысячи развёрнутых на собственной инфраструктуре экземпляров GitLab и реестров Docker оставались доступными в интернете без надлежащей аутентификации. Эти непреднамеренно публично открытые ресурсы были проанализированы на предмет секретов, что привело к обнаружению 80 000 учётных данных. 10 000 из них оказались действующими — то есть немедленно пригодными для использования злоумышленниками.

Распределение:

GitLab-репозитории содержали больший общий объём секретов (57 000), но меньший процент валидных (12%). Напротив, Docker-образы содержали меньше секретов в абсолютных числах (23 000), но 15% из них оказались рабочими.

Находки в Docker особенно тревожны, поскольку, в отличие от экземпляров GitLab, образы Docker предназначены для распространения и обычно передаются между множеством кластеров и узлов, что усиливает опасность.

Близость к продуктовой среде = выше вероятность действующего секрета

Чем ближе актив к проду, тем выше вероятность обнаружить валидные учётные данные.

Примеры по типам секретов:

Разрыв особенно широк для секретов систем контроля версий: 40% действующих в контейнерах Docker против всего 2% в GitLab — и для учётных данных хранилищ данных: 32% против 4% соответственно.

Эффект вложенной экспозиции

Исследование подтверждает критическую закономерность распространения секретов: учётные данные из закрытых ресурсов попадают в образы Docker, которые впоследствии оказываются доступны публично. Возникает каскадный сценарий компрометации: публично открытые утечки содержат действующие секреты, открывающие доступ к закрытой инфраструктуре. Это, в свою очередь, обнажает дополнительные секреты и многократно усиливает масштаб первоначального инцидента.

Дополнительные находки

Помимо секретов, публично открытые данные также содержали сильные индикаторы приватных ресурсов, которые никогда не предназначались для публичного доступа:

• Ссылки на внутренние узлы баз данных и закрытые инфраструктурные шаблоны
• Уведомления о конфиденциальности и защите персональных данных внутри кода
• Значительный объём персональных данных, включая более 300 000 адресов электронной почты, из которых 2 000 имели государственные домены (.gov)

Частота утечек

GitGuardian обнаружили секреты в 12% просканированных GitLab-репозиториев и 18% просканированных Docker-образов. Эти проценты отражают уровень экспозиции на уровне отдельных активов внутри уже обнаруженных экземпляров GitLab и реестров Docker, развёрнутых на собственной инфраструктуре.

Примерно 18% Docker-реестров стали недоступными всего через несколько недель после обнаружения сканированием. Однако в нескольких случаях учётные данные, которые были открыты, оставались валидными даже после того, как публичный доступ был отозван.

При объединении с другими находками это показывает, что частота утечек из Docker и GitLab, развёрнутых на собственной инфраструктуре, в 3–4 раза выше по сравнению с публичными хранилищами GitHub. Это означает: захардкоженные секреты в закрытых ресурсах — это недооценённый риск безопасности для слишком многих команд.

64% секретов 2022 года до сих пор действуют

Каждый год GitGuardian анализирует новые данные об утечках, но также повторно проверяет предыдущие находки, чтобы выявить закономерности во времени. В отчёте State of Secrets Sprawl 2025 было показано, что почти 70% учётных данных, подтверждённых как действующие в 2022 году, всё ещё оставались действующими по состоянию на январь 2025 года.

Когда тот же датасет был повторно протестирован в январе 2026 года, уровень валидности остался выше 64%. Это означает, что эти секреты могли быть использованы любым, кто их обнаружит, на протяжении четырёх лет.

Это подтверждает общую тенденцию, впервые замеченную в прошлом году: как только реальные учётные данные утекают в публичный коммит, они часто остаются пригодными для использования гораздо дольше, чем любая команда сочла бы приемлемым.

Почему секреты не ротируются

Корень проблемы: у большинства организаций нет процессов для быстрой и безопасной ротации секретов. Команды работают с долгоживущими учётными данными, которые изначально не проектировались для регулярной смены.

Отозвать и заменить такой секрет — значит обновить конфигурации во всех средах, перезапустить сервисы, синхронизировать изменения между командами и убедиться, что ничего не сломалось. Без автоматизации это превращается в многочасовую операцию с риском простоя. Поэтому организации выбирают путь наименьшего сопротивления: оставить всё как есть и надеяться, что секрет не найдут злоумышленники.

Результат: обнаружение утечки не решает проблему — оно лишь фиксирует её существование. Пока ротация требует ручной работы, секреты будут оставаться действующими годами.

Пассворк автоматизирует ротацию секретов и даёт полный контроль над жизненным циклом учётных данных. Централизованное хранилище, журнал аудита и интеграция с Active Directory позволяют закрыть цикл «обнаружение → отзыв → ротация» без ручных операций. Протестируйте бесплатно в своей инфраструктуре

Инфраструктура разработки: новый вектор

Рабочие станции разработчиков всегда были частью поверхности атаки, но в 2025 году произошёл качественный сдвиг: атаки на цепочку поставок через npm стали целенаправленно собирать секреты с машин разработчиков в промышленных масштабах.

Кейс Shai-Hulud: атака через компрометацию npm-пакетов

В августе 2025 года злоумышленники внедрили вредоносный код в популярные npm-пакеты. Код выполнялся автоматически при установке и систематически сканировал машины разработчиков:

• Собирал файлы окружения (.env, .bashrc, .zshrc)
• Извлекал конфигурационные файлы приложений
• Сканировал кэши сред разработки и результаты сборок
• Отправлял найденные секреты на управляющий сервер

GitGuardian проанализировал данные этой атаки, повторно просканировав их своим движком обнаружения. Результаты показывают реальную картину того, сколько секретов хранится на типичной рабочей станции разработчика.

Статистика компрометации

Ключевой вывод: каждый действующий секрет в среднем встречался в восьми разных местах на одной машине — в конфигурационных файлах, профилях оболочки, результатах сборки, настройках IDE и кэшах инструментов. Каждая копия — независимый вектор для кражи.

Распределение секретов

• 44% скомпрометированных машин содержали более 10 секретов
• 5% машин несли более 100 секретов

Типы обнаруженных учётных данных

Токены GitHub доминировали в проверенном наборе:

• 581 персональный токен доступа
• 386 токен OAuth
• 104 детализированный токен доступа
• 101 токен GitLab

Каждый из этих токенов обеспечивает доступ к репозиториям, позволяет манипулировать CI/CD-процессами или открывает путь для бокового перемещения по цепочке поставок.

CI/CD-агенты как точка концентрации риска

59% скомпрометированных машин оказались CI/CD-агентами, а не личными рабочими станциями. Это означает, что атака затронула не только индивидуальных разработчиков, но и общую инфраструктуру сборки — узлы с повышенными привилегиями и доступом к продуктовым средам.

Реальная плотность секретов выше

Атаки выполнялись только там, где был установлен вредоносный пакет. Они не достигали папок памяти агентов, кешей сред разработки или растущей поверхности атаки артефактов, генерируемых искусственным интеллектом, которые теперь рутинно включают учётные данные. Реальная плотность секретов на машинах разработчиков почти наверняка выше.

Что делать: от обнаружения секретов к управлению

Разработка с помощью искусственного интеллекта перешла от эксперимента к стандарту. С ней приходит всплеск секретов: служебные учётные записи, ключи интерфейсов, токены агентов, конфигурации протокола контекста модели — все аутентифицирующиеся, все действующие, все способные утечь.

Данные показывают, что разрыв расширяется:

• Коммиты, созданные совместно с Claude Code, утекают в два раза чаще базового уровня
• Утечки инфраструктуры больших языковых моделей растут в пять раз быстрее, чем у основных поставщиков
• Только конфигурации протокола контекста модели обнажили более 24 000 секретов в первый год

Это больше не проблема обнаружения. Это проблема управления. И управление начинается с трёх вопросов, на которые каждая организация должна ответить:

1. Какие секреты существуют в вашей среде?
2. Кто ими владеет?
3. К чему они имеют доступ?

Если вы не можете ответить на все три, ваше внедрение искусственного интеллекта опережает вашу позицию безопасности.

Путь от распространения секретов к контролю:

1. Централизовать хранение секретов. Единый источник правды. Исключить «самодельные» хранения. Когда команды могут надёжно извлекать секреты из одного источника, они перестают изобретать собственные фрагментированные стратегии хранения — основной драйвер распространения секретов.
2. Автоматизировать ротацию. Сократить окно эксплуатации. Если секрет должен существовать, он не должен жить вечно. Регулярная замена действующих секретов сокращает окно атаки и заставляет команды трактовать учётные данные как актив с жизненным циклом, а не как разовую настройку.
3. Сделать безопасный путь удобнее захардкоженных ключей. Устранить файлы окружения и скопированные токены. Разработчики будут продолжать встраивать секреты в код, потому что это работает и позволяет выпустить функциональность. Единственный устойчивый подход — сделать создание, хранение и вызов действующих секретов проще и привлекательнее, чем захардкодить ключи.
4. Сканировать на рабочей станции (до коммита). Инструменты вроде ggshield и расширения для сред разработки не допускают секрет до репозитория. Раннее сканирование предотвращает инциденты. Современные инструменты помогают командам остановить утечку до того, как секрет попадёт в репозиторий навсегда.
5. Распространить мониторинг за пределы кода. Slack, Jira, Confluence, реестры Docker. 28% инцидентов происходят вне кода, и они на 13% чаще критические. Сканирование только репозиториев покрывает ~72% поверхности.
6. Внедрить приоритизацию на основе рисков. Обогащение контекстом и оценка рисков вместо подхода «только проверка». 46% критических секретов пропускаются при подходе «только проверка». Необходимо понимать, что каждый секрет разблокирует, оценивать привилегии и область действия, обрабатывать длинный хвост и приоритизировать на основе фактического влияния на бизнес.

Первый шаг к управлению секретами — централизованное хранилище с контролем доступа и автоматической ротацией. Пассворк закрывает этот критический пробел: локальное развёртывание, интеграция с LDAP/AD, API для автоматизации и полный журнал аудита. Протестируйте бесплатно — узнайте, как корпоративный менеджер паролей превращает обнаружение в управление.

Ключевые выводы

2025 год стал переломным для разработки ПО. ИИ-ассистенты превратили разработку из узкопрофессионального занятия в массовую практику менее чем за 12 месяцев. Стек инструментов ИИ с десятками новых сервисов и токенов стал нормой. Это привело к рекордному числу утечек секретов — 28,65 миллиона на одном только публичном GitHub, рост на 34% год к году.

Пять главных выводов

1. ИИ ускоряет расползание секретов. Рост утечек секретов ИИ на 81,5%, коммиты Claude Code с удвоенной частотой утечек, более 24 000 секретов в конфигурациях — всё это симптомы одной проблемы: команды создают новые токены, ключи и учётные записи сервисов быстрее, чем успевают выстроить процессы управления ими. Модели улучшаются, но ответственность за безопасность остаётся на разработчике и организационных процессах.
2. Внутренние системы — главная зона риска. Внутренние репозитории в шесть раз чаще содержат секреты, чем публичные. 28% инцидентов происходят вне кода и они на 13% чаще критические. Собственные экземпляры GitLab и Docker показывают частоту утечек в 3–4 раза выше, чем публичный GitHub. Приватность — не мера защиты.
3. Устранение отстаёт от обнаружения. 64% секретов 2022 года всё ещё действуют в 2026-м. Обнаружение бесполезно без замкнутого цикла отзыва и ротации. Секреты встроены в системы сборки, переменные непрерывной интеграции, контейнеры. Их ротация — комплексный процесс, который большинство организаций не автоматизировали.
4. Подход «только проверка» — ложная безопасность. 46% критических секретов пропускаются при подходе «только проверка». Универсальные секреты (пароли, приватные ключи, пользовательские токены) составляют 35% критических инцидентов, но массово игнорируются. Необходим переход к приоритизации на основе рисков: обогащение контекстом, оценка рисков и полное покрытие.
5. Переход к управлению машинными идентичностями — стратегическая необходимость. Цель — не только находить утёкшие строки, но непрерывно доказывать, какие машинные идентичности существуют, кто ими владеет и к чему они имеют доступ. Это начинается с централизации секретов, автоматизации ротации, улучшения опыта разработчиков.

Расползание секретов — это проблема управления. Недостаточно найти утёкший токен — нужно его отозвать, ротировать и предотвратить повторную утечку. Организации, которые выстроят процессы централизованного хранения, автоматической ротации и контроля доступа, смогут масштабировать защиту. Те, кто продолжат только искать утечки, не закрывая их системно, останутся уязвимы к самым критичным атакам.

Пассворк помогает организациям сделать первый и фундаментальный шаг: централизовать хранение секретов, контролировать доступ и автоматизировать ротацию. Попробуйте Пассворк бесплатно и узнайте, как корпоративный менеджер паролей и секретов закрывает критический пробел между обнаружением и управлением.

Часто задаваемые вопросы

Что такое захардкоженные секреты и почему они опасны?

Захардкоженные секреты — это учётные данные (API-ключи, токены, пароли, приватные ключи), встроенные непосредственно в исходный код или конфигурационные файлы. Когда такой код попадает в систему контроля версий, секрет становится частью истории репозитория навсегда — даже после удаления из текущей версии. Один утёкший секрет может открыть доступ к продуктовой базе данных, облачной инфраструктуре или CI/CD.

Почему утечки секретов растут быстрее числа разработчиков?

С 2021 года утечки секретов выросли на 152%, в то время как число разработчиков увеличилось на 98%. Главный драйвер — рост объёма кода (+42,7% за год) и количества интегрируемых сервисов. ИИ-инструменты ускоряют разработку, но каждый новый сервис требует новых токенов и ключей. Команды создают учётные данные быстрее, чем успевают выстроить процессы управления ими.

Как ИИ-ассистенты влияют на утечки секретов?

Коммиты с участием Claude Code содержали секреты в 3,2% случаев против 1,5% для обычных коммитов — в два раза чаще. Утечки секретов ИИ-сервисов выросли на 81,5% за год. Инфраструктура вокруг больших языковых моделей (системы поиска, векторные базы, оркестрация) «течёт» в пять раз быстрее, чем ключи от самих моделей. Проблема не в моделях, а в скорости создания новых интеграций без зрелых практик безопасности.

Почему внутренние репозитории опаснее публичных?

32,2% внутренних репозиториев содержат захардкоженные секреты против 5,6% публичных — в шесть раз больше. Команды менее осторожны внутри закрытого периметра, предполагая, что приватность защищает. Но внутренние репозитории содержат самые критичные учётные данные: CI/CD-токены, ключи облачных платформ с широкими привилегиями, доступы к базам данных. Один утёкший секрет становится быстрым путём для горизонтального перемещения по инфраструктуре.

Почему секреты остаются действующими годами после обнаружения?

64% секретов, обнаруженных в 2022 году, всё ещё действуют в 2026-м — спустя четыре года. Ротация — не одна кнопка, а комплексный процесс: секреты встроены в системы сборки, скопированы в несколько хранилищ, запечены в образы контейнеров, указаны в переменных непрерывной интеграции, распределены между командами. Большинство организаций не автоматизировали этот процесс. Обнаружение бесполезно без замкнутого цикла отзыва и ротации.

Что такое подход «только проверка» и почему он не работает?

Многие команды сканируют только те секреты, которые можно автоматически проверить на валидность. Но 46% критических секретов невозможно проверить автоматически — это пароли к базам данных, приватные ключи, внутренние токены. Они составляют 35% критических инцидентов, но массово игнорируются. Правильный подход — оценивать каждый секрет по контексту: к чему он даёт доступ, какие привилегии открывает, насколько критична система.

Где ещё утекают секреты, кроме кода?

28% инцидентов в 2025 году произошли вне кода — в Slack, Jira, Confluence. Секреты из этих источников на 13% чаще получают рейтинг критической опасности (56,7% против 43,7% для кода). Учётные данные передаются в чатах во время срочного устранения неполадок или реагирования на инциденты. Сканирование только репозиториев покрывает ~72% поверхности атаки — четверть уязвимостей остаётся невидимой.

Что такое управление машинными идентичностями (NHI)?

Машинные идентичности (Non-Human Identities, NHI) — это любые механизмы аутентификации для автоматических систем: API-токены, ключи доступа, учётные записи сервисов, сертификаты. С развитием ИИ-разработки их количество взрывообразно растёт. Управление NHI означает непрерывно доказывать, какие машинные идентичности существуют, кто ими владеет и к чему они имеют доступ. Это начинается с централизации секретов, автоматизации ротации и постепенного перехода к краткосрочным учётным данным на основе идентичности.

Как защитить конфигурации протокола контекста модели (MCP)?

За 2025 год в MCP-конфигурациях обнаружено 24 008 секретов, 8,8% действующих. Лучшие практики: никогда не храните секреты в конфигурационных файлах — используйте переменные окружения через менеджер секретов; клиенты, а не серверы, должны владеть секретами; исключите конфигурационные файлы из системы контроля версий; сканируйте перед отправкой в репозиторий; требуйте ручного подтверждения перед действиями MCP, затрагивающими продуктовые системы.

С чего начать защиту от утечек секретов?

Первый шаг — централизовать хранение секретов в едином защищённом хранилище. Это исключает «самодельные» стратегии хранения — основной драйвер распространения секретов. Затем: автоматизируйте ротацию критичных учётных данных; внедрите сканирование на рабочих станциях до коммита; распространите мониторинг на Slack, Jira, Confluence, Docker-реестры; перейдите от подхода «только проверка» к приоритизации на основе рисков; начните миграцию на аутентификацию на основе идентичности для машинных идентичностей.

Первый менеджер паролей с сертификацией ФСТЭК России

30 апреля 2026 года Пассворк получил сертификат ФСТЭК России № 5063 по 4-му уровню доверия — наивысшему для коммерческих средств защиты информации. Пассворк стал первым российским менеджером паролей, который может применяться в ГИС, ИСПДн, КИИ и АСУ ТП 1 класса защищённости.

Блог ПассворкаИлья Шелыгин

Атака на цепочку поставок: взлом Bitwarden CLI, Shai-Hulud и выводы

Зачем атаковать защищённую корпоративную сеть, если можно взломать npm-пакет с миллионами скачиваний? Разбираем три резонансных инцидента 2026 года: компрометацию Bitwarden CLI через GitHub Actions, вредонос в Axios и утечку OAuth-токенов через Vercel. Что их объединяет и как защитить CI/CD.

Блог ПассворкаИлья Шелыгин

Главные киберугрозы апреля 2026: базовые ошибки и миллионы потерь

Взлом Vercel на $2 млн через AI-ассистента, утечка данных Vimeo и Rockstar Games через скомпрометированного подрядчика Anodot, фишинг с официального домена Apple — рассмотрим механику атак через цепочку поставок и покажем, как базовые ошибки в управлении доступом приводят к критическим инцидентам.

Блог ПассворкаИлья Шелыгин