Масштаб проблеми хардкодених секретів у коді та інфраструктурі продовжує зростати й перетворюється на один із ключових системних ризиків для сучасних DevOps та AI-команд. Згідно зі звітом GitGuardian State of Secrets Sprawl 2026, лише за 2025 рік на публічному GitHub було виявлено 29 млн нових секретів — це +34% за рік і найшвидший темп зростання за всю історію спостережень.
Вибухове зростання витоків секретів у відкритому коді
Як показує динаміка з 2021 року, проблема витоків секретів (tokens, API-ключі, паролі до БД, хмарні креденшали) зростає швидше, ніж сама екосистема розробників. Обсяг знайдених секретів збільшився на 152%, тоді як кількість публічних розробників на GitHub — на 98%. Це означає, що кожен новий розробник і кожен новий репозиторій статистично приносять більше ризику, ніж кілька років тому.
На це впливають одразу два фактори. По-перше, масштабна автоматизація та прискорення релізів у DevOps-практиках, де секрети часто потрапляють у код, CI/CD пайплайни та конфігурації. По-друге, масове використання генеративного ІІ для написання коду: багато моделей відтворюють небезпечні патерни роботи з секретами або ж «навчені» на вже скомпрометованих прикладах з публічних репозиторіїв.
Інтеграція AI-сервісів: новий вибуховий сегмент витоків
Особливо швидко зростає сегмент секретів, пов’язаних з інфраструктурою штучного інтелекту. У 2025 році GitGuardian зафіксував 1 275 105 витоків AI-секретів, що на 81% більше, ніж роком раніше. Вісім із десяти найдинамічніших категорій ключів були безпосередньо пов’язані з ІІ.
Йдеться не лише про токени OpenAI чи Anthropic. Основний приріст забезпечила інфраструктура навколо LLM: retrieval-API на кшталт Brave Search (+1255%), сервіси оркестрації на кшталт Firecrawl (+796%) та керовані бекенди на зразок Supabase (+992%). Кожен новий інтеграційний шар створює ще одну машинну ідентичність і, відповідно, збільшує поверхню атаки.
Внутрішні репозиторії, Slack і Jira: де ховаються найкритичніші секрети
Фокус безпеки часто зосереджується на публічному GitHub, однак найцінніші секрети зазвичай живуть у внутрішніх системах. За даними GitGuardian, 32,2% внутрішніх репозиторіїв містять щонайменше один хардкодений секрет, тоді як серед публічних репозиторіїв таких лише 5,6%. Усередині організації це, як правило, не тестові ключі, а токени CI/CD, хмарні облікові дані, паролі до продуктивних БД — саме ті активи, що найчастіше використовуються зловмисниками після первинного проникнення.
Секрети дедалі частіше виходять за межі репозиторіїв вихідного коду. У 28% інцидентів 2025 року вони були виявлені виключно в колаборативних інструментах — Slack, Jira, Confluence та їхніх аналогах. Такі витоки виявилися більш критичними: 56,7% секретів, знайдених лише у корпоративних сервісах, класифіковано як критичні проти 43,7% для інцидентів, обмежених репозиторіями. Причина очевидна: команди активно діляться креденшалами під час розслідувань інцидентів, відладки чи онбордингу, часто без будь-яких технічних обмежень або політик.
Контейнерна безпека: Docker-образи та self-hosted 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-атаки, AI-агенти та Model Context Protocol
Цепочки поставок ПЗ залишаються одним із ключових каналів доступу до секретів. Під час атаки Shai-Hulud 2 дослідники отримали рідкісний погляд на те, як виглядають секрети на скомпрометованих робочих станціях розробників. На 6 943 системах було знайдено 294 842 входження секретів, що відповідають 33 185 унікальним значенням. У середньому кожен активний секрет зустрічався в 8 різних місцях на одній машині: у .env-файлах, історії командної строки, конфігураціях IDE, кешованих токенах, артефактах збірки. Показово, що 59% цих систем були раннерами CI/CD, а не персональними ноутбуками.
Більш свіжа supply chain-атака на пакет LiteLLM продемонструвала аналогічний підхід: шкідливий код збирав SSH-ключі, хмарні креденшали та API-токени з машин розробників — саме там сьогодні концентруються інструменти роботи з ІІ. Окремим вектором ризику стають фреймворки на кшталт Model Context Protocol (MCP) для «агентного ІІ»: у публічних MCP-конфігураціях за 2025 рік виявлено 24 008 унікальних секретів, з яких 2 117 підтверджені як валідні. Поширена практика зберігання ключів у config-файлах, параметрах запуску та локальних JSON ще більше закріплюється.
Від пошуку витоків до управління нефізичними ідентичностями (NHI)
Сучасні програми кібербезпеки дедалі частіше впираються у три базові питання: скільки нефізичних (machine) ідентичностей існує в інфраструктурі, хто за них відповідає та до яких ресурсів вони мають доступ. Під нефізичними ідентичностями (Non-Human Identities, NHI) маються на увазі сервісні акаунти, CI-завдання, мікросервіси, контейнерні ворклоади, AI-агенти — усе, що працює з правами доступу, але не є людиною.
Ставитися до секретів як до окремих інцидентів уже недостатньо. Організаціям, які активно впроваджують ІІ та інтенсивний DevOps, потрібен перехід від разового сканування репозиторіїв до безперервного управління NHI: максимальна відмова від довгоживучих статичних ключів, перехід до короткоживучих токенів на основі ідентичності, використання secret vaults як стандартного девелоперського патерна і повноцінне управління життєвим циклом кожної нефізичної ідентичності в рамках IAM. Компаніям варто вже зараз розширити зону видимості за межі публічних репозиторіїв — на внутрішні системи, колаборативні сервіси, контейнерні реєстри та робочі станції розробників — і вибудувати автоматизовані процеси ротації й відкликання ключів. Ті, хто зробить це раніше за інших, матимуть не лише вищий рівень захисту, а й кращу стійкість до майбутніх хвиль атак на DevOps- та AI-інфраструктуру.
