Ewolucja Zagrożenia: Dlaczego Shai-Hulud 2.0 zmusza nas do ponownego zdefiniowania Bezpieczeństwa Łańcucha Dostaw

Jako ICWT (In Cloud We Trust), partner OX Security w Polsce, nasza rola polega na monitorowaniu ewolucji zagrożeń i dostarczaniu rozwiązań, które odpowiadają na realne, a nie teoretyczne wyzwania. Ostatnie ataki na ekosystem open-source, zwłaszcza powrót malware Shai-Hulud w wersji 2.0, stanowią wyraźny dowód na to, że ryzyko w łańcuchu dostaw oprogramowania nie dotyczy już jedynie luk CVE, błędów w kodzie, ale skompromitowanych tożsamości i zaufanej automatyzacji.

Dlatego uważamy, że w obecnych czasach samo skanowanie po fakcie jest niewystarczające. Musimy przejść do modelu bezpieczeństwa, który przewiduje zagrożenia, rozumiejąc kontekst kodu i całego ekosystemu. Deweloperzy w erze tzw. vibe-codingu i używania licznych narzędzi AI często nie są nawet świadomi z jakich zależności korzysta ich kod.

Skala i Wyrafinowanie Ataku Shai-Hulud 2.0

Wersja 2.0 ataku Shai-Hulud, zidentyfikowana w listopadzie 2025 roku jako „The Second Coming", pokazała, jak szybko i destrukcyjnie może rozprzestrzeniać się zagrożenie w ekosystemie npm. Już w pierwszym ataku, we wrześniu 2025 roku, skompromitowano ponad 180 pakietów npm. Nowa fala, z listopada 2025 roku, objęła ponad 796 unikalnych pakietów npm, dotykając łącznie 1092 unikalnych wersji.

Analiza techniczna tego incydentu, w którym ucierpiały popularne projekty m.in. z Zapier, ENS Domains, PostHog i Postman, ujawnia kilka kluczowych aspektów, które podnoszą poprzeczkę dla DevSecOps:

1. Kradzież poświadczeń i propagacja robaka (Worm-like Propagation)

Atak rozpoczął się od przejęcia kont deweloperów, a następnie wstrzyknięcia złośliwego kodu do popularnych zależności npm. Ten złośliwy kod miał za zadanie zbierać poświadczenia (credentials stealer).

Atakujący celowali w szeroki zakres kluczy:

• Tokeny GitHub (PATs/Actions secrets)
• Tokeny npm
• Klucze dostępu do chmur (AWS, GCP, Azure)
• Inne sekrety poprzez uruchomienie narzędzia Trufflehog do skanowania całego katalogu domowego ofiary

Najbardziej niepokojący jest mechanizm samopropagacji: używając skradzionych tokenów npm, robak automatycznie infekował dodatkowe pakiety należące do skompromitowanego dewelopera, inkrementował ich numery wersji i publikował je z powrotem na npm.

2. Celowe uderzenie w proces CI/CD i środowiska chmurowe

Atak nie ograniczał się do maszyn deweloperów. Nasze źródła wskazują, że około 20% skompromitowanych maszyn stanowiły GitHub runners. Malware wykrywało, czy jest uruchamiane w środowisku CI (poprzez zmienne środowiskowe, takie jak GITHUB_ACTIONS czy GITLAB_CI).

Złośliwy payload:

• W środowiskach CI działał synchronicznie, aby utrzymać runnera w aktywności przez cały proces infekcji
• W środowiskach nie-CI (maszyny deweloperskie) działał w tle, aby nie wzbudzać podejrzeń użytkownika

Malware nie tylko scrapowało pliki konfiguracyjne, ale używało pakietów SDK do interakcji z usługami metadanych instancji (IMDS) w chmurach (AWS, Azure, Google Cloud). Celem było przechwycenie tymczasowych tokenów uwierzytelniających używanych przez aplikacje kontenerowe i funkcje serverless.

3. Wyrafinowana eksfiltracja i „Wyłącznik Bezpieczeństwa" (Dead Man's Switch)

W przeciwieństwie do wcześniejszych ataków, które używały łatwych do zablokowania zewnętrznych endpointów, Shai-Hulud 2.0 wykorzystuje do eksfiltracji danych publiczne repozytoria GitHub, tworzone za pomocą skradzionych tokenów. Repozytoria te były oznaczone specyficznym opisem: „Sha1-Hulud: The Second Coming".

Co gorsza, atakujący stworzyli mechanizm obronny: „dead man's switch". Jeśli zainfekowany system straci dostęp zarówno do GitHub (do eksfiltracji), jak i do npm (do propagacji), złośliwe oprogramowanie uruchamia niszczycielski ładunek, który próbuje zniszczyć dane użytkownika na skompromitowanej maszynie, nadpisując sektory dysku lub używając narzędzia shred.

Ta nowa taktyka sprawia, że tradycyjne metody reagowania kryzysowego (takie jak masowe usuwanie złośliwych repozytoriów) stają się niezwykle ryzykowne, gdyż mogą prowadzić do jednoczesnego zniszczenia danych na tysiącach zainfekowanych systemów.

OX Security: Odpowiedź na Bezpieczeństwo Oparte na Tożsamości

To jest moment, w którym tradycyjne podejścia SAST (Static Application Security Testing) czy DAST (Dynamic Application Security Testing), które są skanerami post-factum, ujawniają swoje luki w ochronie łańcucha dostaw. My w ICWT oferujemy platformę OX Security, która została zaprojektowana, aby rozwiązać te problemy, koncentrując się na wzmacnianiu tożsamości i politykach potoków CI/CD, zamiast polegać na nadziei, że pakiety upstream pozostaną czyste.

Platforma OX jest rozwiązaniem klasy korporacyjnej, które zabezpiecza aplikacje od kodu do środowiska uruchomieniowego (code-to-runtime).

1. Kompleksowa widoczność i SBOM jako podstawa

OX Security działa jako zaawansowane narzędzie Software Composition Analysis (SCA), ale jego siła leży w dostarczaniu kompletnej listy komponentów, czyli Software Bill of Materials (SBOM).

Platforma OX:

• Generuje SBOM i wzbogaca go o kontekstowe metadane. Oznacza to, że wiemy nie tylko co mamy, ale gdzie dany pakiet jest używany, czy jest osiągalny i czy dostępna jest poprawka.
• Zapewnia ciągłe monitorowanie zmian w komponentach w czasie rzeczywistym – w repozytoriach, rejestrach i potokach CI/CD.

2. Wymuszanie polityk w CI/CD (Policy Enforcement)

Ataki takie jak Shai-Hulud 2.0 wykorzystują przejęte poświadczenia, aby wprowadzić ryzykowne zmiany. OX Security umożliwia wbudowanie ochrony w potoki DevSecOps.

W kontekście zagrożeń łańcucha dostaw, platforma pozwala:

• Blokować ryzykowne zmiany za pomocą zasad polityk w potokach CI/CD.
• Uczynić utwardzanie tożsamości (identity hardening) i polityki potoków codziennymi standardami. Oznacza to promowanie stosowania sprzętowego 2FA, krótkotrwałych tokenów (short-lived tokens) oraz wyłączanie domyślne skryptów instalacyjnych w CI.

3. Kontekstowa Analiza AI i Automatyczna Remediacja

Kiedy doszło do ataku typu Shai-Hulud, klienci OX widzieli by to natychmiast na swoich pulpitach bezpieczeństwa.

Platforma OX:

• Nie polega tylko na prostym dopasowywaniu wzorców. Jej analiza AI rozumie prawdziwe implikacje zachowania pakietu (np. próbę przechwytywania podstawowych funkcji przeglądarki i interfejsów API).
• W przypadku wykrycia złośliwego pakietu, platforma identyfikuje incydent jako krytyczny „Dependency-Chain Hijack".
• Co kluczowe, dostarcza jasne, automatyczne ścieżki naprawcze. Zamiast ogólnego komunikatu, otrzymujesz konkretne zalecenie.

Taka ochrona jest wbudowana bezpośrednio w edytory AI i IDE, co oznacza, że zapobiegamy powstawaniu luk, zanim jeszcze zostaną stworzone, przenosząc bezpieczeństwo „w lewo" w cyklu tworzenia oprogramowania.

Podsumowanie: Nasza Propozycja Wzmocnienia Twojej Odporności

W miarę jak 70–90% kodu w nowoczesnych aplikacjach pochodzi z zależności open-source, a ataki stają się coraz bardziej ukierunkowane na przejmowanie poświadczeń i automatyzacji, nasza wspólna odpowiedzialność za bezpieczeństwo nie może polegać na biernym oczekiwaniu na łatkę. Odporność osiąga się teraz poprzez monitorowanie i wzmocnienie procesu wytwarzania i integracji oprogramowania (CI/CD).

Jako ICWT, oferujemy pełne wsparcie we wdrożeniu i optymalizacji platformy OX Security w Twoim środowisku DevSecOps.

Nie pozwól, aby ewolucja zagrożeń zaskoczyła Twoją organizację. Skontaktuj się z nami, aby omówić, w jaki sposób możemy zabezpieczyć Twój łańcuch dostaw oprogramowania i chronić Twoje poświadczenia przed atakami nowej generacji.