Vercel зламали. Скільки твого бізнесу тримається на платформі для деплойменту?
Сьогодні Vercel підтвердив, що хтось пробрався до їхніх внутрішніх систем. На форумі з'явилася пропозиція — хтось, хто називає себе ShinyHunters, виставив на продаж за 2 мільйони доларів те, що описує як вихідний код, ключі доступу, акаунти працівників, API-токени, NPM-токени та GitHub-токени.
Офіційний комунікат Vercel короткий: виявили інцидент, залучили фахівців з incident response, повідомили правоохоронців. Єдина конкретна рекомендація? Перегляньте змінні середовища та використовуйте функцію шифрованих змінних.
Ця рекомендація говорить набагато більше, ніж здається.
Про що ніхто не думає, поки не пізно
Коли деплоїш додаток через платформу на кшталт Vercel, Netlify, Railway чи будь-який PaaS — віддаєш у чужі руки не лише свій код. Віддаєш секрети.
Що лежить у змінних середовища типового продакшн-деплойменту? Connection string до бази з логіном та паролем. API-ключі платіжного шлюзу — Stripe, LiqPay, Fondy. Токени зовнішніх сервісів — Twilio, SendGrid, Auth0. Внутрішні API-ключі для зв'язку між сервісами. OAuth client secrets. Ключі шифрування.
Це не теоретичні приклади. Це те, що прямо зараз лежить у вкладці «Environment Variables» більшості продакшн-деплойментів.
Коли платформу, через яку деплоїш, зламали — зловмиснику не треба ламати тебе. В нього вже є твої ключі. Ключ до Stripe — це доступ до твоєї платіжної інфраструктури. Connection string до бази — це дані твоїх клієнтів. GitHub-токен — це доступ до репозиторіїв і потенційна можливість пушити зміни в код.
Злом Vercel — це не проблема одного Vercel. Це наочна демонстрація того, як виглядає ризик залежності від платформи, коли він реалізується.
Це стосується не лише Vercel
Не тикаємо пальцем у Vercel — вони розкрили інцидент, і це правильний підхід. Проблема структурна, і стосується кожного PaaS та кожного CI/CD пайплайну.
Деплоїш через GitHub Actions і тримаєш там секрети? Те саме ризик. Netlify зі змінними середовища? Те саме. Пайплайн у GitLab з credentials до продакшну? Те саме. AWS-креди в деплоймент-сервісі? Вгадай.
Питання не «чи Vercel безпечний?». Питання: що станеться з твоїм бізнесом, якщо будь-яку платформу, від якої залежиш, скомпрометують?
Що робити прямо зараз
Якщо ти на Vercel — негайні дії:
Зротуй все. Кожен API-ключ, кожен credential до бази, кожен токен у змінних середовища Vercel — вважай скомпрометованим і міняй зараз. Не чекай, поки Vercel скаже, чи ти в тій «обмеженій підмножині клієнтів». Ротація ключа — це хвилини. Відсутність ротації може коштувати всього.
Перевір логи доступу. Зайди в бази даних, у панель платіжного провайдера, у дашборди зовнішніх сервісів. Щось незвичне? API-виклики, які не впізнаєш? Зроби це сьогодні.
Переглянь токени інтеграцій. Токени Vercel, підключення до GitHub, NPM publish-токени — відклич і згенеруй заново.
Що зробити цього місяця — незалежно від платформи
Ширший висновок стосується всіх — хоч ти на Vercel, хоч на Netlify, хоч на AWS.
Проведи інвентаризацію секретів. Склади список кожного credentialа в платформі для деплойменту. Швидше за все, здивуєшся — і кількості, і тому, скільки з них мають більше прав, ніж потрібно. Connection string з правами адміна у preview-середовищі? Такого бути не повинно.
Розділи preview і продакшн. Більшість платформ дозволяють задавати різні змінні для різних середовищ. Preview-деплойменти не повинні мати доступу до продакшн-баз, продакшн-платіжних шлюзів, продакшн-ключів. Якщо злом розкриє секрети з preview — радіус ураження має обмежуватися тестовими системами, а не продакшном.
Використай спеціалізований менеджер секретів. AWS Secrets Manager, HashiCorp Vault, Doppler — інструменти, створені саме для зберігання секретів, з логуванням доступу, політиками ротації та гранулярними правами. Змінні середовища платформи для деплойменту не проєктувалися для такого рівня безпеки. Вони зручні, але не безпечні.
Мінімум прав для кожного токена. GitHub-токен, підключений до платформи — чи йому справді потрібен доступ на запис у всі репозиторії? Навряд. Credential до бази — чи потрібні права адміна? Точно ні. Обмеж кожен credential до мінімуму.
Подумай про радіус ураження. Якщо завтра платформу X зламають — що отримує зловмисник? Доступ до продакшн-даних? Платіжну інформацію клієнтів? Вихідний код? Намалюй цю діаграму. Якщо відповідь «все» — у тебе ризик концентрації, від якого варто не спати ночами.
Підготуй план ротації credentials. Не «розберемося, коли прийде час». Конкретний список: ось наші секрети, ось де вони зберігаються, ось як ротуємо кожен, ось хто відповідає. Коли злом стається — а він рано чи пізно стається — хочеш виконувати план, а не імпровізувати.
Патерн: платформи — це цілі
Два місяці тому знищили дата-центри AWS на Близькому Сході. Сьогодні зламали внутрішні системи Vercel. Різні вектори — руйнування інфраструктури проти кібератаки — але однаковий урок: платформи, на яких будуєш, не є неуразливими, і твоя відповідальність за безпеку не закінчується на межі власного коду.
Кожен шар стеку, який ти не контролюєш — це шар, який може впасти або бути скомпрометований. Хмарний провайдер, платформа для деплойменту, CI/CD пайплайн, реєстр пакетів, DNS-провайдер. Кожен із них — залежність. Кожен — потенційна точка відмови.
Компанії, що проходять через такі інциденти без втрат — це ті, хто заздалегідь продумав залежності від платформ. Розділив секрети. Обмежив права. Підготував плани ротації. Спроєктував архітектуру на випадок, коли довірена платформа перестає бути довіреною.
Якщо ти ще цього не зробив — сьогодні вдалий день, щоб почати.
В Otocolobus ми допомагаємо компаніям проєктувати інфраструктуру, що обмежує радіус ураження — чи то зламана платформа, скомпрометований credential, чи знищений дата-центр. Хочеш зрозуміти, як виглядає твоя експозиція, і що з нею робити — напиши.