У 2025 році поріг входу в складні кібератаки обвалився: підлітки без технічних навичок за допомогою систем на основі великих мовних моделей здійснили злами на мільйони записів і багатомільйонні вимагання, а середній час від публікації вразливості до появи бойового експлойта скоротився з більш ніж 700 днів у 2020 році до 44 днів у 2025‑му; на цьому тлі традиційна стратегія «встигнути запатчити раніше за зловмисників» перестала працювати, і організаціям, які використовують відкритий код і публічні репозиторії пакетів, необхідно переходити до структурного усунення цілих класів вразливостей і жорсткого контролю ланцюга постачання ПЗ.
Технічні деталі та ключові метрики 2025–2026 років
Приклади атак із використанням ШІ
Нетехнічні зловмисники у 2025 році почали проводити операції, які раніше вимагали злагодженої роботи досвідченої команди:
- У грудні 2025 року сімнадцятирічний підліток в Осаці був заарештований за японським законом про несанкціонований доступ за запуск шкідливого коду, що дозволив ексфільтрувати персональні дані понад 7 млн користувачів мережі інтернет‑кафе Kaikatsu Club; мотив — купівля карток Pokémon.
- У лютому 2025 року троє підлітків (14, 15 і 16 років) без досвіду програмування за допомогою ChatGPT створили інструмент, який близько 220 000 разів атакував системи Rakuten Mobile; отримані кошти були витрачені на ігрові приставки та онлайн‑азартні ігри.
- У липні 2025 року один зловмисник, використовуючи платформу агентного програмування Claude Code, провів кампанію вимагання проти 17 організацій за місяць: ШІ розробляв шкідливий код, систематизував украдені файли, аналізував фінансову звітність для калібрування вимог і формував тексти листів‑шантажів.
- У грудні 2025 року інший одиночний актор за допомогою Claude Code і ChatGPT зламав понад 10 відомств уряду Мексики та викрав понад 195 млн записів платників податків.
Усі ці кейси демонструють: роль ШІ вже не допоміжна, а наскрізна — від розробки експлойтів до автоматизації фінансового аналізу й комунікацій.
Еволюція атак на відкритий код і репозиторії пакетів
Одним із найпоказовіших індикаторів стало зростання шкідливих пакетів у публічних репозиторіях:
- у 2022 році фіксувалося близько 55 000 шкідливих пакетів;
- до 2025 року кількість зросла до 454 600, із помітними стрибками в 2023 році (вихід GPT‑4) і 2025‑му (масове поширення агентних ШІ‑інструментів програмування).
У вересні 2025 року атака Shai-Hulud на екосистему npm скомпрометувала понад 500 пакетів. Було допущено витік секретів 487 організацій, а з криптогаманця Trust Wallet викрали 8,5 млн доларів після того, як зловмисники, скориставшись скомпрометованими обліковими даними, підмінили його розширення для Chrome.
Показово, що шкідливі пакети маскувалися під популярні бібліотеки (наприклад, chalk, debug), містили документацію, модульні тести й код, схожий на телеметричні модулі. Класичні статичні аналізатори та сигнатурні сканери пропускали їх, оскільки структура виглядала як «нормальне» ПЗ. Це збігається із загальною тенденцією, коли поведінкові шаблони атак описуються на рівні тактик і технік, наприклад, у матриці MITRE ATT&CK, а не через статичні сигнатури.
Скорочення часу до експлуатації вразливостей
Інший ключовий показник — time to exploit, час від розкриття вразливості до появи експлойта «в полі»:
- у 2020 році він перевищував 700 днів;
- у 2025 році скоротився до 44 днів.
Звіт M-Trends 2026 компанії Mandiant показує ще більш тривожну картину: вікно фактично стало від’ємним, оскільки експлойти дедалі частіше з’являються раніше за патчі, а 28,3% записів CVE експлуатуються протягом 24 годин із моменту розкриття. На цьому тлі каталоги вразливостей, такі як NVD, перетворюються для злочинців на список завдань, які можна швидко автоматизувати за допомогою ШІ.
Дисбаланс між швидкістю атаки та швидкістю захисту
Дані Edgescan за 2025 рік демонструють, що середній час виправлення відомих вразливостей високої та критичної важливості становить 74 дні, а 45% вразливостей в інфраструктурі великих компаній (від 1000 співробітників) так і не усуваються. На цьому тлі середній час розробки експлойта (44 дні) і частка атак у першу добу після розкриття створюють стійку перевагу на боці атакувальних.
Зростання можливостей ШІ для розробки коду
У міру того як фронтирні моделі (ChatGPT, Claude, Gemini) поліпшували результати на бенчмарках розробки ПЗ (наприклад, SWE-bench), їхній внесок в наступальні операції став помітно вищим:
- у серпні 2024 року топові моделі автоматично розв’язували близько 33% реальних завдань із GitHub на SWE-bench;
- до грудня 2025 року показник досяг майже 81%.
Це означає, що більша частина рутинної та середньої за складністю розробки експлойтів і утиліт тепер доступна зловмисникам як сервіс, а не як компетенція.
Спроба структурної відповіді: Chainguard Libraries
На тлі вибухового зростання атак на ланцюг постачання з’являється підхід, націлений не на прискорення реагування, а на усунення цілих класів ризиків. Приклад — Chainguard Libraries, де кожна відкрита бібліотека пересобирається з перевіреного, атрибутованого вихідного коду. Архітектурна мета — зробити неможливими:
- захоплення процесів CI/CD через підміну залежностей;
- атаки типу dependency confusion;
- крадіжку й зловживання довгоживучими токенами під час збірки;
- атаки на інфраструктуру розповсюдження пакетів.
Під час тестування на 8 783 шкідливих пакетах для npm Chainguard Libraries заблокували 99,7% із них; для приблизно 3 000 шкідливих Python‑пакетів — близько 98%. Це ілюструє, наскільки ефективнішими виявляються заходи, вбудовані в саму архітектуру ланцюга постачання, порівняно з додаванням нових шарів детектування.
Контекст загроз: хто і як страждає найбільше
З наведених прикладів видно, що атаки зачіпають:
- державний сектор — від японської правоохоронної системи до урядових відомств Мексики, де витік 195 млн податкових записів створює довгострокові ризики шахрайства та політичних маніпуляцій;
- операторів зв’язку та критичну інфраструктуру — інцидент із Rakuten Mobile показує, що навіть підлітки можуть ініціювати масштабні навантаження або шахрайські операції проти телеком‑платформ;
- фінансові сервіси й криптоплатформи, як у випадку з Trust Wallet і викраденням 8,5 млн доларів через отруєння розширення браузера;
- будь-який бізнес, що залежить від npm, PyPI та інших репозиторіїв відкритого коду, де сотні тисяч шкідливих пакетів підвищують базовий рівень ризику навіть для тривіальних залежностей.
Спільний знаменник — масова залежність від зовнішнього коду й сервісів, поверх якої традиційна модель «оновити антивірус і регулярно встановлювати патчі» більше не дає прийнятного залишкового ризику. Це підтверджується й аналітикою таких організацій, як CISA, які послідовно зміщують фокус до архітектурних принципів «secure by design».
Оцінка впливу на бізнес і операції
- Операційні ризики: вимушені заморозки коду після атак на репозиторії (як після Shai-Hulud) призводять до затримок релізів, зриву дорожніх карт і зростання технічного боргу.
- Фінансові втрати: прямі викрадення (мільйони доларів у кейсі Trust Wallet), викуп, простої сервісів і подальші інвестиції в форсоване поліпшення безпеки.
- Ризики конфіденційності та регуляторні санкції: витік 7 млн записів клієнтів Kaikatsu Club і 195 млн записів платників податків у Мексиці порушують питання не лише штрафів, а й неможливості «відкликати» вже втрачені дані.
- Репутація й довіра: поінформованість користувачів про те, що кіберзлочини тепер може скоїти «кожен із ШІ‑асистентом», підвищує чутливість до новин про інциденти та знижує толерантність до збоїв.
Якісно нова проблема — розширення перетину між тими, хто готовий здійснювати атаки, і тими, хто здатний їх проводити. Раніше це був вузький прошарок; тепер, завдяки ШІ, він швидко зростає, а масштаб атак усе менше залежить від розміру й зрілості злочинного угруповання.
Практичні рекомендації щодо зниження ризику
1. Взяти за базу: експлойт з’явиться раніше, ніж ви встигнете пропатчити
- Планувати процеси управління вразливостями, виходячи зі сценарію, що експлуатація можлива в перші 24 години після розкриття (або раніше), навіть якщо патч ще не вийшов.
- Виділити окремий потік для обробки критичних вразливостей із більш агресивними SLO (години–кілька днів), включно з тимчасовими компенсувальними заходами (відключення функцій, обмеження експонованих сервісів, фільтрація трафіку).
2. Жорстко контролювати ланцюг постачання ПЗ
- Створити внутрішній репозиторій залежностей (дзеркало npm, PyPI тощо) із затвердженням і публікацією лише перевірених версій бібліотек.
- Увімкнути обов’язкове проходження пакетів через процес перевірки (статичний аналіз, ручний огляд, співставлення з відомими легітимними джерелами) перед потраплянням у продуктивний репозиторій.
- Розглянути рішення, які пересобирають відкриті бібліотеки з атрибутованого вихідного коду та надають гарантії незмінності збірок за аналогією з Chainguard Libraries, щоб цілі класи атак (dependency confusion, компрометація CI/CD, підміна бінарів) ставали технічно неможливими.
3. Посилити виявлення атак на рівні поведінки, а не лише коду
- Не покладатися на сигнатурні сканери для виявлення шкідливих пакетів: ШІ‑згенерований код легко маскується під «нормальний» із документацією та тестами.
- Упровадити моніторинг поведінки залежностей: мережеві запити під час встановлення, спроби доступу до конфіденційних файлів, запуск зовнішніх процесів із install‑скриптів.
- Використовувати ізольовані середовища (sandbox) для тестування нових пакетів перед їх використанням у CI/CD і в продакшені.
4. Управління доступом до ШІ‑інструментів розробки
- Формалізувати політику використання систем на кшталт ChatGPT і Claude Code: заборона на завантаження чутливих фрагментів коду й секретів, вимоги до логування сесій.
- Проводити навчання розробників і аналітиків ризикам не лише витоку, а й зловживання ШІ — від несвідомої генерації вразливого коду до допомоги в обході внутрішніх контролів.
5. Підготовка до інцидентів у ланцюгу постачання
- Заздалегідь визначити процедуру швидкого «заморожування» залежностей і відкоту до попередніх версій у разі виявлення компрометації пакета.
- Вести перелік використовуваних бібліотек і їхнього походження (по суті, внутрішню інвентаризацію, аналогічну програмній «відомості матеріалів»), щоб під час нової атаки на npm або інший реєстр швидко визначити, хто постраждав.
Ключовий висновок: в умовах, коли експлуатація вразливостей пришвидшується швидше, ніж скорочуються цикли випуску патчів, ставка лише на швидкість реагування приречена; першим пріоритетом має стати створення контрольованого внутрішнього репозиторію залежностей і перенесення на нього всіх процесів збірки та розгортання, щоб максимально відсікти класи атак на ланцюг постачання ще до того, як вони потраплять у ваш контур.
