У позачерговому випуску подкасту MVC #25 на каналі «УТ‑2» ведучі обговорюють один із найгучніших інцидентів у світі веб‑інфраструктури останнього часу — злам платформи Vercel. Це той самий «модний сервіс для деплою», тісно пов’язаний із Next.js, на якому сьогодні живе величезна кількість сучасних фронтенд‑ і AI‑проєктів. Історія виявилася показовою не лише масштабом компрометації, а й тим, як саме зловмисники зайшли в інфраструктуру — через сторонній сервіс Context AI (Delve/Context), який формально мав SOC 2‑аудит від Deloitte.
Що сталося з Vercel: доступ «до всього, що було»
Vercel — це платформа, яка знімає з розробників біль класичного деплою: замість ручної конфігурації серверів достатньо підключити репозиторій, налаштувати кілька параметрів — і застосунок опиняється в продакшені. Саме тому сервіс став де-факто стандартом для Next.js‑проєктів і популярним вибором для AI‑демок та стартапів.
На цьому тлі новина про злам Vercel виглядає особливо тривожною. За обговоренням у випуску, хакери змогли отримати доступ до внутрішньої інфраструктури компанії. Публічні комунікації Vercel, як зазначається, залишаються обережними й не деталізують повний обсяг компрометації, однак уже зараз є те, що не можна ігнорувати: у даркнеті з’явилися дампи з профілями користувачів платформи.
Той факт, що в обігу опинилися саме профілі, означає, що зловмисники мали щонайменше доступ до бази користувачів. Це може включати імена, email‑адреси, метадані акаунтів, потенційно — прив’язані платіжні провайдери. Повний склад полів у дампах публічно не розкривається, але вже сама наявність таких даних у даркнеті створює ризики подальших таргетованих атак на розробників та компанії, які користуються Vercel.
Ситуацію переводить у ще небезпечнішу площину те, що, за словами ведучих, хакери вимагають у Vercel викуп за викрадені дані. Це класичний сценарій ransomware‑шантажу: зловмисники не лише крадуть інформацію, а й намагаються монетизувати її через тиск на компанію, погрожуючи подальшими зливами або публікацією чутливих фрагментів.
На відміну від типових «шифрувальних» атак, де основна шкода — блокування систем, тут головний актив — дані. І якщо профілі користувачів уже частково опинилися в даркнеті, то логічно припустити, що в руках зловмисників може бути значно більше: внутрішні конфігурації, журнали доступу, службові документи, інтеграційні токени.
Ланцюгова атака: як Context AI відкрив двері до інфраструктури
Найцікавіша й найтривожніша частина історії — це початкова точка входу. Злам Vercel не починався з прямого штурму їхніх серверів чи вразливості в самому хмарному середовищі. Першою ланкою в ланцюгу став сторонній сервіс Context AI (також згадується як Delve/Context).
Цей сервіс мав доступ до Google‑акаунта одного зі співробітників Vercel. Доступ до корпоративного Google‑облікового запису — це, по суті, ключ до величезної кількості внутрішніх артефактів: документів, таблиць, презентацій, внутрішніх інструкцій, можливо — конфігураційних файлів, описів інфраструктури, списків сервісних акаунтів, посилань на внутрішні панелі керування.
Через те, що Context AI мав доступ до документів у цьому акаунті, зловмисники змогли використати його як трамплін. Компрометація Context AI дала їм змогу прочитати те, що бачив співробітник Vercel, і далі розширювати привілеї. У результаті це призвело до подальшого доступу до внутрішньої інфраструктури Vercel.
Це класичний приклад ланцюгової атаки на сучасну SaaS‑екосистему. Компанія може ретельно захищати свої власні системи, але вразливість або компрометація одного з численних інтегрованих сервісів відкриває обхідний шлях. У цьому випадку саме Context AI став слабкою ланкою, через яку вдалося обійти зовнішній периметр безпеки Vercel.
Особливо показово, що ключовим ресурсом, який використали зловмисники, стали документи в Google‑акаунті. Внутрішні документи часто містять не лише бізнес‑інформацію, а й технічні деталі: схеми мережі, описи ролей і доступів, фрагменти конфігів, інструкції з онбордингу, де можуть фігурувати URL‑адреси внутрішніх панелей, назви сервісних акаунтів, навіть приклади токенів або ключів. Усе це — золота жила для атакувальника, який уміє будувати подальший ланцюг експлуатації.
Що мають зробити користувачі Vercel прямо зараз
На тлі обмеженої офіційної інформації від Vercel, практичні рекомендації для користувачів стають критично важливими. Ведучі MVC #25 формулюють їх максимально прямо й без дипломатії: усім, хто користується Vercel, варто негайно відкликати доступи до GitHub та інших інтеграцій, а також змінити всі секрети, які будь‑коли зберігалися у Vercel.
Йдеться не лише про активні токени. Якщо в середовищі Vercel колись зберігалися секрети — API‑ключі, токени до сторонніх сервісів, доступи до баз даних, приватні ключі, — їх варто вважати потенційно скомпрометованими. Навіть якщо ви вже не використовуєте конкретний проєкт або інтеграцію, історичні дані могли бути доступні зловмисникам у момент, коли вони мали контроль над інфраструктурою.
Окремий акцент — на GitHub‑інтеграції. Типовий сценарій роботи з Vercel передбачає, що сервіс отримує доступ до репозиторіїв, аби автоматично деплоїти застосунок при кожному пуші. Якщо токен доступу до GitHub опинився в руках зловмисників, це відкриває їм шлях до вихідного коду, приватних репозиторіїв, CI‑конфігурацій, а іноді й до секретів, які зберігаються в репо всупереч кращим практикам.
Тому мінімальний набір дій для команд, що працюють із Vercel, виглядає так: перевипустити всі інтеграційні токени, які були видані Vercel; змінити всі секрети, що зберігалися в середовищах Vercel; провести внутрішній аудит конфігурацій, аби виявити можливі вторинні наслідки.
Це не просто «параноїдальна обережність». В умовах, коли дампи профілів уже продаються в даркнеті, а зловмисники вимагають викуп, безпечніше виходити з найгіршого сценарію: усе, до чого теоретично можна було дістатися з внутрішньої інфраструктури Vercel, слід вважати під загрозою.
SOC 2 під питанням: коли аудит не рятує від реальної атаки
Окремий вимір цієї історії — це репутація та реальна цінність сертифікацій на кшталт SOC 2. Delve/Context AI, через які почався злам, мали SOC 2‑аудит від Deloitte. Формально це означає, що сервіс відповідає певним стандартам безпеки, процесів і контролів, які мають знизити ризики інцидентів.
Факт, що саме через цей сервіс зламали Vercel, неминуче ставить під сумнів ефективність таких аудитів у практичному вимірі. SOC 2 часто сприймається як «знак якості» для B2B‑SaaS‑продуктів: наявність сертифікації спрощує продажі, відкриває двері до корпоративних клієнтів, знімає частину запитань від відділів безпеки.
Однак у реальності SOC 2 — це, передусім, про відповідність процесів певним вимогам на момент аудиту. Це не гарантія відсутності вразливостей, не страховка від людських помилок і не щит від складних ланцюгових атак. Історія з Context AI демонструє, що навіть сервіс із формальною відповідністю SOC 2 може стати точкою входу для масштабного зламу іншої компанії.
У розмові згадується ще один важливий аспект: на ринку існують SaaS‑рішення, які за підписку й кілька тисяч доларів допомагають компаніям «стати SOC 2 compliant». Це створює враження, що сертифікація перетворюється на формальність, яку можна «купити» як сервіс: заповнити шаблони політик, налаштувати мінімальні контролі, пройти чек‑лист аудитора.
У такій моделі безпека ризикує стати побічним продуктом паперової відповідності. Компанія може мати всі потрібні документи, формально виконувати вимоги, але при цьому залишатися вразливою до реальних атак, які використовують слабкі місця інтеграцій, людський фактор або неочевидні комбінації доступів.
Інцидент із Vercel і Context AI — це наочний кейс, який демонструє розрив між «комплаєнсом» і фактичною стійкістю до атак. Для індустрії це сигнал, що SOC 2 не може бути єдиним або головним критерієм довіри до сервісу. Потрібен глибший аналіз архітектури безпеки, моделі доступів, управління інтеграціями та сценаріїв найгірших випадків.
Ланцюг SaaS‑довіри: коли кожен інтегрований сервіс — потенційна дірка
Сучасні компанії будують свою роботу на довгому ланцюгу SaaS‑інструментів. Vercel сам по собі є таким сервісом, який працює поверх AWS, перепродуючи інфраструктуру Amazon із націнкою й додаючи власний рівень зручності, автоматизації та інтеграцій. До нього підключаються GitHub, CI‑системи, аналітика, APM‑інструменти, секрет‑менеджери, AI‑сервіси на кшталт Context AI.
Кожна така інтеграція — це новий вектор атаки. У випадку з Vercel саме сторонній сервіс, який мав доступ до Google‑акаунта співробітника, став точкою входу. Але в іншій компанії це може бути будь‑що: календарний сервіс, HR‑платформа, інструмент для управління знаннями, внутрішній чат‑бот.
Проблема в тому, що модель довіри в таких ланцюгах часто будується за принципом «усі сервіси, які ми використовуємо, безпечні за замовчуванням». Наявність SOC 2 або великого імені аудитора сприймається як достатня підстава, аби видати сервісу широкі права доступу до корпоративних даних. У результаті одна компрометація може каскадно вдарити по кількох рівнях інфраструктури.
Інцидент із Vercel оголює ще одну слабкість: внутрішні документи в Google‑акаунтах співробітників часто стають неформальним «центром правди» про інфраструктуру. Там описують, як усе влаштовано, які сервіси з чим інтегровані, де які ключі зберігаються, як налаштовуються доступи. Для атакувальника це готова карта місцевості.
У такій реальності компаніям доведеться переосмислити, як вони працюють із SaaS‑ланцюгами. Формальний комплаєнс на кшталт SOC 2 може залишатися важливим елементом, але вже точно не єдиним. Потрібні обмеження прав доступу для інтеграцій, сегментація даних, мінімізація чутливої інформації в документах загального доступу, регулярні рев’ю того, які сервіси до чого мають доступ.
Висновок: Vercel як симптом глибшої проблеми безпеки SaaS‑екосистеми
Злам Vercel — це не просто черговий інцидент із великою хмарною платформою. Це концентрований приклад того, як сучасна інфраструктура, побудована на десятках взаємопов’язаних SaaS‑сервісів, може впасти через одну скомпрометовану ланку. У цьому випадку нею став Context AI, який, попри SOC 2‑аудит від Deloitte, став воротами до внутрішньої інфраструктури Vercel.
Для користувачів платформи наслідки вже очевидні: дампи профілів у даркнеті, вимоги викупу від хакерів, необхідність терміново відкликати токени GitHub та інших інтеграцій, змінювати всі секрети, які будь‑коли зберігалися у Vercel. Для індустрії в цілому це ще й привід переглянути ставлення до сертифікацій на кшталт SOC 2, які дедалі частіше виглядають як формалізований бар’єр для продажів, а не як реальний індикатор стійкості до атак.
Головний урок цієї історії — у тому, що безпека в епоху SaaS‑ланцюгів не може зводитися до галочок у чек‑листах і логотипів аудиторів на лендингах. Вона вимагає постійної недовіри до інтеграцій, мінімізації прав доступу, обережного ставлення до того, що опиняється в корпоративних документах, і готовності діяти за найгіршим сценарієм, коли одна з ланок неминуче дасть збій.