Vercel zhackowany. Ile Twojego biznesu siedzi w platformie do deploymentu?
Dzisiaj Vercel potwierdził, że ktoś dostał się do ich wewnętrznych systemów. Na forum pojawiła się oferta sprzedaży — ktoś podający się za grupę ShinyHunters wystawił za 2 miliony dolarów to, co opisuje jako kod źródłowy, klucze dostępowe, konta pracowników, tokeny API, tokeny NPM i tokeny GitHub.
Oficjalny komunikat Vercel jest oszczędny: zidentyfikowano incydent, zatrudniono specjalistów od incident response, powiadomiono organy ścigania. Jedyna konkretna rekomendacja? Przejrzyj swoje zmienne środowiskowe i skorzystaj z funkcji szyfrowanych zmiennych.
Ta rekomendacja mówi więcej, niż się wydaje na pierwszy rzut oka.
Nad czym nikt się nie zastanawia, dopóki nie jest za późno
Kiedy wdrażasz aplikację przez platformę typu Vercel, Netlify, Railway czy jakikolwiek PaaS — oddajesz w cudze ręce nie tylko swój kod. Oddajesz sekrety.
Co siedzi w zmiennych środowiskowych typowego wdrożenia produkcyjnego? Connection string do bazy z danymi logowania. Klucze API bramki płatniczej — Stripe, Adyen, Przelewy24. Tokeny serwisów zewnętrznych — Twilio, SendGrid, Auth0. Wewnętrzne klucze API do komunikacji między serwisami. Client secrets OAuth. Klucze szyfrowania.
To nie są teoretyczne przykłady. To jest to, co teraz siedzi w zakładce „Environment Variables" większości produkcyjnych deploymentów.
Kiedy platforma, na której wdrażasz, zostaje zhackowana — atakujący nie musi się włamywać do Ciebie. Już ma Twoje klucze. Klucz do Stripe daje dostęp do Twojej infrastruktury płatniczej. Connection string do bazy daje dostęp do danych Twoich klientów. Token GitHub daje dostęp do repozytoriów i potencjalnie możliwość pushowania zmian w kodzie.
Włamanie do Vercel to nie jest problem samego Vercel. To demonstracja tego, jak wygląda ryzyko zależności od platformy, kiedy się materializuje.
To nie jest unikalne dla Vercel
Nie wskazujemy palcem na Vercel — ujawnili incydent, i to jest właściwe podejście. Problem jest strukturalny i dotyczy każdej platformy PaaS i każdego pipeline'u CI/CD.
Wdrażasz przez GitHub Actions i trzymasz tam sekrety? To samo ryzyko. Netlify ze zmiennymi środowiskowymi? To samo. Pipeline w GitLab z credentials do produkcji? To samo. Dane dostępowe do AWS w serwisie deploymentowym? Zgadnij.
Pytanie nie brzmi „czy Vercel jest bezpieczny?". Pytanie brzmi: co się stanie z Twoim biznesem, jeśli dowolna platforma, od której zależysz, zostanie skompromitowana?
Co zrobić teraz
Jeśli korzystasz z Vercel — działania natychmiastowe:
Zrotuj wszystko. Każdy klucz API, każdy credential do bazy, każdy token przechowywany w zmiennych środowiskowych Vercel — zakładaj, że jest skompromitowany, i zmieniaj go teraz. Nie czekaj, aż Vercel powie Ci, czy jesteś w tej „ograniczonej grupie klientów". Zmiana klucza kosztuje Cię minuty. Brak zmiany może kosztować wszystko.
Sprawdź logi dostępu. Zajrzyj do baz danych, do panelu bramki płatniczej, do dashboardów usług zewnętrznych. Jakieś nietypowe wzorce dostępu? Wywołania API, których nie rozpoznajesz? Zrób to dzisiaj.
Przejrzyj tokeny integracji. Tokeny Vercel, połączenia z GitHub, tokeny publikacji NPM — unieważnij i wygeneruj nowe.
Co zrobić w tym miesiącu — niezależnie od platformy
Szerszy wniosek dotyczy każdego — czy jesteś na Vercel, Netlify, AWS, czy czymkolwiek innym.
Zinwentaryzuj, jakie sekrety gdzie siedzą. Zrób listę każdego credentiala przechowywanego w platformie deploymentowej. Prawdopodobnie zdziwisz się, ile ich jest i ile z nich ma więcej uprawnień, niż potrzebuje. Connection string z uprawnieniami admina w środowisku preview? Tego nie powinno być.
Oddziel preview od produkcji. Większość platform pozwala ustawić różne zmienne dla różnych środowisk. Deploymenty preview nie powinny mieć dostępu do produkcyjnych baz danych, produkcyjnych bramek płatniczych, produkcyjnych kluczy API. Jeśli breach ujawni sekrety ze środowiska preview — promień rażenia powinien być ograniczony do systemów testowych, nie do produkcji.
Użyj dedykowanego menedżera sekretów. AWS Secrets Manager, HashiCorp Vault, Doppler — narzędzia zaprojektowane do przechowywania sekretów, z logowaniem dostępu, politykami rotacji i granularnymi uprawnieniami. Zmienne środowiskowe platformy deploymentowej nie zostały do tego zaprojektowane. Są wygodne, ale nie bezpieczne.
Zasada minimalnych uprawnień dla tokenów. Token GitHub podłączony do platformy — czy naprawdę potrzebuje uprawnień zapisu do wszystkich repozytoriów? Raczej nie. Credential do bazy — czy potrzebuje uprawnień admina? Na pewno nie. Ogranicz każdy credential do minimum.
Pomyśl o promieniu rażenia. Jeśli jutro platforma X zostanie zhackowana — co dostaje atakujący? Dostęp do danych produkcyjnych? Informacje płatnicze klientów? Kod źródłowy? Narysuj sobie ten diagram. Jeśli odpowiedź brzmi „wszystko" — masz ryzyko koncentracji, które powinno spędzać Ci sen z powiek.
Przygotuj plan rotacji credentials. Nie „jakoś to ogarniemy jak przyjdzie co do czego". Konkretna lista: to są nasze sekrety, tu są przechowywane, tak rotujemy każdy z nich, ta osoba jest odpowiedzialna. Kiedy breach nadejdzie — a kiedyś nadejdzie — chcesz wykonywać plan, nie improwizować.
Wzorzec: platformy są celami
Dwa miesiące temu zniszczono centra danych AWS na Bliskim Wschodzie. Dziś włamano się do wewnętrznych systemów Vercel. Inne wektory ataku — zniszczenie infrastruktury kontra cyberatak — ale ta sama lekcja: platformy, na których budujesz, nie są niezwyciężone, a Twoja odpowiedzialność za bezpieczeństwo nie kończy się na granicy Twojego kodu.
Każda warstwa stosu, której nie kontrolujesz, to warstwa, która może zostać skompromitowana. Dostawca chmury, platforma deploymentowa, pipeline CI/CD, rejestr pakietów, dostawca DNS. Każda z nich to zależność. Każda to potencjalny single point of failure.
Firmy, które przechodzą przez takie incydenty bez strat — to te, które wcześniej przemyślały zależność od platformy. Rozdzieliły sekrety. Ograniczyły uprawnienia. Miały gotowe plany rotacji. Zaprojektowały się na scenariusz, w którym zaufana platforma przestaje być zaufana.
Jeśli jeszcze tego nie zrobiłeś — dzisiaj jest dobry dzień, żeby zacząć.
W Otocolobus pomagamy firmom projektować infrastrukturę, która ogranicza promień rażenia — czy to zhackowana platforma, skompromitowany credential, czy zniszczony data center. Chcesz wiedzieć, jak wygląda Twoja ekspozycja i co z nią zrobić — odezwij się.