Szybka odpowiedź: Ataki na łańcuch dostaw NPM polegają na naruszeniu konta zaufanego administratora lub CI/CD token, publikując złośliwą wersję pakietu, któremu programiści już ufają, i pozwalając skryptom instalacyjnym lub logice robaka tego pakietu zająć się resztą. Między sierpniem 2025 a połową 2026 roku ten schemat wywołał największą falę ataków na łańcuch dostaw pakietów npm w historii rejestru, w tym przejęcie kontroli nad chalk/debug, Robak Shai-Huludi złośliwe oprogramowanie pochodzące od państw narodowych ukryte w pakiecie pobieranym 100 milionów razy tygodniowo. Rozwiązaniem nie jest skanowanie kodu po jego instalacji. Polega ono na wyłapywaniu złośliwych pakietów przed ich zainstalowaniem i obserwowaniu pipeline ze względu na dokładne wspólne zachowanie tych ataków.
Każda instalacja jest aktem zaufania i atakujący o tym wiedzą
Deweloper prowadzi npm zainstalowaćZa tym jednym poleceniem kryje się drzewo zależności składające się z setek, a czasem tysięcy pakietów, z których większość jest pisana i utrzymywana przez ludzi, których programista nigdy nie spotka. Nikt nie przegląda tego drzewa linia po linii. Nikt nie ma na to czasu.
To zaufanie jest celem ataku. Dla atakującego tańsze jest wyłudzenie danych od jednego administratora NPM z 2.6 miliarda pobrań tygodniowo niż znalezienie luki zero-day w zaporze sieciowej firmy z listy Fortune 500. Ataki na łańcuch dostaw NPM wykorzystują właśnie tę asymetrię, a fala z lat 2025-2026 pokazuje, jak daleko się ona rozprzestrzeniła: od odizolowane typosquatting do samorozmnażających się robaków które publikują własne złośliwe pakiety szybciej, niż jakikolwiek człowiek jest w stanie zareagować.
Co uznaje się za atak na łańcuch dostaw npm
Atak na łańcuch dostaw npm to każde zdarzenie, w którym atakujący wprowadza złośliwy kod do dystrybucji npm pipeline zamiast do własnej bazy kodu docelowego, dzięki czemu złośliwe oprogramowanie pojawia się pod przykrywką rutynowej aktualizacji zależności. Punktem wejścia jest zazwyczaj jedna z trzech rzeczy: skradzione dane uwierzytelniające administratora, skradzione dane publikacyjne lub CI/CD token lub skompromitowana kompilacja pipeline który zostaje oszukany i publikuje w imieniu atakującego. Ponieważ pakiety npm automatycznie pobierają zależności przechodnie, pojedynczy skompromitowany pakiet może dotrzeć do aplikacji, które nigdy nie zadeklarowały go jako bezpośredniej zależności.
Oś czasu: największe ataki na łańcuchy dostaw NPM w latach 2025–2026
Schemat leżący u podstaw każdego ataku na łańcuch dostaw pakietów npm
Jeśli odrzucimy szczegóły, okaże się, że niemal każdy opisany powyżej incydent przebiega według tych samych czterech kroków:
- Narażaj tożsamość, nie system. Wyłudzony token użytkownika, wyciekły token npm, skradziony PAT GitHub lub wyciągnięty token OIDC CI/CD Pamięć biegacza. Atakujący nie łamie rejestru. Pożycza do niego czyjś klucz.
- Publikuj pod nazwą, której twórcy gier już ufają. Nie jest wymagane literowanie, gdy prawdziwa nazwa pakietu działa. To właśnie sprawia, że te ataki są tak skuteczne w walce z automatycznymi aktualizacjami. pipelines: aktualizacja wygląda na całkowicie legalną.
- Uruchom zanim ktokolwiek to sprawdzi. Złośliwe skrypty instalacyjne, zaciemnione ładunki lub uśpiony kod, który uruchamia się tylko w określonych warunkach, są wykonywane w momencie npm zainstalować uruchamia się, często na laptopie programisty, na długo zanim zaplanowane skanowanie bezpieczeństwa mogłoby go wykryć.
- Trwać i coraz bardziej się rozprzestrzeniać. Shai-Hulud i jego potomkowie wykorzystują skradzione dane uwierzytelniające, aby automatycznie publikować kolejny zatruty pakiet, zmieniając pojedyncze naruszenie w reakcję łańcuchową obejmującą cały graf zależności.
Dlaczego zwykłe obrony nie dają rady
Większość narzędzi AppSec została stworzona do analizy tego, co już znajduje się w repozytorium: znanych luk CVE, statycznych wzorców kodu, problemów z licencjami. Jest to konieczne, ale strukturalnie dociera za późno w przypadku tej klasy ataków. Zanim skaner wykryje zależność, skrypt instalacyjny mógł już zostać wykonany na komputerze programisty. Tradycyjne programy antywirusowe i EDR monitorują system operacyjny, a nie rejestry pakietów, więc nie rozumieją pojęcia „nowej wersji npm” jako jednostki ryzyka. Jak pokazują incydenty TanStack i Red Hat, nawet atesty integralności kompilacji, takie jak SLSA provenance nie pomagają, gdy atakujący legalnie przejął tożsamość osoby, która złożyła podpis: podpis jest ważny, ale pakiet nadal jest złośliwy.
Luka, którą wykorzystują ataki na łańcuchy dostaw npm, występuje szczególnie w momencie publikacji i instalacji, zanim powstanie sygnatura złośliwego oprogramowania i zanim pakiet zostanie uruchomiony gdziekolwiek, gdzie mógłby go wykryć tradycyjny skaner.
Jak powstrzymać kolejny atak na łańcuch dostaw npm
Część z tych działań stanowi dyscyplinę procesową, którą każdy zespół inżynierski może wdrożyć już dziś:
- Zależności pinów i commit pliki blokujące, więc automatyczna aktualizacja nie może po cichu zainstalować właśnie opublikowanej złośliwej wersji.
- Wyłącz lub przeprowadź test skryptów poinstalacyjnych domyślnie; większość pakietów nie musi wykonywać dowolnego kodu w momencie instalacji.
- Wymuś sprzętowe uwierzytelnianie wieloskładnikowe (MFA) dla kont publikujących npm, zamykając dokładną ścieżkę phishingu, która umożliwiła naruszenie bezpieczeństwa kont chalk, debug i Qix.
- Zakres i obrót CI/CD tokeny agresywniei traktować tokeny OIDC w pamięci modułu wykonawczego jako poświadczenie warte ochrony, a nie szczegół implementacji.
- Zwróć uwagę na schemat odblokowania-wstrzyknięcia-ponownego zablokowania in CI/CD:wyłączona reguła ochrony gałęzi, commit wciśnięty, reguła ponownie włączona, wszystko w krótkim czasie. To powtarzający się znak pipelinekompromis w zakresie łańcucha dostaw.
Gdzie kończy się dyscyplina procesowa
Dyscyplina procesowa zmniejsza ryzyko. Nie wychwytuje złośliwego pakietu w momencie jego opublikowania ani robaka, który już rozprzestrzenia się w grafie szybciej, niż człowiek jest w stanie go zidentyfikować. To właśnie ta warstwa stanowi podstawę bezpieczeństwa łańcucha dostaw firmy Xygeni.
Xygeni'ego MEW (wczesne ostrzeganie przed złośliwym oprogramowaniem) nieprzerwanie analizuje nowe pakiety publikowane w npm, PyPI i Maven, wykrywając złośliwe oprogramowanie przed powstaniem sygnatury, a nie po jej powstaniu, i przesyłając potwierdzone zagrożenia z powrotem do Xygeni'ego własny silnik detekcji. Zapora zależności skanuje npm, PyPI, Maven, NuGet i RubyGems w czasie rzeczywistym i blokuje złośliwe instalacje zanim dotrą one do komputera dewelopera lub kompilacji. CI/CD wykrywanie anomalii zegarki pipelines dokładnie dla wzorca zachowań leżącego u podstaw incydentów takich jak włamanie do TanStack, w tym sekwencji odblokowania-wstrzyknięcia-ponownego zablokowania, z pełnym śladem audytu. A ponieważ Xygeni Triaż i naprawa wspomagane sztuczną inteligencją dotyczy to również ustaleń pochodzących ze skanerów innych firm, zespoły nie muszą usuwać istniejących narzędzi, aby wypełnić tę lukę.
FAQ: ataki na łańcuch dostaw npm
Czym jest atak na łańcuch dostaw npm?
Jest to atak, w którym złośliwy kod dociera do aplikacji docelowej za pośrednictwem zaufanej zależności npm, a nie za pośrednictwem własnego kodu aplikacji docelowej, zwykle dlatego, że atakujący naruszył konto osoby utrzymującej, token publikacji lub CI/CD pipelinetożsamość.
Jaki był największy atak na łańcuch dostaw npm?
Pod względem zasięgu, atak typu chalk/debug z września 2025 roku należy do największych: 18 pakietów o łącznej liczbie 2.6 miliarda pobrań tygodniowo zostało przejętych za pośrednictwem jednego konta administratora, które padło ofiarą phishingu. Shai-Hulud, będąc nowinką techniczną, był ważniejszym punktem zwrotnym, jako pierwszy samonapędzający się robak w historii npm.
Jak zazwyczaj rozpoczyna się atak na łańcuch dostaw pakietów npm?
Prawie zawsze z ukradzioną tożsamością: przez phishingowego administratora, wyciekły token publikacji lub skradziony CI/CD poświadczenie, takie jak token OIDC pobrany z pamięci użytkownika, a nie włamanie techniczne do samego npm.
Czy oprogramowanie antywirusowe lub EDR może powstrzymać atak na łańcuch dostaw npm?
Niezawodny. EDR monitoruje system operacyjny i nie rozpoznaje rejestrów pakietów, a program antywirusowy opiera się na sygnaturach, co uniemożliwia jego ochronę przed złośliwym oprogramowaniem opublikowanym przed powstaniem jakiejkolwiek sygnatury. Zatrzymanie tej klasy ataków wymaga monitorowania w momencie publikacji i instalacji, a nie tylko w punkcie końcowym.
Czy SLSA provenance lub zbudować atest, aby temu zapobiec?
To dowodzi pipeline Sam w sobie nie został naruszony podczas kompilacji. Nie dowodzi to jednak, że tożsamość, która uruchomiła kompilację, nie została naruszona, co pokazały incydenty TanStack i Red Hat z ważnymi atestami dołączonymi do złośliwych pakietów.
W jaki sposób zespół może wykryć złośliwy pakiet npm zanim zostanie zainstalowany?
Poprzez ciągłą analizę złośliwego oprogramowania przed podpisaniem go w nowo opublikowanych pakietach, co jest zadaniem systemu wczesnego ostrzegania przed złośliwym oprogramowaniem i zapory zależności, zamiast polegać wyłącznie na post-hoc skanowaniu podatności kodu, który już znajduje się w repozytorium.
Gdzie zacząć
Ataki na łańcuch dostaw NPM nie zwalniają tempa, a trend od czasu Shai-Huluda wskazuje na większą, a nie mniejszą automatyzację. Zespoły najlepiej przygotowane do kolejnej kampanii to te, które przestały traktować każdą instalację NPM jako rutynowe zdarzenie i zaczęły monitorować rejestr. pipeline, a punkt końcowy jako jedna połączona powierzchnia ataku.
Plan deweloperski Xygeni obejmuje ochronę MEW i Dependency Firewall dla maksymalnie 25 repozytoriów bezpłatnie. To rozsądne miejsce, aby zobaczyć, co już znajduje się w drzewie zależności.
