Atak na Vercel a KSC 2.0 — łańcuch dostaw w 2026

18 kwietnia 2026 Vercel potwierdził incydent bezpieczeństwa. Wektor ataku nie prowadził przez lukę w infrastrukturze hostingowej. Prowadził przez zewnętrzne narzędzie AI, z którego korzystał jeden pracownik. To typowy wzorzec 2026 roku — i dokładnie to, przed czym KSC 2.0 każe się zabezpieczyć.

Co się stało w Vercelu — fakty

Według komunikatu w Vercel Knowledge Base i potwierdzeń dla BleepingComputer sekwencja była następująca. Atakujący skompromitował aplikację OAuth dostawcy Context.ai — narzędzia AI zintegrowanego z Google Workspace pracownika Vercela. Context.ai miał autoryzowany dostęp do tego konta w granicach przyznanych scope'ów (zakresów uprawnień OAuth). Kompromitacja aplikacji oznaczała więc, że atakujący mógł wywoływać Google API jako pracownik — bez hasła i bez MFA, w obrębie tych scope'ów. Stąd, poprzez dalsze zasoby wewnętrzne, dotarł do części środowisk Vercela.

Wyciekły zmienne środowiskowe klientów nieoznaczone jako „Sensitive". Wszystkie zmienne Vercela są szyfrowane at rest, ale zwykłe są odczytywalne przez dashboard i API — więc w scenariuszu kompromitacji konta administracyjnego stają się dostępne atakującemu w plaintext. Zmienne oznaczone jako Sensitive mają dodatkową warstwę ochrony: są write-only w UI, niedostępne przez API po zapisaniu, nie wyciekają do build logów. Brak dowodów, że zostały odczytane. Vercel określa skalę jako „limited subset" klientów i kontaktuje się z nimi indywidualnie. Grupa znana jako ShinyHunters twierdzi na BreachForums, że dysponuje kodem źródłowym i kluczami, żądając 2 mln USD okupu — Vercel nie potwierdza ani nie zaprzecza szczegółom roszczenia.

Zgodnie z komunikatem Vercela ten sam kompromis OAuth Context.ai mógł potencjalnie dotknąć setek użytkowników w wielu organizacjach, które podłączyły to narzędzie do swoich Google Workspace. Vercel jest najbardziej widoczną ofiarą — między innymi dlatego, że szykuje się do IPO. W reakcji na incydent firma zaangażowała Mandiant do wsparcia response i współpracuje z organami ścigania.

Dlaczego to klasyczny supply chain attack 2026 roku

Wzorzec jest powtarzalny i dobrze znany. Atakujący nie atakuje bezpośrednio celu z dobrą ochroną perymetru. Atakuje zewnętrzne SaaS lub narzędzie AI, które zostało podłączone przez OAuth (protokół autoryzacji „zaloguj się przez Google / Microsoft" — aplikacja dostaje token z określonymi uprawnieniami do konta) do Google Workspace lub Microsoft 365 celu. Z tego zaczepienia atakujący uzyskuje ważny token dostępowy działający w ramach scope'ów aplikacji i może wywoływać API jako pracownik — bez hasła, bez MFA, w granicach przyznanych uprawnień.

Identyczny wzorzec widzieliśmy w kampanii Midnight Blizzard (APT29) przeciwko Microsoft, ujawnionej w styczniu 2024. Atak przebiegł w trzech krokach: (1) password spraying na nieużywany legacy test tenant (odrębne środowisko Azure AD / Entra ID) bez MFA; (2) w tym tenancie odnaleziono aplikację OAuth z podwyższonym dostępem do produkcyjnego środowiska korporacyjnego Microsoft; (3) aktor użył jej do utworzenia własnych malicious OAuth apps i przyznał sobie rolę full_access_as_app na Exchange Online, eksfiltrując maile kierownictwa i zespołu bezpieczeństwa. Wzorzec: third-party identity + nadużycie uprawnień aplikacji OAuth → core environment.

W obu przypadkach nie zawiodła technologia podstawowa (Azure AD, Google Workspace). Zawiodła higiena łańcucha tożsamości: zbyt szerokie uprawnienia OAuth, brak inwentaryzacji aplikacji third-party, brak monitoringu zachowań aplikacji zintegrowanych.

Łańcuch dostaw IT w 2026 — dlaczego eksplodował jako wektor

Kilka zweryfikowanych liczb opisujących skalę problemu. Według raportu BetterCloud 2025 State of SaaS średnia organizacja korzysta z 106 aplikacji SaaS (rok wcześniej 112 — to drugi rok spadku, po latach silnego wzrostu). Skala pozostaje jednak na tyle duża, że pełna kontrola nad zakresami OAuth wymaga dedykowanego procesu, nie ad-hoc przeglądu.

Verizon DBIR 2025 raportuje, że 30% naruszeń miało źródło w kompromitacji dostawcy — to dwukrotnie więcej niż rok wcześniej (15% w DBIR 2024). Supply chain pojawia się też w ENISA Threat Landscape 2025 jako jedna z głównych kategorii analizowanych zagrożeń, obok ransomware i DDoS.

Trzy czynniki, które składają się na ten wzrost:

• SaaS sprawl — firmy dodają aplikacje szybciej, niż je wycofują. W Workspace lub M365 wiszą dziesiątki OAuth grantów do narzędzi, z których nikt już nie korzysta.
• AI tools ad-hoc — zespoły eksperymentują z narzędziami AI, które niemal wszystkie żądają dostępu do maila, dokumentów albo kalendarza. Ocena bezpieczeństwa takiego dostawcy rzadko poprzedza integrację.
• Over-permissioned apps i consent fatigue — użytkownik klikający „Allow" nie czyta szczegółowo zakresu uprawnień. Aplikacje domyślnie żądają pełnego dostępu do Drive zamiast konkretnego folderu, pełnej skrzynki zamiast pojedynczego labela. W efekcie każda zintegrowana aplikacja trzyma szerszy zakres, niż faktycznie potrzebuje.

Case Vercel to nie anomalia. To objaw systemowej zmiany powierzchni ataku.

KSC 2.0 i NIS2 — dlaczego słusznie to wymusiły

Polska ustawa o krajowym systemie cyberbezpieczeństwa w znowelizowanej wersji (KSC 2.0) obowiązuje od 3 kwietnia 2026. Implementuje dyrektywę NIS2 (UE 2022/2555). Artykuł 21 ust. 2 dyrektywy — przeniesiony do polskiej ustawy jako obowiązkowy zestaw środków zarządzania ryzykiem — zawiera literę d: bezpieczeństwo łańcucha dostaw, w tym aspekty związane z relacjami między podmiotem a jego bezpośrednimi dostawcami lub usługodawcami.

Konkretnie wymagane są:

• Polityka bezpieczeństwa wobec dostawców — pisemna, zatwierdzona przez zarząd, z jasnymi kryteriami oceny.
• Ocena ryzyka w łańcuchu dostaw — udokumentowana, z klasyfikacją dostawców (kluczowi / ważni / pozostali) i proporcjonalnym poziomem kontroli.
• Klauzule bezpieczeństwa w umowach — obowiązek raportowania incydentów (SLA umowny 24h to praktyka rynkowa, nie wymóg ustawowy — służy temu, żebyś dotrzymał Twoich 24h wobec CSIRT NASK wynikających z art. 23 NIS2), prawo do audytu, standard bezpieczeństwa (ISO 27001 lub równoważny), procedury zakończenia współpracy.
• Monitorowanie dostawców w cyklu życia relacji — nie jednorazowy kwestionariusz na wejściu, lecz okresowa weryfikacja.

Łatwo patrzeć na te wymagania jak na biurokrację. Case Vercel pokazuje, że to nie biurokracja — to reakcja na wzorzec ataku, który już działa. Gdyby organizacje dotknięte kompromitacją Context.ai miały wdrożoną inwentaryzację aplikacji OAuth i politykę zatwierdzania integracji third-party AI, część z nich nie byłaby dziś na liście klientów, których Vercel i Context.ai muszą informować.

Warto rozgraniczyć: sama dyrektywa NIS2 nie wylicza konkretnych klauzul umownych (ISO 27001, prawo audytu, exit clause) — wymaga, aby podmiot uwzględnił praktyki cyberbezpieczeństwa dostawcy w sposób proporcjonalny do ryzyka. Powyższa lista to rekomendacja zgodna z wytycznymi ENISA i praktyką rynku, nie dosłowny cytat z ustawy.

KSC 2.0 nie żąda, żeby audytować każdego dostawcę z taką samą intensywnością. Żąda, żeby wiedzieć, kto ma dostęp, do czego i na jakiej podstawie — i żeby ta wiedza była aktualna. To minimum zawodowe.

Kary i odpowiedzialność zarządu

Art. 34 NIS2 przewiduje kary administracyjne do 10 mln EUR lub 2% globalnego rocznego obrotu (wyższa z kwot) dla podmiotów kluczowych, oraz do 7 mln EUR lub 1,4% obrotu dla ważnych. Polska ustawa (Dz.U. 2026 poz. 252) transponuje ten reżim do krajowego systemu kar.

Istotniejszy jednak dla decydentów jest art. 20 NIS2: organy zarządzające (zarząd, rada nadzorcza) są zobowiązane zatwierdzić środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorować ich wdrożenie i ponoszą odpowiedzialność osobistą za naruszenie tego obowiązku. Dodatkowo członkowie zarządu muszą regularnie odbywać szkolenia pozwalające identyfikować ryzyka i oceniać praktyki zarządzania ryzykiem.

Dla CISO oznacza to konkret: jeśli polityka wobec dostawców nie istnieje, nie została zatwierdzona przez zarząd lub nie jest egzekwowana — odpowiedzialność nie kończy się na dziale IT.

Więcej o samej ustawie: KSC 2.0 — ustawa o krajowym systemie cyberbezpieczeństwa. Przegląd wymagań wobec łańcucha dostaw: Bezpieczeństwo łańcucha dostaw NIS2.

Co robić — checklist dla firm objętych KSC 2.0

Lista zadań uporządkowana od najszybszych do najbardziej systemowych. Część można zamknąć w ciągu tygodnia, część to projekt kwartalny.

1. Inwentaryzacja aplikacji OAuth w Workspace i M365. Google Workspace: Admin → Security → API controls → App access control. Microsoft 365: Entra ID → Enterprise applications. Eksport listy, przegląd uprawnień, wyłączenie aplikacji nieużywanych od 90+ dni.
2. Przegląd zakresów uprawnień. Aplikacje z dostępem do całego Drive, pełnej skrzynki mailowej albo „offline access" do konta — wymagają uzasadnienia biznesowego albo odebrania uprawnień.
3. Polityka zatwierdzania integracji third-party. Zanim zespół podłączy narzędzie AI do Workspace, musi być wpisane w rejestr, ocenione pod kątem ryzyka i zatwierdzone. To nie spowalnia — to porządkuje.
4. Rotacja sekretów na platformach PaaS. W Vercel, Netlify, Railway i podobnych — wszystkie klucze API, tokeny i sekrety przenieść do pól szyfrowanych („Sensitive" w Vercel, odpowiedniki w innych platformach). Zmienne środowiskowe przechowywane jawnie traktować jak zawartość pliku konfiguracyjnego wstawionego do publicznego repo.
5. Klauzule SLA dostawców. Przy odnowieniu umowy z każdym kluczowym dostawcą SaaS — aneks o raportowaniu incydentów w 24h, prawie do informacji o kompromitacjach dotyczących Twojego konta, o standardzie bezpieczeństwa.
6. Threat modeling dla third-party. Dla 5-10 najważniejszych dostawców odpowiedz na pytanie: „Co by się stało, gdyby konto admina u tego dostawcy zostało przejęte?". Wnioski zapisać, plan mitigacji opracować.
7. Incident response dla supply chain. Runbook uwzględniający scenariusz „dostawca zgłasza wyciek" — kto decyduje o rotacji kluczy, kto komunikuje się z klientami Twojej firmy, jak dokumentujecie działania dla regulatora.

Ten zestaw to nie maksimum. To minimum, które pozwala uczciwie odpowiedzieć audytorowi KSC 2.0 na pytanie o literę d artykułu 21.

Nie wiesz, od czego zacząć? Inwentaryzacja aplikacji OAuth w Twoim tenancie to nasza pierwsza odpowiedź — 3 dni robocze, raport z klasyfikacją Tier 1/2/3 (krytyczni / ważni / pozostali), konkretne rekomendacje odbierania uprawnień. Bez zobowiązań, bez presji handlowej.

Zamów inwentaryzację OAuth →

Jak SecIQ pomaga

Ryzyko łańcucha dostaw rzadko daje się zamknąć jednym narzędziem. Wymaga pracy na styku zgodności, architektury tożsamości i operacji SOC.

• vCISO (virtual CISO — dyrektor ds. bezpieczeństwa na zasadzie outsourcingu) — dedykowany opiekun strategiczny pomaga zbudować politykę wobec dostawców, klasyfikację i klauzule umowne dopasowane do Twojej skali. Nie szablon z internetu, tylko dokument, który przejdzie audyt.
• Audyt zgodności KSC 2.0 — przegląd gotowości do artykułu 21, w tym litery d. Konkretna luka, konkretny priorytet, konkretny plan.
• Ocena łańcucha dostaw — inwentaryzacja aplikacji OAuth w Workspace/M365, kwestionariusze dla kluczowych dostawców, klasyfikacja Tier 1/2/3.
• Monitoring integracji OAuth — nasz SOC obserwuje zachowania aplikacji zintegrowanych z Twoim tenantem. Nietypowy wzorzec dostępu przez aplikację third-party generuje alert u analityka, który zna Twoją organizację — nie anonimowego L1 z globalnej kolejki.

To praca na styku wszystkich czterech filarów SecIQ — ludzi (vCISO, dedykowany analityk SOC), procedur (polityka wobec dostawców, klauzule umowne), technologii (inwentaryzacja OAuth, monitoring integracji) i AI (detekcja nietypowych wzorców dostępu przez aplikacje third-party).

Migracja nie jest odpowiedzią

Incydent Vercela pokazuje, że pojedynczy dostawca w łańcuchu dostaw może być pojedynczym punktem ekspozycji. Ten wniosek nie zmienia się, gdy zamienisz Vercela na Azure, AWS, Cloudflare czy self-hosted Kubernetes — zmienia się tylko lista OAuth grantów, nazwa panelu admina i umowa, którą negocjujesz.

KSC 2.0 nie każe wybierać „bezpiecznego dostawcy". Każe znać i oceniać swoich dostawców — niezależnie od tego, czy to Vercel, Azure, AWS czy dowolny inny SaaS. Odpowiedzią nie jest panic-migracja, tylko inwentaryzacja, klauzule umowne, monitoring i plan IR na wypadek kompromitacji dostawcy. Dokładnie to, co opisuje artykuł 21 ust. 2 lit. d.

Case Vercel nie jest ostatni. Będą kolejne, z tego samego wzorca. Dobrą wiadomością jest to, że wzorzec jest zrozumiały i da się przed nim zabezpieczyć metodycznie — niezależnie od tego, gdzie hostujesz.

Następny krok: zamów 60-minutowy audyt gotowości do art. 21 ust. 2 lit. d KSC 2.0. Otrzymasz listę luk w polityce wobec dostawców, inwentaryzację aplikacji OAuth w Twoim tenancie Google Workspace lub Microsoft 365 oraz konkretny plan naprawczy z priorytetami. Bez zobowiązań handlowych — umów audyt KSC 2.0.

Jeśli interesuje Cię szerszy kontekst regulacji — hub NIS2/KSC 2.0.

Źródła

• Vercel Knowledge Base — April 2026 Security Incident
• BleepingComputer — Vercel confirms breach as hackers claim to be selling stolen data
• The Hacker News — Vercel breach tied to Context.ai hack
• Microsoft Security Response Center — Midnight Blizzard: Nation-state attack on corporate systems (styczeń 2024)
• EUR-Lex — Dyrektywa (UE) 2022/2555 (NIS2), art. 21
• ENISA Threat Landscape 2025
• Verizon Data Breach Investigations Report 2025
• BetterCloud — 2025 State of SaaS Report
• Dziennik Ustaw — Ustawa o krajowym systemie cyberbezpieczeństwa (nowelizacja, Dz.U. 2026 poz. 252)