Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
GitHub zapowiedział istotne zmiany w npm 12, które mają ograniczyć jeden z najczęściej wykorzystywanych wektorów ataku w ekosystemie Node.js. Chodzi o automatyczne uruchamianie skryptów instalacyjnych podczas wykonywania polecenia npm install. W nowym modelu mechanizm ten nie będzie już aktywny domyślnie, lecz stanie się funkcją wymagającą jawnej zgody zespołu.
To ważna zmiana dla bezpieczeństwa łańcucha dostaw oprogramowania, ponieważ instalacja zależności od lat była nie tylko procesem pobierania pakietów, ale również potencjalnym momentem wykonania niezweryfikowanego kodu.
W skrócie
W npm 12 skrypty preinstall, install i postinstall pochodzące z zależności mają być domyślnie blokowane, dopóki nie zostaną wyraźnie zatwierdzone. Równolegle ograniczone zostanie pobieranie zależności z repozytoriów Git oraz zdalnych adresów URL spoza rejestru, chyba że użytkownik jawnie dopuści takie źródła.
- domyślne wyłączenie skryptów instalacyjnych zależności,
- blokada zależności pobieranych z Git bez zgody użytkownika,
- blokada pakietów z nierejestrowych zdalnych źródeł,
- ostrzeżenia dostępne już w npm 11.16.0 i nowszych,
- premiera npm 12 planowana na lipiec 2026 roku.
Kontekst / historia
Ekosystem npm odgrywa kluczową rolę w nowoczesnym wytwarzaniu oprogramowania, ale jednocześnie od dawna pozostaje atrakcyjnym celem dla cyberprzestępców. Model zależności tranzytywnych sprawia, że nawet pojedynczy skompromitowany pakiet osadzony głęboko w drzewie zależności może doprowadzić do wykonania kodu na stacji roboczej dewelopera lub w środowisku CI/CD.
Szczególnie problematyczne są skrypty cyklu życia pakietów uruchamiane podczas instalacji. W praktyce umożliwiało to złośliwym pakietom lub przejętym kontom maintainerów wykonywanie działań takich jak kradzież tokenów, wyciek zmiennych środowiskowych, pobieranie malware czy nadużycia w pipeline’ach budowania.
Zapowiedziane zmiany wpisują się w szerszy trend zaostrzania polityk bezpieczeństwa wokół źródeł pakietów i domyślnych zachowań instalatorów. Coraz większy nacisk kładziony jest na przewidywalność, jawne zaufanie i ograniczanie automatycznego wykonywania kodu.
Analiza techniczna
Najważniejsza zmiana polega na tym, że mechanizm allowScripts ma być domyślnie wyłączony. Oznacza to, że npm install nie uruchomi już automatycznie skryptów preinstall, install ani postinstall pochodzących z zależności, dopóki nie zostaną one jawnie dopuszczone w projekcie.
Zmiana obejmuje również scenariusze związane z natywnymi modułami korzystającymi z node-gyp. Nawet jeśli pakiet nie definiuje własnego skryptu instalacyjnego, wcześniejsze zachowanie mogło prowadzić do niejawnego uruchomienia procesu przebudowy, co także zwiększało powierzchnię ataku.
Drugim istotnym elementem jest zaostrzenie zasad dla źródeł zależności. Flaga --allow-git ma domyślnie przyjmować wartość blokującą, przez co instalator nie będzie rozwiązywał zależności z repozytoriów Git bez wyraźnego zezwolenia. Podobnie flaga --allow-remote ma blokować pobieranie pakietów z nierejestrowych, zdalnych źródeł, takich jak archiwa dostępne przez HTTPS.
Aby ułatwić migrację, nowsze wydania npm 11 już teraz prezentują ostrzeżenia o zachowaniach, które po przejściu na npm 12 zostaną zablokowane. Zespoły mogą wykorzystać polecenia służące do identyfikacji i zatwierdzania pakietów wymagających skryptów instalacyjnych oraz do budowy listy wyjątków zapisanej w konfiguracji projektu.
Konsekwencje / ryzyko
Z perspektywy bezpieczeństwa to jedna z ważniejszych zmian w npm od lat. Automatyczne wykonywanie skryptów instalacyjnych było jednym z najpoważniejszych wektorów zdalnego wykonania kodu w narzędziach deweloperskich opartych na JavaScript. Ograniczenie tego mechanizmu do modelu jawnej zgody znacząco utrudni nadużycia.
Jednocześnie zmiana może wywołać skutki operacyjne. Wiele legalnych pakietów wykorzystuje skrypty instalacyjne do kompilacji modułów natywnych, przygotowania binariów, generowania zasobów lub konfiguracji środowiska. Po wdrożeniu npm 12 część takich zależności może przestać działać bez wcześniejszego zatwierdzenia.
W praktyce oznacza to ryzyko błędów kompilacji, nieudanych wdrożeń, niepełnych instalacji zależności oraz przestojów w procesach developerskich i CI/CD. Organizacje, które nie przygotują się odpowiednio wcześniej, mogą odczuć skutki tej zmiany nie tylko w obszarze bezpieczeństwa, ale również ciągłości działania.
Rekomendacje
Zespoły bezpieczeństwa, DevOps i deweloperskie powinny potraktować npm 12 jako zmianę wymagającą planowanej migracji. Nie jest to zwykła aktualizacja narzędzia, lecz modyfikacja domyślnego modelu zaufania w całym procesie instalacji pakietów.
- zaktualizować środowiska testowe do npm 11.16.0 lub nowszego i przeanalizować ostrzeżenia,
- zinwentaryzować pakiety wymagające skryptów instalacyjnych,
- zatwierdzać wyłącznie te zależności, które są rzeczywiście niezbędne,
- ograniczyć użycie zależności z Git oraz zdalnych URL-i spoza rejestru,
- testować pipeline’y CI/CD z nowymi ustawieniami domyślnymi,
- monitorować zmiany w
package.jsoni plikach lock pod kątem nowych wyjątków, - objąć szczególną kontrolą pakiety natywne zależne od
node-gyp.
Dodatkową dobrą praktyką będzie połączenie tych działań z analizą SBOM, ochroną sekretów w runnerach oraz oceną reputacji i pochodzenia kluczowych pakietów.
Podsumowanie
GitHub wprowadza w npm 12 istotne wzmocnienie bezpieczeństwa łańcucha dostaw oprogramowania w ekosystemie Node.js. Domyślne wyłączenie skryptów instalacyjnych oraz blokada zależności z Git i zdalnych źródeł bez jawnej zgody ograniczają ryzyko automatycznego wykonania złośliwego kodu podczas instalacji.
To krok w stronę bardziej defensywnego i przewidywalnego modelu zarządzania pakietami. Jednocześnie firmy i zespoły deweloperskie powinny odpowiednio wcześnie przeprowadzić przegląd zależności oraz procesów buildowych, aby uniknąć problemów kompatybilności po premierze npm 12.
Źródła
- https://thehackernews.com/2026/06/github-to-disable-npm-install-scripts.html
- https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/
- https://github.com/orgs/community/discussions/198547