Zatruta aktualizacja popularnej wtyczki dla programistów pokazała, jak szybko dostawca staje się wektorem ataku. Nowy KSC mówi jasno: odpowiedzialność za bezpieczeństwo usługi zostaje w firmie.
O co chodzi i dlaczego to ważne
29 października 2026 r. przez kilkanaście godzin marketplace edytora Cursor dystrybuował zmodyfikowaną wersję wtyczki Claude Code – pod nazwą prawdziwego wydawcy i jako zwykłą aktualizację. Według komunikatu Cursora złośliwe były wersje 2.1.312 i 2.1.313 dla Windows i macOS. Kod dopisywał do authorized_keys klucz SSH atakującego (opisany niewinnie jako svc-telemetry), próbował zestawić odwrócony tunel SSH, instalował mechanizm przetrwania i wysyłał na serwer atakującego informacje o hoście, w tym nazwy zmiennych środowiskowych zawierających słowa w rodzaju KEY czy TOKEN. Sekurak, powołując się na Cursora, pisze o nawet 5 tys. potencjalnie poszkodowanych użytkowników.
Nikt w zaatakowanych firmach nie popełnił klasycznego błędu: nie kliknął w phishing, nie zainstalował pirackiego oprogramowania. Zaufał kanałowi aktualizacji dostawcy. To jest istota ryzyka łańcucha dostaw – i dokładnie ten obszar nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (KSC) stawia po stronie firmy, a nie dostawcy.
Co mówi znowelizowany KSC
Nowelizacja KSC wdrażająca dyrektywę NIS2 została opublikowana w Dz.U. 2026 poz. 252 i obowiązuje od 3 kwietnia 2026 r. Dla średnich firm z sektorów objętych ustawą (m.in. produkcja wybranych wyrobów, transport, usługi cyfrowe, część usług finansowych) kluczowy jest kalendarz:
| Termin | Obowiązek |
|---|---|
| 3 października 2026 | wpis do wykazu podmiotów kluczowych i ważnych (minął – kto się nie zgłosił, powinien to pilnie nadrobić) |
| 3 kwietnia 2027 | wdrożenie systemu zarządzania bezpieczeństwem informacji, obsługi incydentów, podłączenie do systemu S46 |
| 3 kwietnia 2028 | pierwszy obowiązkowy audyt podmiotów kluczowych (poza dotychczasowymi operatorami usług kluczowych), potem co najmniej co 3 lata |
Źródło terminów: Ministerstwo Cyfryzacji (gov.pl), potwierdzone przez Forsal.
Bezpieczeństwo łańcucha dostaw nie jest tu dodatkiem. Dyrektywa NIS2 wprost wymienia je wśród obowiązkowych środków zarządzania ryzykiem (art. 21 ust. 2 lit. d), w tym relacje z bezpośrednimi dostawcami i usługodawcami. Polska ustawa idzie w tę samą stronę: podmiot odpowiada za bezpieczeństwo świadczonej usługi jako całości – niezależnie od tego, czy dany element utrzymuje sam, czy kupuje go na zewnątrz (szerzej: komentarz Anny Szymańskiej w CyberDefence24).
Dochodzą do tego dwa mechanizmy, które bezpośrednio dotykają relacji z dostawcami:
- Dostawca wysokiego ryzyka – minister właściwy ds. informatyzacji, po procedurze z udziałem Kolegium ds. Cyberbezpieczeństwa, może uznać dostawcę za dostawcę wysokiego ryzyka. Podmioty kluczowe i ważne nie mogą wtedy wprowadzać jego produktów, a te już używane trzeba wycofać w wyznaczonym terminie. Te przepisy prezydent skierował do Trybunału Konstytucyjnego w trybie kontroli następczej, ale obowiązują.
- Kary – dla podmiotów kluczowych do 10 mln euro lub 2% rocznego obrotu, dla ważnych do 7 mln euro lub 1,4% obrotu (wg Prawo.pl; progi zgodne z art. 34 NIS2).
Wniosek dla zarządu jest prosty: umowa outsourcingowa przenosi pracę, ale nie przenosi odpowiedzialności.
Gdzie firmy realnie się potkną
Z perspektywy dyrektora IT największe ryzyka nie leżą w egzotycznych atakach, tylko w codziennej praktyce:
- Brak pełnej listy dostawców ICT. Księgowość zna dostawców, którym płaci faktury. IT zna systemy, które utrzymuje. Nikt nie zna wtyczek, rozszerzeń przeglądarki, narzędzi SaaS kupionych kartą przez dział marketingu czy integracji „na chwilę”. Incydent z Cursorem dotyczył właśnie warstwy, która rzadko trafia do rejestrów: narzędzi programisty.
- Automatyczne aktualizacje bez rozróżnienia. Szybkie łatanie to dobra praktyka, ale aktualizacja jest też kanałem dostarczenia kodu, którego nikt nie zweryfikował. Trzeba świadomie zdecydować, co aktualizuje się natychmiast (np. łatki bezpieczeństwa systemu), a co z krótkim opóźnieniem.
- Umowy bez zębów. Typowa umowa z integratorem czy dostawcą SaaS nie przewiduje prawa audytu, terminu zgłoszenia incydentu ani planu wyjścia. Po nowelizacji to luka, którą trudno wytłumaczyć audytorowi.
- Stacje robocze z szerokim dostępem. Laptop administratora czy programisty z kluczami do chmury, repozytoriów i produkcji jest dla atakującego cenniejszy niż serwer. Złośliwa wtyczka zbierała właśnie nazwy zmiennych z tokenami i kluczami.
- Plan wyjścia tylko na papierze. Jeśli dostawca zostanie uznany za dostawcę wysokiego ryzyka albo zostanie skompromitowany, zastąpienie go zajmuje miesiące. Bez wcześniejszego planu ciągłość usługi stoi pod znakiem zapytania.
Checklista: łańcuch dostaw IT w 90 dni
Inwentaryzacja (dni 1–30)
- [ ] Zbuduj rejestr dostawców ICT: systemy, usługi chmurowe, integratorzy, serwis, oprogramowanie na stacjach roboczych – łącznie z rozszerzeniami IDE i przeglądarek.
- [ ] Połącz dane z trzech miejsc: księgowość (faktury), IT (CMDB, konsola zarządzania stacjami), działy biznesowe (narzędzia kupione samodzielnie).
- [ ] Sklasyfikuj dostawców: krytyczni (awaria lub kompromitacja zatrzymuje usługę albo daje dostęp do danych), istotni, pozostali.
Ocena i umowy (dni 31–60)
- [ ] Dla dostawców krytycznych przeprowadź ocenę ryzyka: certyfikaty, historia incydentów, lokalizacja przetwarzania danych, podwykonawcy, status regulacyjny samego dostawcy.
- [ ] Uzupełnij umowy o: prawo audytu, termin powiadomienia o incydencie zgodny z Twoimi obowiązkami raportowymi, minimalne wymagania techniczne, obowiązek informowania o zmianie podwykonawców i właściciela, klauzulę wyjścia z przekazaniem danych.
- [ ] Sprawdź, czy któryś z dostawców nie jest objęty postępowaniem dotyczącym dostawcy wysokiego ryzyka.
Kontrole techniczne (dni 61–90)
- [ ] Wprowadź listę dozwolonych rozszerzeń IDE i przeglądarek; zablokuj instalację spoza niej na stacjach zarządzanych.
- [ ] Ustal politykę aktualizacji: łatki bezpieczeństwa – szybko; narzędzia deweloperskie i wtyczki – z opóźnieniem 24–72 h lub po wydaniu w kanale stabilnym.
- [ ] Monitoruj zmiany w
authorized_keys, nowe zadania harmonogramu, LaunchAgents i wpisy autostartu – to typowe ślady przetrwania. - [ ] Ogranicz sekrety na stacjach roboczych: krótkotrwałe tokeny, menedżer sekretów zamiast zmiennych środowiskowych, osobne konta do produkcji.
- [ ] Przygotuj procedurę „dostawca skompromitowany”: izolacja hostów, rotacja poświadczeń, komunikacja, kryteria zgłoszenia incydentu do CSIRT.
- [ ] Dla 3–5 najważniejszych dostawców spisz plan zastępczy: alternatywa, czas przejścia, właściciel decyzji.
Stale
- [ ] Przegląd rejestru dostawców co kwartał i przy każdej zmianie właściciela, podwykonawcy lub zakresu usługi.
- [ ] Raport dla zarządu: liczba dostawców krytycznych, stan umów, otwarte ryzyka. Odpowiedzialność kierownictwa za cyberbezpieczeństwo to jeden z filarów nowego KSC.
Podsumowanie
Incydent z zatrutą wtyczką nie jest wyjątkiem, tylko kolejnym przypomnieniem, że kanał dostawy oprogramowania jest częścią powierzchni ataku. Nowelizacja KSC daje firmom czas do 3 kwietnia 2027 r. na wdrożenie obowiązków, ale rejestr dostawców, poprawione umowy i plan wyjścia to praca na miesiące, nie tygodnie. Warto zacząć od inwentaryzacji – bo nie da się zarządzać ryzykiem dostawcy, o którego istnieniu się nie wie.
Jeśli firma dopiero ustala, czy i jak podlega ustawie, punktem wyjścia może być Poradnik NIS2 w średniej firmie: od czego zacząć.
Źródła
- Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa, Dz.U. 2026 poz. 252 (ELI)
- Ministerstwo Cyfryzacji: Nowelizacja KSC – obowiązki podmiotów kluczowych i ważnych
- Forsal: Nowelizacja ustawy o KSC weszła w życie – kluczowe terminy i obowiązki do 2028 r.
- Prawo.pl: Prezydent podpisał ustawę o krajowym systemie cyberbezpieczeństwa i skierował wniosek do TK
- Dyrektywa (UE) 2022/2555 (NIS2), EUR-Lex
- [CyberDefence24, A. Szymańska: Outsourcing bez outsourcingu odpowiedzialności [OPINIA]](https://cyberdefence24.pl/cyberbezpieczenstwo/poradniki/outsourcing-bez-outsourcingu-odpowiedzialnosci-jak-zabezpieczyc-lancuch-dostaw-podmiotu-krytycznego-opinia)
- Sekurak: Złośliwa aktualizacja Claude Code w Cursor Marketplace
- Cursor: Claude Code extension security notice
- OpenSourceMalware: Trojanized Claude Code extension plants persistent SSH backdoor
Artykuł ma charakter informacyjny i nie stanowi porady prawnej.
✦ Ten tekst przygotował agent AI. Przed publikacją przeszedł recenzję autora.