Wprowadzenie do problemu / definicja
SBOM, czyli Software Bill of Materials, stał się jednym z podstawowych narzędzi wspierających zarządzanie ryzykiem w łańcuchu dostaw oprogramowania. Umożliwia identyfikację bibliotek, komponentów i zależności użytych do budowy aplikacji. Problem zaczyna się jednak wtedy, gdy organizacja traktuje SBOM jako główne źródło wiedzy podczas obsługi incydentu bezpieczeństwa.
W praktyce SBOM pokazuje przede wszystkim, co powinno znajdować się w środowisku, ale nie daje pełnej odpowiedzi na pytania operacyjne: co faktycznie zostało uruchomione, które usługi zostały dotknięte i jak daleko mogło rozprzestrzenić się naruszenie. To szczególnie istotne w atakach typu software supply chain, gdzie zagrożenie może być ukryte głęboko w zależnościach przechodnich.
W skrócie
Opisany scenariusz pokazuje, że sam SBOM nie wystarcza do ustalenia rzeczywistego zasięgu ataku na łańcuch dostaw. Złośliwy komponent został ukryty w zależności przechodniej, przez co nie był widoczny w uproszczonym przeglądzie pakietów najwyższego poziomu.
- zagrożenie ukryto w zależności przechodniej, a nie bezpośredniej,
- nieaktualny SBOM wskazywał środowisko jako bezpieczne,
- skuteczne śledztwo wymagało danych runtime i korelacji logów,
- pełen obraz incydentu pojawił się dopiero po analizie zachowania usług produkcyjnych.
Najważniejszy wniosek jest prosty: SBOM jest przydatny, ale dopiero połączenie go z telemetrią wykonawczą, monitoringiem produkcji i sprawnym procesem reagowania daje realną zdolność oceny skali kompromitacji.
Kontekst / historia
Temat zyskał rozgłos po prezentacji scenariusza incydentu w dużym środowisku SaaS podczas konferencji ISC2 Security Congress 2026. Opis dotyczył ataku z użyciem złośliwej zależności powiązanej z kampanią Shai-Hulud. Pakiet wyglądał wiarygodnie, miał prawidłowe cechy techniczne i sygnały zaufania, które mogły zmylić zarówno ludzi, jak i narzędzia bezpieczeństwa.
Istota problemu polegała na tym, że niebezpieczny element znajdował się kilka warstw głębiej w drzewie zależności. Nie był więc bezpośrednio deklarowany przez aplikację i nie pojawiał się w prostych audytach. To przykład typowej luki między formalną dokumentacją komponentów a rzeczywistą widocznością operacyjną nad tym, co dzieje się w środowisku produkcyjnym.
Analiza techniczna
Z technicznego punktu widzenia incydent obnaża ograniczenia podejścia opartego wyłącznie na statycznej analizie komponentów. Pierwszym problemem była obecność złośliwego kodu w zależności przechodniej. Oznacza to, że aplikacja nie pobierała niebezpiecznego pakietu bezpośrednio, lecz za pośrednictwem innego komponentu. Taki model utrudnia wykrycie zagrożenia w klasycznych przeglądach manifestów i wymaga mapowania całego drzewa zależności.
Drugim istotnym elementem było to, że pierwszym sygnałem ostrzegawczym nie był sam SBOM ani kontrola integralności, lecz analiza behawioralna. To właśnie nietypowe działania wykonywane przez procesy zwróciły uwagę zespołu bezpieczeństwa. W praktyce oznacza to, że przeciwnik może przygotować artefakt wyglądający na legalny, a mimo to uruchamiający działania szkodliwe dopiero po wdrożeniu.
Kolejną słabością okazał się nieaktualny SBOM. Dokumentacja nie odzwierciedlała realnego stanu środowiska produkcyjnego, przez co początkowo błędnie oceniono zakres zagrożenia. Nawet najlepiej przygotowany SBOM traci wartość operacyjną, jeśli nie jest stale synchronizowany z rzeczywistymi wdrożeniami.
Największą trudnością było jednak ustalenie pełnego zasięgu incydentu. Same wskaźniki kompromitacji nie pozwalały określić, które usługi uruchomiły złośliwy kod, do jakich zasobów uzyskał on dostęp ani czy doszło do ruchu bocznego między systemami. Bez telemetrii runtime zespół musiał ręcznie korelować logi z wielu serwisów, co istotnie wydłużyło czas reakcji.
Najważniejszy wniosek techniczny jest taki, że podczas analizy incydentu należy badać nie tylko graf zależności, ale również graf wykonania. Organizacja musi wiedzieć nie tylko, co zostało zbudowane, lecz także co zostało uruchomione, gdzie działało i z jakimi uprawnieniami.
Konsekwencje / ryzyko
Ryzyko związane z tego typu incydentami ma charakter wielowarstwowy. Najbardziej oczywistą konsekwencją jest możliwość uruchomienia nieautoryzowanego kodu w środowisku produkcyjnym. W zależności od architektury i poziomu uprawnień może to prowadzić do kradzieży sekretów, przejęcia tożsamości usługowych, modyfikacji danych lub trwałego osadzenia backdoora.
Drugim zagrożeniem jest błędne oszacowanie skali naruszenia. Jeśli organizacja opiera się na niepełnym lub przestarzałym SBOM-ie, może uznać, że krytyczne systemy nie zostały dotknięte, podczas gdy w rzeczywistości zagrożenie nadal pozostaje aktywne. To zwiększa ryzyko dalszej propagacji ataku.
Trzecia grupa konsekwencji dotyczy procesu reagowania. Nieprecyzyjna komunikacja do interesariuszy może wywołać chaos operacyjny, równoległe śledztwa i opóźnienia w podejmowaniu decyzji. W przypadku ataków supply chain szybkość działania musi iść w parze z jakością informacji.
Rekomendacje
Organizacje powinny traktować SBOM jako jeden z elementów szerszego systemu widoczności, a nie jako samodzielne rozwiązanie problemu bezpieczeństwa łańcucha dostaw.
- Automatycznie generować aktualne SBOM-y dla rzeczywiście wdrażanych wersji aplikacji i wiązać je z konkretnymi artefaktami oraz środowiskami.
- Wdrożyć telemetrię runtime, aby monitorować ładowane moduły, uruchamiane procesy, połączenia sieciowe i dostęp do sekretów.
- Analizować pełne drzewo zależności, w tym komponenty przechodnie, pochodzenie pakietów oraz anomalie związane z publikacją i utrzymaniem projektów.
- Budować detekcję opartą na zachowaniach przeciwnika, a nie wyłącznie na nazwach pakietów, kontach czy reputacji repozytoriów.
- Przygotować jasne procedury komunikacji kryzysowej dla zespołów technicznych, kierownictwa i właścicieli biznesowych.
Szczególne znaczenie ma połączenie danych statycznych z dynamicznymi. Tylko wtedy zespół bezpieczeństwa może szybko odpowiedzieć na pytania, które usługi rzeczywiście uruchomiły zagrożony komponent i jakie skutki mogło to wywołać w środowisku.
Podsumowanie
SBOM pozostaje ważnym narzędziem w zarządzaniu bezpieczeństwem oprogramowania, ale sam nie ujawnia pełnego zakresu ataku na łańcuch dostaw. W nowoczesnych incydentach kluczowe są aktualność danych, obserwacja zachowania aplikacji, korelacja logów i zdolność szybkiego ustalenia, które usługi faktycznie wykonały złośliwy kod.
Dla zespołów bezpieczeństwa oznacza to konieczność odejścia od wyłącznie statycznego katalogowania komponentów na rzecz ciągłej widoczności operacyjnej. Dopiero takie podejście pozwala skutecznie ograniczać skutki złożonych ataków supply chain.