Wprowadzenie do problemu / definicja
SBOM, czyli Software Bill of Materials, stał się jednym z podstawowych narzędzi porządkujących wiedzę o komponentach wykorzystywanych w nowoczesnym oprogramowaniu. Umożliwia identyfikację bibliotek, pakietów i zależności obecnych w aplikacji, co wspiera analizę podatności, zgodność oraz zarządzanie ryzykiem.
W praktyce sam SBOM nie daje jednak pełnego obrazu incydentu bezpieczeństwa. W przypadku ataków na łańcuch dostaw kluczowe znaczenie ma nie tylko to, jakie komponenty zostały zadeklarowane, ale również to, jaki kod faktycznie uruchomił się w środowisku produkcyjnym, jakie procesy zainicjował oraz z jakimi zasobami się komunikował.
W skrócie
Rosnąca liczba ataków na łańcuch dostaw pokazuje, że statyczny wykaz zależności nie wystarcza do szybkiego określenia skali kompromitacji. Złośliwe komponenty mogą być ukryte głęboko w zależnościach przechodnich, a nieaktualny SBOM może wprowadzać zespoły bezpieczeństwa w błąd.
Przykład kampanii Shai-Hulud unaocznia, że organizacje potrzebują połączenia aktualnych SBOM-ów, telemetrii runtime, korelacji logów i precyzyjnych procedur reagowania. Dopiero taki zestaw umożliwia ustalenie, które systemy zostały rzeczywiście dotknięte incydentem.
Kontekst / historia
Opisany scenariusz dotyczy kompromitacji powiązanej z robakiem Shai-Hulud, wykorzystywanym jako przykład problemów operacyjnych podczas reagowania na incydent w dużym środowisku SaaS. Na pierwszy rzut oka podejrzany pakiet wyglądał wiarygodnie: posiadał poprawny skrót kryptograficzny, rozpoznawalne repozytorium i cechy sugerujące legalne pochodzenie.
Problem ujawnił się na poziomie zależności przechodnich. Złośliwy komponent znajdował się kilka warstw niżej w drzewie pakietów, przez co nie został wykryty w audycie skupionym na zależnościach najwyższego poziomu. Dodatkowo zespół bezpieczeństwa opierał się na SBOM-ie, który nie odzwierciedlał aktualnego stanu środowiska produkcyjnego.
W efekcie początkowa ocena ryzyka okazała się zbyt optymistyczna, a ustalenie realnego zasięgu incydentu wymagało ręcznej korelacji logów, telemetrii i danych pochodzących z wielu usług.
Analiza techniczna
Najważniejsze ograniczenie SBOM-u polega na tym, że odpowiada on głównie na pytanie, jakie komponenty powinny znajdować się w aplikacji. Nie odpowiada natomiast automatycznie na pytania dotyczące wykonania kodu, uprawnień procesu, komunikacji sieciowej czy dostępu do sekretów i systemów wewnętrznych.
W omawianym przypadku pierwszym sygnałem ostrzegawczym nie był sam wykaz zależności, ale nietypowe zachowanie procesu wykryte przez mechanizmy behawioralne. To pokazuje, że warstwa obserwacji runtime może ujawniać nadużycia niewidoczne dla klasycznej analizy statycznej.
Dodatkowym problemem jest aktualność danych. W dynamicznych środowiskach opartych na mikroserwisach i szybkim CI/CD nawet niewielkie opóźnienie w generowaniu SBOM-u może sprawić, że zespół reaguje na podstawie historycznego obrazu systemu, a nie rzeczywistego stanu produkcji.
Ataki wykorzystujące zależności przechodnie są szczególnie niebezpieczne, ponieważ złośliwy pakiet może zostać zaimportowany pośrednio przez legalny komponent. Atakujący mogą też wykorzystywać wiarygodnie wyglądające repozytoria, podszywać się pod maintainerów lub publikować pakiety przypominające nazewnictwem wewnętrzne biblioteki organizacji.
Z perspektywy obrony kluczowa staje się więc widoczność runtime, pozwalająca ustalić:
- które usługi załadowały podejrzany moduł,
- kiedy doszło do jego wykonania,
- jakie procesy potomne zostały uruchomione,
- z jakimi hostami, kontenerami lub usługami komunikował się komponent,
- czy uzyskał dostęp do sekretów, tokenów, repozytoriów lub systemów buildowych.
Taka analiza wymaga korelacji danych z EDR, logów aplikacyjnych, telemetrii kontenerów, monitoringu procesów, systemów obserwowalności oraz pipeline’ów dostarczania oprogramowania. Dopiero połączenie tych źródeł pozwala zbudować rzeczywisty obraz ścieżki wykonania i zasięgu zagrożenia.
Konsekwencje / ryzyko
Największym zagrożeniem jest błędne oszacowanie skali incydentu. Jeśli organizacja przyjmie, że brak wskazania w audycie lub niepełny SBOM oznacza brak ryzyka, może przeoczyć faktyczne wykonanie złośliwego kodu w produkcji.
Taki błąd prowadzi zwykle do opóźnionej izolacji systemów, zawężenia zakresu dochodzenia oraz niedoszacowania wpływu incydentu na środowisko biznesowe i techniczne. W rezultacie zagrożenie może utrzymywać się dłużej, obejmując kolejne usługi i zasoby.
W środowiskach enterprise konsekwencje mogą obejmować:
- lateral movement pomiędzy usługami,
- naruszenie integralności procesu build i release,
- ekspozycję sekretów oraz poświadczeń CI/CD,
- przejęcie kont utrzymujących pakiety lub repozytoria,
- długotrwałe utrzymanie się złośliwego komponentu w wielu mikroserwisach,
- chaos komunikacyjny pomiędzy zespołami technicznymi i biznesowymi.
Ryzyko ma również wymiar organizacyjny. Brak jasnej informacji o tym, które usługi są zagrożone, może sparaliżować działania SOC, DevSecOps oraz właścicieli aplikacji, wydłużając czas reakcji i zwiększając presję operacyjną.
Rekomendacje
Organizacje powinny traktować SBOM jako ważny element programu bezpieczeństwa łańcucha dostaw, ale nie jako jedyne źródło prawdy podczas obsługi incydentu. Potrzebne jest podejście wielowarstwowe, które łączy dane statyczne z obserwacją rzeczywistego wykonania kodu.
W pierwszej kolejności należy zadbać o aktualność SBOM-ów wdrożeniowych. Wykazy komponentów powinny być generowane automatycznie i powiązane z konkretnymi artefaktami release, aby odzwierciedlały realny stan produkcji możliwie najbliżej momentu wdrożenia.
Drugim filarem jest telemetria runtime. Organizacje powinny monitorować ładowanie modułów, tworzenie procesów, nietypowe połączenia sieciowe, użycie interpreterów, wykonywanie skryptów oraz dostęp do magazynów sekretów i usług tożsamości.
Równie istotne jest budowanie mapy relacji pomiędzy zależnościami a usługami biznesowymi. Sama obecność pakietu nie wystarcza do oceny ryzyka. Zespół bezpieczeństwa musi wiedzieć, gdzie dany komponent został wdrożony, jakie funkcje realizuje i z jakimi elementami środowiska się łączy.
Warto również aktywnie monitorować rejestry pakietów pod kątem podszywania się pod nazwy wewnętrznych bibliotek, podejrzanych forków oraz anomalii związanych z publisherami i maintainerami.
Procedury reagowania na incydenty powinny być z kolei oparte na analizie tego, co rzeczywiście się uruchomiło, a nie wyłącznie tego, co zadeklarowano w zależnościach. To fundamentalna zmiana z perspektywy statycznej na operacyjną.
Dodatkowe dobre praktyki obejmują:
- podpisywanie artefaktów i weryfikację pochodzenia pakietów,
- egzekwowanie polityk allowlist dla zależności,
- skanowanie zależności przechodnich,
- separację uprawnień dla pipeline’ów CI/CD,
- ograniczanie dostępu build agentów do sekretów,
- ćwiczenia tabletop dla scenariuszy kompromitacji łańcucha dostaw,
- przygotowanie jednoznacznych szablonów komunikacji kryzysowej.
Podsumowanie
SBOM pozostaje ważnym narzędziem w zarządzaniu ryzykiem związanym z łańcuchem dostaw oprogramowania, ale samodzielnie nie rozwiązuje problemu określenia zasięgu incydentu. Przypadek związany z Shai-Hulud pokazuje, że decydujące znaczenie mają aktualność danych, korelacja telemetrii oraz widoczność runtime.
Dla zespołów bezpieczeństwa najważniejsza lekcja jest jednoznaczna: podczas incydentu trzeba analizować nie tylko listę zależności, ale przede wszystkim zachowanie systemu w produkcji. To właśnie tam ujawnia się faktyczny wpływ ataku, jego zasięg i priorytety działań obronnych.
Źródła
- Dark Reading: https://www.darkreading.com/cyber-risk/sboms-alone-scope-supply-chain-attack
- CISA — Software Bill of Materials (SBOM): https://www.cisa.gov/sbom
- NIST — Secure Software Development Framework (SSDF): https://csrc.nist.gov/Projects/ssdf