W skrócie: bezpieczeństwo łańcucha dostaw npm wykracza poza skaner podatności
bezpieczeństwo łańcucha dostaw npm to praktyka polegająca na upewnieniu się, że każdy pakiet instalowany w projektach JavaScript jest legalny, niezmodyfikowany i bezpieczny, nie tylko wolne od znanych luk w zabezpieczeniach.
- Luka: Klasyczny skaner luk w zabezpieczeniach npm porównuje pakiety z bazami danych CVE. Złośliwy pakiet nie ma CVE, więc przechodzi kontrolę.
- Dowód: w marcu 2026 r. przejęte konto administratora serwisu Axios, z ponad 100 milionami pobrań tygodniowo, na około trzy godziny przekształciło się w kanał dystrybucji złośliwego oprogramowania.
- Punkt wejścia: większość ataków npm jest przeprowadzana za pomocą skryptów instalacyjnych, które są uruchamiane w momencie wpisania
npm install. - Poprawka: wykrywaj złośliwe zachowania już w momencie publikacji pakietów, a nie po pojawieniu się CVE, i wzmacniaj mechanizmy uruchamiania instalacji.
31 marca 2026 roku tysiące programistów uruchomiło najzwyklejsze polecenie w JavaScript: npm installNiektórzy z nich pobrali nową wersję Axiosa, klienta HTTP, który jest obecny w ogromnej części aplikacji internetowych na świecie. Ich skanery zależności pozostały sprawne. Ich kompilacje zakończyły się sukcesem. A na ich komputerach po cichu wylądował trojan zdalnego dostępu.
Nic w tej historii nie dotyczyło luki w zabezpieczeniach. Właśnie dlatego tak wiele programów bezpieczeństwa npm ją przeoczyło.
Co się stało z aksjami?
Atak był prosty i cierpliwy. Według własna analiza post mortem opiekunów AxiosDwie złośliwe wersje, 1.14.1 i 0.30.4, zostały opublikowane za pośrednictwem zhakowanego konta głównego administratora. Atakujący nie zmienił ani jednej linijki kodu Axios. Dodał tylko jedną nową zależność, plain-crypto-js, który prowadził postinstall skrypt pobierający ładunek drugiego etapu.
Microsoft Threat Intelligence przypisał infrastrukturę do Sapphire Sleet, północnokoreańskiego aktora państwowego. Zatrute wersje były dostępne przez około trzy godziny, zanim npm je usunął. Dla każdego CI pipeline lub laptopa, na którym zainstalowano oprogramowanie w tym czasie, wystarczyły trzy godziny.
To nie był odosobniony przypadek. We wrześniu 2025 roku robak Shai-Hulud rozprzestrzenił się w setkach pakietów npm, kradnąc tokeny konserwatorów i ponownie publikując siebie. Inna technika, ta sama lekcja: w npm zaufanie jest dziedziczone automatycznie i atakujący o tym wiedzą.
Dlaczego Twój skaner luk w zabezpieczeniach npm nic nie powiedział
Większość zespołów traktuje bezpieczeństwo łańcucha dostaw npm jako problem podatności. Uruchamiają skaner podatności npm, który porównuje ich drzewo zależności z bazami danych znanych luk i naprawia to, co raportuje. Ta praca ma znaczenie. Po prostu odpowiada na inne pytanie.
| Wymiary | Pakiet podatny na ataki | Złośliwy pakiet |
|---|---|---|
| Co to jest | Prawdziwy kod z błędem | Kod napisany, aby ci zaszkodzić |
| Czy ma CVE? | Zwykle ostatecznie | Prawie nigdy |
| Kiedy jest niebezpiecznie | Kiedy wada jest osiągalna i można ją wykorzystać | W chwili instalacji |
| Co to łapie | Przeszukiwanie bazy danych luk w zabezpieczeniach | Analiza zachowania samego pakietu |
| Typowy czas reakcji potrzebny | Dni do tygodni | Minuty do godziny |
Baza danych luk w zabezpieczeniach może opisywać jedynie to, co ktoś już przeanalizował i skatalogował. Złośliwy pakiet opublikowany godzinę temu nie ma nigdzie wpisu. Skaner powraca więc bez błędów, a czysty pakiet jest odczytywany jako bezpieczny.
To jest sedno zmiany w bezpieczeństwie łańcucha dostaw npm: pytanie nie brzmi już „czy ten pakiet ma znaną wadę?”, ale „czy ten pakiet robi coś, czego nie powinien?”.
Cztery sposoby, w jakie atakujący dostają się do twoich modułów node_modules
- Przejęcie konta. Ukraść dane uwierzytelniające lub token administratora i opublikować zatrutą wersję pakietu, któremu ludzie już ufają. To jest podręcznik Axios i najtrudniejszy do wykrycia, ponieważ nazwa pakietu jest prawidłowa.
- Typosquatting. Publikować
axoisorreqeustsi czekaj na literówkę, skopiowanie i wklejenie z kiepskiego samouczka lub asystenta kodowania AI, który zasugeruje niewłaściwą nazwę. - Zamieszanie związane z zależnościami. Opublikuj pakiet publiczny o tej samej nazwie, co jeden z Twoich wewnętrznych pakietów. Jeśli Twoja konfiguracja rejestru preferuje pakiet publiczny, instalujesz kod atakującego.
- Zainstaluj skrypty. Wspólnym mianownikiem w prawie wszystkich powyższych kwestiach jest npm, który pozwala na uruchamianie pakietów
preinstallorazpostinstallskrypty automatycznie, dzięki czemu złośliwy kod zostaje wykonany zanim ktokolwiek cokolwiek zaimportuje. CISWskazówki A dotyczące kompromisu Axios zaleca ustawienieignore-scripts=truedla preciswłaśnie z tego powodu.
Jak wygląda bezpieczeństwo łańcucha dostaw npm w praktyce
Nie powstrzymasz każdego ataku jednym ruchem. Możesz uczynić się o wiele trudniejszym celem, stosując kilka nawyków:
- Commit Twój plik blokady i zainstaluj za pomocą
npm ci. Kompilacje powinny instalować dokładnie to, co zostało sprawdzone, a nie to, co rejestr wyświetlił danego ranka. - Wyłącz domyślnie skrypty instalacyjne. Zestaw
ignore-scripts=truei zezwalaj na skrypty tylko dla pakietów, które ich naprawdę potrzebują. - Określ zakres swoich wewnętrznych pakietów. Nieograniczające się nazwy wewnętrzne mogą prowadzić do pomyłek w zakresie zależności.
- Sprawdź pochodzenie. npm obsługuje oświadczenia o pochodzeniu Łączą one opublikowany pakiet ze źródłem i kompilacją. Nagłe wydanie bez nich, z projektu, który normalnie je posiada, to sygnał ostrzegawczy, który warto zautomatyzować.
- Połącz skanowanie luk w zabezpieczeniach z wykrywaniem złośliwego oprogramowania. Zachowaj skaner luk w zabezpieczeniach npm, aby wykrywać znane błędy i dodaj funkcję wykrywania analizującą, co tak naprawdę robią nowe pakiety.
Piąty nawyk to ten, którego większość zespołów nie zauważa, a to właśnie on został ujawniony przez atak Axios.
Wykryj złośliwy pakiet zanim będzie miał nazwę
Xygeni'ego Wczesne ostrzeganie przed złośliwym oprogramowaniem (MEW) Skanuje nowe pakiety w rejestrach publicznych, w tym npm, zaraz po ich opublikowaniu i analizuje zachowanie ich kodu, zamiast czekać na znany podpis. Gdy pakiet zostanie oznaczony, użytkownicy, których to dotyczy, są powiadamiani za pośrednictwem poczty e-mail, platform komunikatorów lub internetu.hooks, a pakiet jest poddany kwarantannie, więc możesz to zatrzymać w swoim CI/CD guardrails.
Wokół niego, Xygeni'ego open source security Wychwytuje pozostałe zagrożenia, na których opierają się cztery powyższe ścieżki ataku: typosquatting, pomyłki w zależnościach, podejrzane skrypty instalacyjne i nieograniczone wewnętrzne komponenty npm. Obejmuje również znane luki w zabezpieczeniach z komunikatów NVD, OSV i GitHub, priorytetyzowane według dostępności, dzięki czemu naprawiasz to, co faktycznie jest podatne na atak, z automatycznym pull requests w celu wprowadzenia poprawek.
Usługa MEW jest zawarta w bezpłatnym planie Developer. Zacznij za darmo i przeskanuj swoje pierwsze projekty npm w ciągu kilku minut.
FAQ
Czym jest bezpieczeństwo łańcucha dostaw npm?
Bezpieczeństwo łańcucha dostaw NPM obejmuje wszystkie zagrożenia związane z pakietami, od których zależą Twoje projekty JavaScript: znane luki w zabezpieczeniach, złośliwe pakiety, przejęte konta administratorów, typosquatting i pomyłki w zależnościach. Wykracza poza skanowanie luk w zabezpieczeniach, aby zweryfikować, czy instalowane pliki są legalne.
Czy skaner luk w zabezpieczeniach npm wykrywa złośliwe oprogramowanie?
Zazwyczaj nie. Tradycyjny skaner luk w zabezpieczeniach npm sprawdza pakiety w bazach danych znanych luk. Nowo opublikowany złośliwy pakiet nie ma wpisu w bazie danych, więc przechodzi, chyba że narzędzie analizuje również zachowanie pakietu.
Is npm audit wystarczająco?
npm audit To użyteczna, darmowa baza danych dla znanych luk w zabezpieczeniach. Nie wykrywa nowo opublikowanego złośliwego oprogramowania, typosquatów ani pomyłek w zależnościach i nie informuje, czy podatna na ataki funkcja jest rzeczywiście dostępna z poziomu kodu.
Jak mogę sprawdzić, czy pakiet jest złośliwy?
Sygnałami ostrzegawczymi są m.in. skrypty instalacyjne pobierające lub wykonujące zdalny kod, zaciemniony kod, wywołania sieciowe niezwiązane z przeznaczeniem pakietu, nowa zależność, do której nigdy nie odwołuje się repozytorium źródłowe, oraz wydanie bez pochodzenia, które projekt zwykle publikuje.
