Коли державний підрядник, що працює з Агентством з кібербезпеки та безпеки інфраструктури США (CISA), залишає відкритим публічний GitHub‑репозиторій із хмарними ключами, токенами, логами та паролями у відкритому тексті — це не просто черговий інцидент. Це концентрований кейс про те, як ламається керування ідентичностями та доступами (IAM) у 2026 році, і чому корпоративні звички на кшталт «Company2024!» більше не можна вважати безпечними.
Про цей витік детально писав відомий дослідник безпеки Браян Кребс. У подкасті IBM Security Intelligence його обговорювали фахівці з безпеки Kimmie Farrington, Dustin “EvilMog” Heywood та Curtis Pitts — на тлі ширшої розмови про сучасні інструменти на кшталт AI‑моделі Mythos. Але історія з GitHub‑репозиторієм CISA виявилася показовою сама по собі: вона оголила одразу кілька системних проблем — від культури паролів до управління секретами в хмарі.
Як один GitHub‑репозиторій перетворився на «ключі від квартири»
За даними Кребса, підрядник CISA протягом місяців тримав публічним репозиторій на GitHub, у якому лежало те, чого там не має бути за визначенням: хмарні ключі, токени доступу, паролі у відкритому тексті, журнали, інші чутливі артефакти. Репозиторій був доступний будь‑кому, хто знайшов би його через пошук або випадковий перегляд.
Дослідники, які встигли проаналізувати вміст до видалення репозиторію, виявили, що частина цих облікових даних давала реальний доступ до хмарних серверів та середовищ безпечної розробки коду. Тобто це були не «тестові» чи «застарілі» секрети, а робочі ключі до інфраструктури та ланцюга постачання програмного забезпечення.
Це важливий момент. Коли в одному місці одночасно опиняються:
- облікові дані до хмари,
- токени сервісів,
- паролі до середовищ розробки,
- журнали, що підказують структуру систем,
репозиторій перестає бути просто витоком паролів. Він стає потенційною точкою повного компромісу: від інфраструктури до коду, який потім розгортається клієнтам.
Репозиторій уже видалили, а публічних доказів того, що зловмисники встигли скористатися цими даними, наразі немає. Але тривала публічна експозиція створила величезне, майже невимірюване «вікно атаки». Навіть якщо жодних інцидентів не виявлено сьогодні, немає гарантії, що облікові дані не були тихо скопійовані й не «дозрівають» десь у приватних наборах для майбутніх атак.
Вразливий ланцюг постачання: коли GitHub стає точкою входу
Те, що дослідники знайшли в репозиторії CISA, добре ілюструє, як легко один прорахунок у керуванні репозиторіями перетворюється на ризик для всього ланцюга постачання.
Доступ до хмарних серверів означає можливість:
- змінювати конфігурації,
- розгортати нові ресурси,
- читати або змінювати дані, які зберігаються в цих середовищах.
Доступ до «secure code development environments» — середовищ безпечної розробки — відкриває інший вимір загроз. Це вже не просто інфраструктура, а сам код, який потім потрапляє в продакшн. Компрометований обліковий запис розробника або сервісний токен у такому середовищі може дозволити:
- вносити непомітні зміни в репозиторії,
- додавати бекдори,
- змінювати залежності або CI/CD‑конфігурації так, щоб шкідливий код потрапляв у збірки.
У сучасних ланцюгах постачання ПЗ GitHub, GitLab та інші платформи розробки — це не просто «сховище коду». Це вузли, через які проходять ключі, токени, секрети для CI/CD, конфігурації хмарних розгортань. Якщо контроль доступу до таких репозиторіїв налаштовано неправильно, вони стають ідеальними точками входу для атак на ланцюг постачання.
Кейс CISA показує, що навіть організації, які мають бути еталоном кібергігієни, можуть припускатися базових помилок: тримати секрети в репозиторіях, робити їх публічними, не відстежувати експозицію місяцями. Це не лише проблема окремого підрядника; це симптом ширшої хвороби IAM‑практик у корпоративному світі.
Паролі «Platform2023» як системна вада, а не дрібна недбалість
Окремий тривожний сигнал у цій історії — якість самих паролів, що опинилися у відкритому доступі. Частина з них, за повідомленнями, будувалася за типовими слабкими шаблонами: назва платформи плюс рік. Це не унікальна вада конкретної команди; це віддзеркалення звичок, які десятиліттями культивувалися в корпоративних середовищах.
У дискусії експерти згадували найпоширеніші патерни, які бачать у великих організаціях:
- сезон плюс рік плюс знак оклику — «Spring2024!», «Winter2023!»;
- місяць плюс рік плюс знак оклику — «March2024!»;
- назва компанії плюс рік плюс знак оклику — «Acme2024!».
Для людини, яка не займається безпекою, такі паролі можуть здаватися «достатньо складними»: є великі й малі літери, цифри, спецсимвол. Але для сучасних інструментів зламу паролів це фактично вже «попередньо зламані» шаблони.
Сучасні словникові атаки та генератори кандидатів не перебирають випадкові послідовності символів. Вони будуються навколо реальних людських звичок: назв компаній, сезонів, років, типових суфіксів. Патерни на кшталт «SeasonYYYY!» або «CompanyYYYY!» давно зашиті в правилах генерації, а отже, такі паролі опиняються в перших хвилинах атаки, а не в її кінці.
Коли подібні паролі ще й зберігаються у відкритому тексті в репозиторіях, ситуація стає подвійно небезпечною. З одного боку, їх легко вгадати. З іншого — їх можна просто прочитати, якщо хтось випадково або навмисно відкрив доступ до репозиторію.
Це не дрібна недбалість окремих співробітників. Це наслідок корпоративних політик, які десятиліттями заохочували «запам’ятовувані» паролі з обов’язковою ротацією раз на 60–90 днів. Люди адаптувалися, створивши передбачувані схеми: змінювати рік, місяць або сезон, додаючи мінімальні варіації. Для атакуючих це подарунок.
Чому парольні звички підприємств більше не витримують реальності
Історія з CISA вкладається в ширшу картину: традиційна модель «людина вигадує і пам’ятає складний пароль» у корпоративному середовищі більше не працює.
Є кілька причин, чому це стало очевидним:
По‑перше, обсяг секретів. Середній співробітник великої організації має десятки облікових записів: внутрішні портали, SaaS‑сервіси, VPN, хмара, інструменти розробки. Очікувати, що людина створить для кожного унікальний, довгий і непередбачуваний пароль і при цьому не буде його повторно використовувати, — нереалістично.
По‑друге, вимоги до ротації. Часті зміни паролів, які досі прописані в багатьох політиках, штовхають користувачів до мінімальних модифікацій: додати «1», змінити рік, пересунути знак оклику. З точки зору зламу це не новий пароль, а варіація старого, яку легко передбачити.
По‑третє, автоматизація атак. Інструменти на кшталт Hashcat, сучасні словники, злиті бази даних паролів і готові правила генерації кандидатів зробили людські патерни прозорими. Те, що колись здавалося «хитрим» паролем, сьогодні — просто ще один рядок у словнику.
По‑четверте, мультивекторність загроз. Навіть якщо пароль не вгадали, він може бути вкрадений через фішинг, кейлогери, витоки з інших сервісів, де користувач його повторно використав. Або, як у випадку з CISA, просто опинитися в репозиторії, який хтось випадково зробив публічним.
У такій реальності спроби «навчити людей придумувати кращі паролі» виглядають як боротьба з симптомами, а не з причиною. Потрібні інші підходи до керування секретами.
Менеджери паролів і passkeys: вихід із пастки людської пам’яті
На тлі кейсу CISA експерти з подкасту наголошували: настав час мінімізувати залежність від паролів, які вигадує людина. Особливо в середовищах, де:
- вимагається часта ротація,
- є багато різних секретів,
- критично важлива точність і непередбачуваність облікових даних.
Перший очевидний інструмент — менеджери паролів. Вони дозволяють:
- генерувати довгі, випадкові паролі, які не підкоряються людським патернам;
- зберігати їх у зашифрованому вигляді;
- автоматично підставляти в потрібні поля, зменшуючи спокусу копіювати секрети в текстові файли чи репозиторії.
У корпоративному контексті це означає, що розробники та адміністратори не повинні тримати паролі до баз даних, хмарних акаунтів чи CI/CD‑систем у коді або конфіг‑файлах. Замість цього секрети зберігаються в спеціалізованих сховищах, інтегрованих із менеджерами паролів і системами керування доступом.
Другий напрям — перехід до безпарольних технологій, насамперед passkeys. Вони базуються на криптографічних ключах, прив’язаних до пристрою користувача, і не вимагають запам’ятовування рядків символів. Навіть якщо база даних сервісу буде скомпрометована, зловмисник не отримає «пароль» у звичному розумінні — лише публічний ключ, який не дає можливості увійти від імені користувача.
Для підприємств це означає поступовий відхід від паролів як основного фактора автентифікації, особливо для доступу до критичних систем. Там, де це можливо, варто впроваджувати:
- апаратні токени,
- FIDO2‑ключі,
- платформені passkeys на базі мобільних пристроїв або ноутбуків.
Менеджери паролів і passkeys не скасовують потребу в політиках безпеки, але радикально зменшують площу, де людський фактор може зламати всю модель.
Active Directory: хеші як повноцінні «паролі» і чому ротація все одно потрібна
Окремий пласт проблеми IAM у великих організаціях — це середовища, побудовані навколо Active Directory (AD). У таких інфраструктурах паролі користувачів зберігаються не у відкритому вигляді, а у вигляді хешів. Часто можна почути хибне уявлення: мовляв, якщо зловмисник отримав лише хеш, а не сам пароль, то ризик обмежений.
Експерти наголошують: у контексті AD хеші паролів фактично є еквівалентом самих паролів. Причина в тому, що існують техніки на кшталт pass‑the‑hash, які дозволяють автентифікуватися в системі, не знаючи вихідного пароля, а лише маючи його хеш. Для служби, яка перевіряє облікові дані, це виглядає як легітимний вхід.
Це має два важливі наслідки для інцидентів на кшталт витоку репозиторію CISA:
По‑перше, якщо в логах, дампах пам’яті або інших артефактах, що опинилися у відкритому доступі, є хеші AD‑паролів, їх потрібно вважати повноцінно скомпрометованими. Неважливо, чи вдалося зловмиснику «розколоти» хеш і відновити текст пароля; сам хеш уже можна використати для доступу.
По‑друге, ротація все одно обов’язкова. Після будь‑якого витоку, де могли опинитися хеші, організація має змінити відповідні паролі. Інакше ризик pass‑the‑hash‑атак зберігається невизначено довго, навіть якщо жодних ознак активної експлуатації немає.
У середовищах, де AD залишається «серцем» ідентичності, це ще один аргумент на користь:
- централізованого керування секретами,
- мінімізації кількості облікових записів із високими привілеями,
- використання менеджерів паролів для сервісних акаунтів,
- впровадження багатофакторної автентифікації поверх паролів.
І, знову ж таки, це аргумент проти зберігання будь‑яких облікових даних — навіть хешів — у місцях, які можуть випадково стати публічними, як‑от репозиторії коду.
IAM як «кібергігієна», а не разова ініціатива
Історія з GitHub‑репозиторієм CISA добре вписується в тезу, яку все частіше повторюють фахівці: керування ідентичностями та доступами — це не окремий проєкт, а постійна гігієна. Як би не розвивалися інструменти — від AI‑моделей на кшталт Mythos до нових сканерів вразливостей — базові помилки IAM здатні нівелювати будь‑які технологічні досягнення.
У цьому сенсі інцидент CISA показує одразу кілька уроків:
По‑перше, контроль над репозиторіями коду — це елемент IAM. Потрібно не лише керувати правами доступу до GitHub чи GitLab, а й мати процеси, які запобігають потраплянню секретів у репозиторії. Це включає:
- використання сканерів секретів у CI/CD,
- політики, що забороняють зберігання паролів і ключів у коді,
- навчання розробників роботі з секрет‑менеджерами.
По‑друге, якість паролів — це не питання «дисципліни співробітників», а наслідок політик. Якщо організація вимагає частих змін і не дає зручних інструментів на кшталт менеджерів паролів, вона фактично штовхає людей до патернів «Spring2024!». Змінювати потрібно не лише поведінку користувачів, а й самі правила.
По‑третє, час експозиції має значення. Навіть якщо сьогодні немає доказів зловмисного використання витеклих облікових даних, місяці публічного доступу означають, що хтось міг їх скопіювати й відкласти до кращих часів. Це аргумент на користь:
- постійного моніторингу публічних активів організації,
- регулярних перевірок GitHub‑організацій на предмет публічних репозиторіїв із секретами,
- швидкої реакції на будь‑які виявлені витоки, включно з масовою ротацією ключів і паролів.
По‑четверте, IAM не можна розглядати окремо від архітектури. Навіть якщо облікові дані потраплять назовні, правильно спроєктована архітектура — з мінімальними привілеями, сегментацією, додатковими перевірками — може зменшити масштаб шкоди. Це перегукується з думкою, що вразливості неминучі, і завдання архітектури — зробити експлуатацію максимально складною.
Висновок: від «людських» паролів до керованих секретів
Витік GitHub‑репозиторію підрядника CISA — це не просто черговий заголовок про «забуті ключі в публічному доступі». Це концентрований урок про те, що:
- людські паролі з передбачуваними патернами більше не відповідають реаліям атак;
- репозиторії коду стали критичною частиною ланцюга постачання й потребують такого ж рівня контролю, як продакшн‑середовища;
- хеші паролів у середовищах на кшталт Active Directory слід вважати повноцінними секретами, що потребують ротації після будь‑якого витоку;
- менеджери паролів, passkeys та централізовані сховища секретів — не «опція для зручності», а базова вимога до сучасної IAM‑стратегії.
Поки організації інвестують у нові інструменти виявлення вразливостей, включно з AI‑моделями, старі проблеми — слабкі паролі, секрети в коді, публічні репозиторії — продовжують відкривати двері для атак. Закривати ці двері — завдання не штучного інтелекту, а дисциплінованої, послідовної роботи з керування ідентичностями та доступами.
Джерело
First findings from Project Glasswing — IBM Technology (YouTube)