Przejdź do treści głównej

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

Sebastian Cyber Security Consultant
10 min czytania
Ewolucja Zagrożenia: Dlaczego Shai-Hulud 2.0 zmusza nas do ponownego zdefiniowania Bezpieczeństwa Łańcucha Dostaw Oprogramowania

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

Samo skanowanie po fakcie jest niewystarczające. Musimy przejść do modelu bezpieczeństwa przewidującego zagrożenia poprzez rozumienie kontekstu kodu i całego ekosystemu. Deweloperzy często nie są świadomi zależności używanych przez ich kod.

Skala i Wyrafinowanie Ataku Shai-Hulud 2.0

Wersja 2.0 identyfikowana w listopadzie 2025 roku jako "The Second Coming" pokazała szybkość rozprzestrzeniania się zagrożeń w ekosystemie npm. Pierwszy atak we wrześniu 2025 skompromitował ponad 180 pakietów npm. Nowa fala listopada 2025 objęła ponad 796 unikalnych pakietów npm i 1092 unikalne wersje, dotykając projektów z Zapier, ENS Domains, PostHog i Postman.

Kradzież poświadczeń i propagacja robaka

Atak rozpoczął się od przejęcia kont deweloperów i wstrzyknięcia złośliwego kodu w popularne zależności npm. Kod zbierał poświadczenia poprzez kierowanie na:

  • Tokeny GitHub (PATs/Actions secrets)
  • Tokeny npm
  • Klucze dostępu do chmur (AWS, GCP, Azure)
  • Inne sekrety poprzez narzędzie Trufflehog

Mechanizm samopropagacji był szczególnie niepokojący: używając skradzionych tokenów npm, robak automatycznie infekował dodatkowe pakiety, inkrementował numery wersji i publikował je na npm.

Celowe uderzenie w proces CI/CD i środowiska chmurowe

Atak nie ograniczał się do maszyn deweloperów. Około 20% skompromitowanych maszyn stanowiły GitHub runners. Malware wykrywało środowisko CI poprzez zmienne takie jak GITHUB_ACTIONS lub GITLAB_CI.

W środowiskach CI payload działał synchronicznie, aby utrzymać runnera w aktywności. Na maszynach deweloperskich działał w tle, aby nie wzbudzać podejrzeń.

Malware scrapowało pliki konfiguracyjne i używało pakietów SDK do interakcji z usługami metadanych instancji (IMDS) w chmurach, aby przechwycić tymczasowe tokeny uwierzytelniające.

Wyrafinowana eksfiltracja i „Wyłącznik Bezpieczeństwa"

W przeciwieństwie do wcześniejszych ataków, Shai-Hulud 2.0 wykorzystuje publiczne repozytoria GitHub do eksfiltracji danych, tworzone za pomocą skradzionych tokenów, oznaczane opisem: "Sha1-Hulud: The Second Coming".

Atakujący stworzyli mechanizm obronny: dead man's switch. Jeśli zainfekowany system straci dostęp do GitHub i npm, malware uruchamia niszczycielski ładunek, próbując zniszczyć dane użytkownika poprzez nadpisanie sektorów dysku lub użycie narzędzia shred.

Ta taktyka sprawia, że tradycyjne metody reagowania kryzysowego stają się ryzykowne — mogą prowadzić do zniszczenia danych na tysiącach zainfekowanych systemów.

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

Tradycyjne podejścia SAST (Static Application Security Testing) czy DAST ujawniają swoje luki w ochronie łańcucha dostaw. ICWT oferuje platformę OX Security, zaprojektowaną do rozwiązania tych problemów poprzez wzmacnianie tożsamości i polityk potoków CI/CD, zamiast polegania na czystości pakietów upstream.

Kompleksowa widoczność i SBOM jako podstawa

OX Security działa jako zaawansowane narzędzie Software Composition Analysis (SCA), dostarczając Software Bill of Materials (SBOM).

Generuje SBOM wzbogacony o kontekstowe metadane — nie tylko wiadomo jakie komponenty są obecne, ale gdzie są używane, czy są osiągalne i czy dostępna jest poprawka. Zapewnia ciągłe monitorowanie zmian w komponentach w czasie rzeczywistym w repozytoriach, rejestrach i potokach CI/CD.

Wymuszanie polityk w CI/CD

Ataki takie jak Shai-Hulud 2.0 wykorzystują przejęte poświadczenia. OX Security umożliwia wbudowanie ochrony w potoki DevSecOps poprzez:

  • Blokowanie ryzykownych zmian za pomocą zasad polityk w potokach CI/CD
  • Utwardzanie tożsamości i polityki potoków jako codzienne standardy, promując 2FA sprzętowe, krótkotrwałe tokeny oraz wyłączanie domyślne skryptów instalacyjnych w CI

Kontekstowa Analiza AI i Automatyczna Remediacja

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

Analiza nie polega na prostym dopasowywaniu wzorców — jej AI rozumie rzeczywiste implikacje zachowania pakietu, takie jak próba przechwytywania podstawowych funkcji przeglądarki i interfejsów API.

Przy wykryciu złośliwego pakietu, platforma identyfikuje incydent jako Dependency-Chain Hijack i dostarcza jasne, automatyczne ścieżki naprawcze — konkretne zalecenia zamiast ogólnych komunikatów.

Taka ochrona jest wbudowana w edytory AI i IDE, co oznacza zapobieganie lukom przed ich powstaniem, przenosząc bezpieczeństwo w lewo w cyklu tworzenia oprogramowania.

Podsumowanie: Wzmocnienie Odporności Twojej Organizacji

W erze, gdzie 70–90% kodu w nowoczesnych aplikacjach pochodzi z zależności open-source, a ataki ukierunkowują się na przejmowanie poświadczeń i automatyzacji, wspólna odpowiedzialność nie może polegać na biernym oczekiwaniu na łatkę.

Odporność osiąga się poprzez monitorowanie i wzmocnienie procesu wytwarzania i integracji oprogramowania (CI/CD).

ICWT oferuje pełne wsparcie we wdrożeniu i optymalizacji platformy OX Security. Nie pozwól, aby ewolucja zagrożeń zaskoczyła Twoją organizację — skontaktuj się, aby omówić zabezpieczenie łańcucha dostaw oprogramowania i ochronę poświadczeń przed atakami nowej generacji.

Tagi:
#Shai-Hulud #supply chain security #OX Security #npm #CI/CD #DevSecOps