GitHub wprowadził w npm dwa istotne mechanizmy bezpieczeństwa: staged publishing, czyli publikowanie pakietów z obowiązkowym zatwierdzeniem przez człowieka i 2FA, oraz nowe flagi instalacyjne ograniczające źródła, z których npm może pobierać zależności. Zmiana jest dostępna od npm CLI 11.15.0 i bezpośrednio odpowiada na rosnące ryzyko ataków na łańcuch dostaw oprogramowania.

W praktyce npm przestaje traktować publikację pakietu jako prostą operację techniczną. Coraz wyraźniej staje się ona kontrolowanym procesem bezpieczeństwa, w którym znaczenie mają tożsamość maintainera, pochodzenie artefaktu, konfiguracja CI/CD oraz ograniczenie niejawnych ścieżek instalacji zależności.

Problem: pakiet npm jako wygodny kanał dystrybucji ataku.

Ekosystem npm jest jednym z najważniejszych elementów współczesnego web developmentu. To jednocześnie ogromna powierzchnia ataku. Wystarczy przejęcie konta maintainer’a, tokena publikacyjnego, workflow CI/CD albo popularnego pakietu, aby złośliwy kod trafił nie do jednej aplikacji, ale do setek lub tysięcy projektów.

Ataki na open source rzadko przypominają już klasyczny scenariusz „podatność w bibliotece”. Coraz częściej chodzi o przejęcie procesu dostarczania oprogramowania: publikację złośliwej wersji, podmianę zależności, wykorzystanie postinstall scripts, złośliwe tarballe, zależności z GitHub URL, lokalne ścieżki albo ukryte elementy w pipeline. The Hacker News zwraca uwagę, że nowe mechanizmy npm pojawiają się w okresie zwiększonej aktywności grup atakujących ekosystemy open source.

Dlatego najważniejszy wniosek z tej zmiany jest prosty: bezpieczeństwo aplikacji nie kończy się na skanowaniu kodu. Coraz ważniejsze staje się zarządzanie tym, kto, skąd, jak i w jakim procesie publikuje oraz instaluje zależności.

Staged publishing: publikacja pakietu nie od razu trafia do rejestru.

Najważniejszą nowością jest staged publishing. Zamiast publikować pakiet bezpośrednio komendą npm publish, maintainer może użyć:

npm stage publish

Pakiet trafia wtedy do obszaru staging, a nie od razu do publicznego rejestru npm. Dopiero maintainer z uprawnieniami publikacji musi go sprawdzić i zatwierdzić przy użyciu 2FA. npm opisuje ten proces jako trzyetapowy: staging pakietu, review oraz approval.

To pozornie niewielka zmiana, ale z punktu widzenia bezpieczeństwa jest bardzo istotna. Dotychczas zautomatyzowany workflow mógł opublikować pakiet natychmiast po spełnieniu warunków pipeline. Teraz organizacja może wymusić dodatkową kontrolę człowieka, zanim artefakt stanie się dostępny dla całego ekosystemu.

Staged publishing wymaga npm CLI 11.15.0 lub nowszego, Node.js 22.14.0 lub nowszego, istniejącego już pakietu w rejestrze npm, włączonego 2FA oraz uprawnień publikacji do danego pakietu. Nie można więc użyć tego mechanizmu do pierwszej publikacji zupełnie nowego pakietu.

„Proof of presence” zamiast ślepego zaufania do automatyzacji.

Najciekawszym elementem tej zmiany jest nie sama komenda, ale model kontroli. GitHub określa staged publishing jako sposób na zapewnienie „proof of presence” przy każdej publikacji. Oznacza to, że nawet jeżeli build i przygotowanie paczki odbywa się automatycznie, finalne dopuszczenie wersji do publicznego rejestru wymaga świadomej akcji maintainera oraz przejścia 2FA.

To ważne, bo wiele incydentów supply chain zaczyna się nie od błędu w kodzie, ale od przejęcia elementu automatyzacji. Token w CI/CD, zbyt szerokie uprawnienia workflow, zapisany sekret, kompromitacja konta lub automatyczna publikacja po tagu mogą wystarczyć, aby złośliwa wersja trafiła do użytkowników.

Staged publishing nie eliminuje całego ryzyka, ale wprowadza punkt kontrolny dokładnie tam, gdzie ryzyko jest największe: pomiędzy wygenerowaniem artefaktu a jego publiczną dystrybucją.

Najlepszy model: staged publishing razem z OIDC.

npm rekomenduje łączenie staged publishing z trusted publishing, czyli publikowaniem opartym o OpenID Connect. Trusted publishing pozwala publikować pakiety z CI/CD bez długowiecznych tokenów npm. Zamiast stałego sekretu w pipeline wykorzystywany jest krótkotrwały, kryptograficznie podpisany token powiązany z konkretnym workflow.

To istotne, ponieważ klasyczne tokeny publikacyjne są jednym z typowych słabych punktów w łańcuchu dostaw. Mogą zostać przypadkowo ujawnione w logach, skopiowane do złego środowiska, pozostawione po odejściu pracownika albo przejęte po kompromitacji repozytorium. Trusted publishing redukuje ten problem, bo zamiast „sekretu przechowywanego gdzieś w CI” mamy relację zaufania między npm a konkretnym dostawcą CI/CD.

npm wspiera trusted publishing m.in. dla GitHub Actions, GitLab CI/CD Pipelines i CircleCI. Dokumentacja wskazuje też, że self-hosted runners nie są obecnie obsługiwane, choć są planowane w przyszłości.

Dla organizacji najbezpieczniejszy model wygląda więc następująco: CI/CD buduje pakiet, uwierzytelnia się przez OIDC, wysyła artefakt do stagingu, a maintainer zatwierdza finalną publikację z 2FA. To rozdziela automatyzację techniczną od decyzji o publicznym wydaniu.

Nowe flagi instalacyjne: kontrola źródeł zależności.

Drugą istotną zmianą są nowe flagi --allow-*, które pozwalają ograniczać instalację zależności spoza standardowego rejestru npm. Od npm CLI 11.15.0 dostępne są:

Każda z tych opcji może ograniczyć źródło zależności do wartości all, none albo root. Dokumentacja npm wskazuje, że zmiana tych ustawień może spowodować niekompletne drzewo zależności, ale jednocześnie daje zespołom możliwość świadomego blokowania niepożądanych źródeł instalacji.

To bardzo ważne w praktyce. W wielu projektach zależności nie pochodzą wyłącznie z rejestru npm. W package.jsonmożna spotkać odwołania do repozytoriów Git, lokalnych katalogów, tarballi, forków lub zewnętrznych URL. Czasami jest to uzasadnione, ale czasami tworzy niekontrolowaną ścieżkę pobierania kodu.

Nowe flagi pozwalają wprowadzić zasadę: zależności mają pochodzić z przewidywalnych, kontrolowanych źródeł, a wyjątki muszą być świadome i jawne.

Co to oznacza dla zespołów DevOps i bezpieczeństwa?

Dla zespołów utrzymujących aplikacje Node.js ta zmiana powinna być sygnałem do przeglądu własnego procesu release i dependency management. Sam fakt, że npm dodaje takie mechanizmy, pokazuje kierunek, w którym idzie bezpieczeństwo open source: mniej niejawnego zaufania, więcej kontroli tożsamości, pochodzenia artefaktów i konfiguracji pipeline.

W praktyce warto sprawdzić:

Warto też odróżnić dwa poziomy ochrony. Pierwszy dotyczy organizacji publikujących własne pakiety. Tam staged publishing, 2FA i OIDC powinny stać się elementem standardowego procesu release. Drugi dotyczy organizacji, które tylko konsumują pakiety npm. Tam kluczowe są restrykcje instalacyjne, lockfile, skanowanie zależności, kontrola zmian w package.json i ograniczanie zewnętrznych źródeł.

To nie zastępuje skanowania podatności.

Nowe mechanizmy npm nie są zamiennikiem dla npm audit, SCA, SBOM, skanowania kontenerów czy polityk bezpieczeństwa repozytoriów. Rozwiązują inny problem: zmniejszają ryzyko, że złośliwy lub nieautoryzowany pakiet zostanie opublikowany albo zainstalowany przez niekontrolowaną ścieżkę.

To istotna różnica. Skaner podatności może wykryć znane CVE, ale nie zawsze wykryje świeżo opublikowaną, złośliwą wersję pakietu, która wygląda jak normalna aktualizacja. Podobnie SBOM pokaże, co znajduje się w aplikacji, ale nie zatrzyma automatycznej publikacji pakietu po przejęciu workflow. Dlatego bezpieczeństwo software supply chain wymaga warstw: kontroli tożsamości, kontroli publikacji, kontroli źródeł instalacji, analizy zależności i monitorowania zmian.

Wnioski.

Zmiany w npm pokazują, że bezpieczeństwo open source przesuwa się z modelu reaktywnego do modelu kontrolnego. Nie chodzi już tylko o pytanie, czy biblioteka ma znaną podatność. Coraz ważniejsze są pytania: kto może opublikować pakiet, czy ta publikacja została zatwierdzona, czy pochodzi z zaufanego workflow, czy wymaga 2FA oraz czy aplikacja może instalować kod z niekontrolowanych źródeł. Dla organizacji korzystających z Node.js i npm jest to dobry moment, aby potraktować dependency management jako część governance, a nie wyłącznie techniczny detal projektu. W praktyce oznacza to przegląd kont, tokenów, CI/CD, plików .npmrc, lockfile i wyjątków w package.json.

Supply chain security zaczyna się od prostego założenia: zależność nie jest tylko biblioteką. Jest elementem zaufania, który trafia do aplikacji, środowiska build, kontenera, serwera i ostatecznie do użytkownika końcowego. Nowe mechanizmy npm pomagają to zaufanie lepiej kontrolować — ale tylko wtedy, gdy zespoły faktycznie włączą je do swoich procesów.