Atak na łańcuch dostaw: gdy włamanie u dostawcy jest włamaniem u Ciebie

Czym jest atak na łańcuch dostaw

Atak na łańcuch dostaw, po angielsku supply chain attack, polega na tym, że napastnik nie uderza w Twoją organizację wprost, tylko przejmuje kontrolę nad kimś, komu Twoje systemy już ufają, i wchodzi kanałem, który sam otworzyłeś. Celem końcowym jesteś Ty. Punktem wejścia jest dostawca.

Definicja jest przy tym szersza, niż podpowiada intuicja. Łańcuch dostaw w cyberbezpieczeństwie to nie tylko kod: to każdy podmiot, który ma dostęp do Twoich systemów albo przechowuje Twoje dane. Producent oprogramowania, integrator z kontem serwisowym, firma hostingowa, biuro obsługujące kadry i płace, dostawca usług zarządzanych. Ryzyko dostawcy powstaje w dniu podpisania umowy, a nie w dniu incydentu, i dokładnie wtedy da się nim jeszcze zarządzać.

Dwa warianty tego samego mechanizmu

Ten sam mechanizm zaufania prowadzi do dwóch zupełnie różnych zdarzeń i mylenie ich kosztuje najwięcej. W wariancie oprogramowania napastnik podrzuca kod, który sam wnosisz do swojego środowiska. W wariancie usługi i danych nie wnosisz niczego: napastnik włamuje się do firmy, która już przetwarza Twoje dane albo ma zdalny dostęp do Twojej sieci. Mechanizm jeden, wykrywanie i odpowiedzialność zupełnie inne.

Najważniejsza różnica siedzi w trzecim i czwartym wierszu. W wariancie danych nie ma czego szukać we własnych logach, bo zdarzenie w ogóle się w nich nie odbyło. Organizacja, która zbudowała całą detekcję pod wariant pierwszy, w drugim dowiaduje się ostatnia i zwykle nie od dostawcy.

Wariant oprogramowania: pięć typowych wejść

Wspólny mianownik jest jeden: kod trafia do Ciebie drogą, którą sam uznałeś za zaufaną, więc nie zatrzymuje go żadna kontrola.

• Skażona zależność. Biblioteka używana przez Twoją aplikację dostaje wydanie z dodatkowym kodem. Instaluje się razem z resztą projektu, bo figuruje w pliku zależności
• Przejęty pakiet. Napastnik zdobywa konto opiekuna projektu w repozytorium pakietów i publikuje wydanie jako on. Wszystko się zgadza, łącznie z podpisem, bo klucz też jest już jego
• Złośliwa aktualizacja. Producent oprogramowania zostaje zaatakowany, a podpisana aktualizacja rozchodzi się do wszystkich klientów naraz, kanałem, który z założenia ma nie pytać użytkownika o zgodę
• Zatruty potok budowania. Kod źródłowy jest czysty, ale artefakt wychodzący z systemu CI/CD już nie. Przegląd kodu tego nie wychwyci: przeglądane jest źródło, a wdrażany wynik budowania
• Typosquatting nazw pakietów. Pakiet o nazwie różniącej się jedną literą od popularnego. Wystarczy literówka w pliku zależności albo komenda skopiowana z przypadkowego poradnika

Wariant usługi i danych: włamanie u kogoś, kto ma Twoje dane

Tu nie ma żadnego skażonego artefaktu i nie ma czego wycofywać. Twój udział sprowadza się do tego, że powierzyłeś komuś dane albo dostęp. Wariant obejmuje dostawcę oprogramowania w modelu usługowym, firmę hostingową, biuro rachunkowe z dostępem do danych kadrowych, integratora z otwartym kanałem zdalnym oraz dostawcę usług zarządzanych, który z definicji pracuje na szerokich uprawnieniach. Wyciek danych w firmie potrafi zacząć się na serwerze, którego nigdy nie widziałeś.

Dlaczego to działa: relacja zaufania jest przepustką

Atak na łańcuch dostaw korzysta z wyjątków, które sami ustanowiliśmy, i to zupełnie świadomie. Aktualizacja od dostawcy przechodzi przez kontrole nie dlatego, że kontrole zawiodły, tylko dlatego, że ma przejść: źródło jest na liście dozwolonych, podpis się zgadza, a wstrzymanie aktualizacji zostałoby uznane za błąd administratora.

Ta sama logika rządzi kontami. Konto integracyjne, przez które system dostawcy rozmawia z Twoim, ma szerokie uprawnienia, bo musi działać bez człowieka, o trzeciej w nocy i bez pytania o drugi składnik uwierzytelniania. Zwykle nie wygasa, rzadko bywa przeglądane i nie wywołuje żadnego alertu, gdy zaczyna robić coś nowego, ponieważ nikt nigdy nie ustalił, co jest dla niego normą.

Stąd bierze się skuteczność całego mechanizmu. Napastnik, który przejął dostawcę, nie musi łamać zabezpieczeń klienta: wchodzi wejściem służbowym, z ważną legitymacją. Reguła korelacji, która wykryłaby to samo działanie u zwykłego użytkownika, dla konta serwisowego ma zwykle wyjątek, wpisany kiedyś po to, żeby integracja przestała generować fałszywe alarmy.

Wariant danych na żywym przykładzie

Sierpień 2026 dał polskiemu rynkowi przykład podręcznikowy. 12 sierpnia Prezes UODO opublikował komunikat pod tytułem, który rozstrzyga całą sprawę: administrator musi zgłosić wyciek, do którego doszło w podmiocie przetwarzającym. Chodziło o incydent u dostawcy oprogramowania dla podmiotów leczniczych.

Pouczający jest rozkład ról. Włamanie nastąpiło w jednym miejscu, a obowiązek zgłoszenia powstał w tysiącach: według doniesień prasowych z platformy korzystało około 12 tysięcy podmiotów leczniczych i to one, a nie dostawca, są administratorami danych swoich pacjentów. Prezes UODO zapowiedział ponadto kontrolę u dostawcy, obejmującą zastosowane środki techniczne i organizacyjne oraz to, czy były regularnie testowane.

Dla pojedynczej przychodni oznacza to sytuację, której nie da się przećwiczyć w warstwie technicznej: zdarzenie odbyło się poza jej siecią, na serwerze, do którego nie ma dostępu, a ciężar zgłoszenia i zawiadomienia pacjentów zostaje po jej stronie. Kto składa zgłoszenie, od którego momentu biegnie termin i co robić w oknie oczekiwania na potwierdzenie od dostawcy, rozłożyliśmy w tekście o obowiązkach administratora przy naruszeniu ochrony danych u dostawcy. Tutaj wystarczy jeden wniosek: w wariancie danych odpowiedzialność nie wędruje razem z danymi.

Łańcuch dostaw w ustawie o KSC

Podmiot objęty ustawą o krajowym systemie cyberbezpieczeństwa odpowiada za bezpieczeństwo swojego łańcucha dostaw, a nie wyłącznie za własną infrastrukturę. Wymóg obejmuje uwzględnienie ryzyka wnoszonego przez dostawców i usługodawców, łącznie z jakością ich praktyk bezpieczeństwa oraz sposobem wytwarzania oprogramowania, z którego korzystasz.

W praktyce oznacza to przeniesienie wymagań na kontrahentów drogą umowną: przegląd umów, wymagania bezpieczeństwa w postępowaniach zakupowych i mechanizm ich weryfikacji, w tym prawo do audytu. Tym kanałem regulacja wychodzi poza podmioty formalnie nią objęte i sięga ich zaplecza technologicznego. Dostawca, który sam ustawie nie podlega, i tak dostanie kwestionariusz bezpieczeństwa, zwykle przy pierwszym przedłużeniu umowy.

Jest w tym drugie dno, o którym po polsku prawie się nie pisze. Załącznik nr 1 do ustawy obejmuje zarządzanie usługami ICT, w tym dostawców usług zarządzanych oraz usług zarządzanych w zakresie cyberbezpieczeństwa. Firma, która prowadzi dla Ciebie monitorowanie bezpieczeństwa albo utrzymuje Twoją infrastrukturę, sama może być podmiotem kluczowym albo ważnym. To zmienia charakter pytania w postępowaniu: nie pytasz wtedy o deklaracje, tylko o status prawny, który dostawca albo ma ustalony i udokumentowany, albo nie. Progi, terminy i sposób kwalifikacji zebraliśmy w tekście o tym, kogo dotyczy NIS2 i ustawa o KSC, a ujęcie od strony jednostki publicznej opisuje strona o zgodności podmiotu publicznego z ustawą o KSC.

Co realnie da się sprawdzić u dostawcy przed podpisaniem umowy

Sprawdzalne jest to, co ma postać dokumentu, zapisu w umowie albo konfiguracji, którą można pokazać. Reszta jest deklaracją i tak trzeba ją traktować. Poniżej siedem pytań neutralnych wobec technologii, razem z tym, czego nie warto przyjmować jako odpowiedzi.

Kryteria są celowo neutralne: żadne z tych pytań nie wskazuje konkretnego dostawcy ani technologii, więc wszystkie da się wpisać do dokumentacji postępowania. Warto przy tym pilnować różnicy między odpowiedzią a dowodem. Odpowiedź „tak" zamyka rubrykę w ankiecie, dowodem jest dopiero dokument, raport z testu albo zapis umowny. Ta sama zasada rządzi weryfikacją własnej organizacji i opisaliśmy ją przy okazji przebiegu audytu cyberbezpieczeństwa.

Co da się zrobić po własnej stronie

Wyboru dostawcy nie cofniesz po incydencie, ale zasięg tego incydentu w Twoim środowisku jest wynikiem decyzji podjętych dużo wcześniej. Wszystkie punkty poniżej mają jeden cel: sprawić, żeby przejęcie dostawcy nie oznaczało automatycznie przejęcia Ciebie.

Dwa punkty z tej listy bywają najtrudniejsze, a żaden z powodów nie jest techniczny. Odcięcie integracji zatrzymuje proces biznesowy, więc decyzja wymaga osoby z mandatem do zatrzymania tego procesu, wskazanej z nazwiska przed incydentem. Inwentarz integracji z kolei nie ma właściciela: powstaje przy wdrożeniu i nikt go potem nie aktualizuje, bo nie jest to niczyje zadanie.

Monitorowanie jako element obrony

Informacja o incydencie u dostawcy nie zawsze przychodzi od dostawcy. Wzmianki o jego domenie albo o Twojej organizacji w obiegu przestępczym, na giełdzie logów czy w combolistach, bywają pierwszym sygnałem, czasem na kilka dni przed oficjalnym komunikatem. Zakres i ograniczenia takiego nasłuchu, razem z tym, czego on nie pokazuje, opisuje tekst o monitorowaniu wycieków danych.

Pierwsze 48 godzin po informacji o incydencie u dostawcy

Kolejność kroków ma znaczenie, ponieważ pierwsze z nich służą ustaleniu, czy sprawa w ogóle Was dotyczy, a nie natychmiastowemu zgłoszeniu. Poniższy przebieg zakłada wariant typowy: informacja przyszła z zewnątrz, a dostawca niczego jeszcze nie potwierdził.

1. Godziny 0–2Bezpieczeństwo
   Ustal zakres powierzenia i integracji

   Sprawdź w wykazie powierzeń, jakie kategorie danych ten dostawca przetwarza, w jakim systemie i na jakiej podstawie, oraz jakimi kontami wchodzi do Waszego środowiska. To jedyne pytanie z całej listy, na które dostawca nie odpowie za Was. Zapisz też datę i godzinę, o której dotarła pierwsza informacja, bo od tego punktu ocenia się później ewentualną zwłokę.

2. Godziny 0–4Właściciel umowy
   Wystąp o potwierdzenie na piśmie

   Wyślij datowane zapytanie: czy incydent objął dane powierzone przez Waszą organizację, jakich kategorii dotyczy i jakiego okresu. Skorzystaj z kanału wskazanego w umowie, a jeżeli go nie ma, udokumentuj, jakim kanałem próbowałeś się skontaktować. Milczenie po drugiej stronie też jest faktem i też trzeba je odnotować.

3. Godziny 2–8IT i bezpieczeństwo
   Przejrzyj dostępy dostawcy do Waszych systemów

   Wypisz wszystkie konta, klucze, tokeny i połączenia zdalne przypisane temu dostawcy. Sprawdź, kiedy były ostatnio używane i czy w ostatnich dniach nie pojawiły się logowania z nietypowych adresów albo o nietypowych porach. Zakres tego przeglądu wyznacza inwentarz integracji, o ile ktoś go wcześniej prowadził.

4. Godziny 4–12IT
   Unieważnij klucze i sesje integracji

   Rotacja poświadczeń integracyjnych i unieważnienie aktywnych sesji są działaniem tanim i odwracalnym, w przeciwieństwie do ich zaniechania. Skradzione ciasteczko sesji przechodzi obok uwierzytelniania wieloskładnikowego, więc sama zmiana hasła nie zamyka dostępu. Decyzję o zawieszeniu całej integracji podejmuje osoba z mandatem do zatrzymania procesu biznesowego.

5. Godziny 12–36Inspektor ochrony danych
   Oceń, czy powstało naruszenie

   Zestaw potwierdzenie od dostawcy z własnym ustaleniem, jakie dane w ogóle znajdowały się w tym systemie. Ocena dotyczy ryzyka dla osób, nie dla organizacji. Brak potwierdzenia nie jest przy tym czasem wolnym: dopytywanie, ustalanie zakresu i przygotowanie projektu zgłoszenia wykonuje się w tym samym oknie i dokumentuje.

6. Godziny 24–48Kierownictwo
   Podejmij i udokumentuj decyzję o zgłoszeniu

   Zgłoszenie do organu nadzorczego, zgłoszenie do właściwego CSIRT albo obie ścieżki naraz, jeżeli podlegacie ustawie o KSC. Decyzję odmowną również się dokumentuje, razem z uzasadnieniem. Sposób liczenia terminu i wymaganą zawartość zgłoszenia rozpisaliśmy w tekście o naruszeniu ochrony danych u dostawcy.

Przebieg wygląda na oczywisty do chwili, w której trzeba go wykonać w piątek po godzinach. Punktem zatrzymania rzadko bywa analiza techniczna, tylko pytanie, kto ma prawo odciąć dostawcę i kto podpisze zgłoszenie.

Najczęstsze pytania

Podsumowanie

Atak na łańcuch dostaw jest niewygodny, bo przenosi ryzyko tam, gdzie nie sięgają Twoje zabezpieczenia, a obowiązki zostawia dokładnie tam, gdzie były. Kontrolujesz jednak trzy rzeczy i wszystkie trzy ustala się przed incydentem: co wpisaliście do umowy, jak szeroki dostęp ma dostawca w Waszym środowisku i jak szybko dowiecie się, że coś się stało. Bezpieczeństwo łańcucha dostaw sprowadza się do przeniesienia tych trzech decyzji z dnia incydentu na spokojny poniedziałek. Jeżeli potrzebujecie kogoś, kto poprowadzi to od strony zarządczej, od przeglądu umów po wymagania w postępowaniach, odpowiada za to usługa vCISO.

Zaufanie do dostawcy jest decyzją architektoniczną. Podejmuje się ją raz, przy podpisie, a jej zasięg sprawdza się w dniu, w którym błąd popełnił ktoś inny.