npm wyłącza to, co napędzało każdy atak na łańcuch dostaw, który opisywaliśmy. Cena: części buildów przestanie działać – i to jest zamierzone.

9 czerwca GitHub ogłosił, że npm w wersji 12 — planowanej na lipiec — domyślnie wyłączy automatyczne wykonywanie skryptów instalacyjnych. Polecenie npm install przestanie uruchamiać skrypty preinstall, install i postinstall z zależności, dopóki deweloper jawnie ich nie zatwierdzi. GitHub nazywa to wprost „breaking changes" — zmianami łamiącymi kompatybilność. I to jest najważniejsze w tej historii: psucie kompatybilności jest tu zamierzone, nie ubocznie.

Dla cyberflux to jest temat domykający. Przez ostatnie tygodnie opisywaliśmy atak za atakiem, które wszystkie używały dokładnie tego mechanizmu, który npm 12 teraz zamyka. To nie jest kolejny incydent — to jest strukturalna odpowiedź na serię incydentów, którą śledziliśmy.

Mechanizm, który napędzał wszystko

Żeby zrozumieć wagę tej zmiany, trzeba zobaczyć, co dokładnie znikają.

Skrypty cyklu życia npm — preinstall, install, postinstall — to fragmenty kodu, które pakiet może uruchomić automatycznie w momencie instalacji. GitHub opisuje je jako „największą pojedynczą powierzchnię wykonania kodu w ekosystemie npm". Powód jest w jednym zdaniu: polecenie npm install uruchamia skrypty z każdej tranzytywnej zależności, więc jeden skompromitowany pakiet gdziekolwiek w drzewie zależności może wykonać dowolny kod na maszynie dewelopera lub w runnerze CI.

To jest dokładnie ten wektor, który widzieliśmy w niemal każdym ataku supply chain z ostatnich tygodni. Miasma wstrzykiwała 4,1 MB zaciemnionego JavaScriptu jako hook preinstall — odpalający się, zanim jakikolwiek kod aplikacji został uruchomiony. Shai-Hulud, Glassworm, cała seria TeamPCP — wszystkie opierały się na tym, że instalacja pakietu automatycznie uruchamia jego kod. SOCFortress nazywa to „efektem motyla": podatność w niejasnym narzędziu cztery poziomy w głąb drzewa zależności może doprowadzić do pełnej kompromitacji systemu.

W npm 12 nowa konfiguracja allowScripts jest domyślnie ustawiona na „off". Skrypt nie uruchomi się, dopóki deweloper go jawnie nie zatwierdzi. To odwraca model zaufania: z „uruchom wszystko, chyba że zabronisz" na „nie uruchamiaj nic, dopóki nie pozwolisz".

To zamyka więcej niż jeden wektor

GitHub nie zatrzymał się na skryptach cyklu życia. Pakiet zmian zamyka kilka ścieżek wykonania kodu naraz — i warto je wymienić, bo pokazują, że to przemyślana operacja, nie pojedyncza łatka.

allowScripts domyślnie off — blokuje preinstall/install/postinstall, w tym natywne buildy node-gyp. Pakiet z plikiem binding.gyp bez jawnego skryptu instalacyjnego też zostanie zablokowany, bo npm uruchamia dla niego niejawny node-gyp rebuild. Skrypty prepare z zależności git, file i link są blokowane tak samo.

--allow-git domyślnie none — npm przestanie rozwiązywać zależności git, dopóki nie zostaną jawnie dozwolone. To zamyka ścieżkę wykonania kodu, w której plik .npmrc zależności git mógł nadpisać sam plik wykonywalny Git — działającą nawet przy fladze --ignore-scripts. To istotny szczegół: stara flaga --ignore-scripts, której używali ostrożni deweloperzy, nie chroniła przed tym wektorem. npm 12 zamyka lukę, której obejście dotąd nie łapało.

--allow-remote domyślnie none — npm przestanie rozwiązywać zależności ze zdalnych URL-i, takich jak tarbally https, dopóki nie zostaną jawnie dozwolone.

Wszystkie te zmiany są już dostępne za ostrzeżeniami w npm 11.16.0 — można się przygotować przed wymuszeniem ich w wersji 12.

Dlaczego „breaking changes" są tu zaletą, nie wadą

Tu jest punkt, który czyni tę zmianę godną osobnego wpisu, a nie notki.

GitHub świadomie wybiera złamanie kompatybilności. Część narzędzi enterprise, potoków CI i monorepo napotka nieoczekiwane awarie, gdy npm 12 wejdzie — i GitHub o tym wie, mówi to wprost, i robi to mimo wszystko. To jest rzadka decyzja: firma, która przejęła npm, stawia bezpieczeństwo ponad wygodę w sposób, który zaboli jej własnych użytkowników.

Przez lata domyślne ustawienia npm były optymalizowane pod wygodę — zainstaluj wszystko, uruchom wszystko, buduj szybko. Fala ataków na łańcuch dostaw z ostatnich lat uczyniła tę filozofię nie do utrzymania. To jest dokładnie ta zmiana myślenia, którą opisywaliśmy w Radarze jako przejście od „łańcuch dostaw to wektor" do „łańcuch dostaw to infrastruktura". Skoro łańcuch dostaw jest infrastrukturą, na której rozgrywają się ataki, to trzeba zmienić fundament tej infrastruktury — a nie łatać kolejne pakiety pojedynczo.

To jest też część szerszego wzorca z tego tygodnia. VS Code wprowadził dwugodzinne opóźnienie auto-aktualizacji rozszerzeń, żeby ograniczyć okno, w którym skompromitowane wydanie może się rozejść. Oba ruchy — npm i VS Code — to producenci narzędzi deweloperskich, którzy zmieniają domyślne ustawienia z „ufaj automatycznie" na „weryfikuj, zanim zaufasz". To jest reakcja ekosystemu na to, co opisywaliśmy incydent po incydencie.

Pułapka, której trzeba uniknąć

Jest tu jednak haczyk, który warto nazwać wprost, bo inaczej cała zmiana pójdzie na marne.

GitHub daje narzędzie npm approve-scripts do przeglądania, które pakiety mają skrypty, zatwierdzania tych zaufanych i zapisania decyzji. Ale — jak ostrzega AI Weekly — zespoły, które zareagują masowym zatwierdzeniem wszystkich skryptów przez approve-scripts, eliminują korzyść bezpieczeństwa całkowicie i pozostają wystawione na te same ataki, którym zmiana miała zapobiec.

To jest ta sama dynamika, którą opisywaliśmy przy zmęczeniu alertami i przy zgodach klikanych bez czytania. Mechanizm bezpieczeństwa, który wymaga decyzji, jest tak dobry, jak uważność osoby, która tę decyzję podejmuje. „Zatwierdź wszystko, żeby build przeszedł" to nie jest bezpieczeństwo — to jest stary model zaufania z dodatkowym krokiem. Wartość pojawia się tylko wtedy, gdy zespół faktycznie przegląda, które pakiety potrzebują skryptów, i zatwierdza świadomie.

Jest też realny koszt operacyjny. Potoki CI i zautomatyzowane wdrożenia, które wywołują npm install nieinteraktywnie, nie mogą poprosić o zatwierdzenie w trakcie — będą wymagać nowej konfiguracji na poziomie pipeline, albo buildy zaczną się wywalać po wejściu wersji 12. Zespoły, które dziś nie przygotują listy zatwierdzonych skryptów, w lipcu obudzą się ze zepsutymi buildami.

Ale jest w tym też wartość, której nie widać od razu: model approve-scripts tworzy audytowalny zapis tego, którym skryptom organizacja zaufała. Dla firm, które muszą wykazać nadzór nad łańcuchem dostaw audytorom albo klientom enterprise, to jest dokładnie ten rodzaj dowodu, którego crosswalk AIUC-1 i raport OWASP wymagają jako element governance. Z wymuszonej niewygody powstaje ślad zgodności.

Co zrobić — i to przed lipcem

Zaktualizuj do npm 11.16.0 lub nowszej już teraz. Wszystkie zmiany v12 są tam dostępne za ostrzeżeniami — możesz zobaczyć, co się zepsuje, zanim się zepsuje na produkcji.

Uruchom normalną instalację i przejrzyj ostrzeżenia. Użyj npm approve-scripts --allow-scripts-pending, żeby zobaczyć, które pakiety mają skrypty. Zatwierdź te, którym ufasz i które są naprawdę potrzebne — i commituj zaktualizowany package.json. To jest moment na świadomy audyt, nie na masowe „pozwól wszystko".

Przygotuj potoki CI osobno. Buildy nieinteraktywne nie poproszą o zatwierdzenie — potrzebują konfiguracji listy dozwolonych skryptów na poziomie pipeline, zanim npm 12 wejdzie w lipcu. Zrób to teraz, nie w dniu, w którym buildy przestaną przechodzić.

Potraktuj listę zatwierdzonych skryptów jako żywy dokument bezpieczeństwa. Każdy pakiet, który wymaga skryptu instalacyjnego, to pakiet, który może wykonać kod na twojej maszynie — przeglądaj tę listę przy każdej większej zmianie zależności, tak samo jak przeglądasz uprawnienia.

Źródła

GitHub Changelog — oficjalne ogłoszenie zmian w npm v12 z pełną listą nowych domyślnych ustawień: https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/

The Hacker News — kontekst „największej powierzchni wykonania kodu" i mechanizm tranzytywnych zależności: https://thehackernews.com/2026/06/github-to-disable-npm-install-scripts.html

SecurityWeek — szczegóły wpływu na buildy node-gyp i skrypty prepare: https://www.securityweek.com/npm-12-will-change-script-execution-behavior-to-prevent-supply-chain-attacks/

AI Weekly — analiza pułapki masowego zatwierdzania i kosztu dla potoków CI: https://aiweekly.co/alerts/github-npm-v12-disables-dependency-scripts-by-default

SOCFortress — analiza techniczna zamykanych luk i obejścia flagi --ignore-scripts: https://socfortress.medium.com/github-to-disable-default-npm-install-scripts-in-version-12-3fd61634588d