Zabezpieczenie łańcucha dostaw npm: biblioteki i narzędzia do wykrywania podatności w dependencies

W projekcie JavaScript podatność nie musi znajdować się w kodzie napisanym przez zespół. Może zostać wprowadzona przez małą bibliotekę używaną tylko przez narzędzie testowe, bundler albo logger. Jeszcze trudniejszy przypadek to zależność przechodnia, której nazwa nie występuje bezpośrednio w package.json, ale która trafia do obrazu kontenera i środowiska produkcyjnego przez kilka kolejnych poziomów zależności.

Zabezpieczenie łańcucha dostaw npm wymaga więc czegoś więcej niż jednorazowego uruchomienia npm audit. Potrzebne są równocześnie: kontrola źródeł pakietów, analiza drzewa dependencies, wykrywanie znanych podatności, obserwacja zmian w paczkach, generowanie SBOM, blokowanie ryzykownych aktualizacji oraz procedura reakcji na alert. Dobór narzędzia SCA powinien wynikać z charakteru projektu, sposobu budowania aplikacji i dojrzałości procesu CI/CD, a nie wyłącznie z popularności konkretnej usługi. ^[4]

Anatomia podatności w ekosystemie npm: punkty krytyczne łańcucha dostaw

Główne wektory zagrożeń: od typosquattingu po przejęcie kont maintainerów

Łańcuch dostaw npm obejmuje znacznie więcej elementów niż sam rejestr pakietów. W jego skład wchodzą autorzy bibliotek, konta maintainerów, system publikowania wydań, zależności bezpośrednie i przechodnie, skrypty instalacyjne, serwer CI, cache pakietów, obrazy kontenerów oraz wszystkie osoby i procesy mające możliwość zmiany kodu przed wdrożeniem.

Jednym z najprostszych ataków jest typosquatting, czyli publikowanie pakietu o nazwie podobnej do popularnej biblioteki. Różnica może polegać na jednej literze, myślniku, dodatkowym sufiksie albo zamianie kolejności słów. Programista może zainstalować złośliwy pakiet po błędzie w nazwie, nieaktualnej instrukcji lub automatycznym uzupełnianiu w edytorze. Taki pakiet często zawiera kod kradnący zmienne środowiskowe, tokeny CI albo dane zapisane w katalogu użytkownika.

Inny scenariusz to przejęcie konta maintenera. Atakujący nie musi publikować nowej biblioteki pod własną nazwą. Wystarczy, że uzyska dostęp do konta właściciela popularnego pakietu i opublikuje wersję zawierającą dodatkowy kod. Niebezpieczne może być także przejęcie domeny projektu, repozytorium albo tokena publikacyjnego. Sygnał ostrzegawczy stanowi nagła zmiana właściciela, nieoczekiwana modyfikacja procesu wydawniczego, nowe konto publikujące paczkę lub wydanie pozbawione typowych plików i metadanych.

Ryzyko wiąże się również z podatnością w legalnej, znanej bibliotece. W takim przypadku pakiet nie jest złośliwy, lecz posiada błąd pozwalający na wykonanie kodu, obejście autoryzacji, odczyt danych, zatrzymanie procesu albo manipulację zapytaniami. Narzędzia SCA są szczególnie przydatne właśnie przy takich problemach, ponieważ porównują wersje komponentów z bazami opublikowanych podatności.

Zależności przechodnie jako ukryty wektor ryzyka

Wpis w rodzaju "express": "^4.18.2" nie opisuje całego kodu, który zostanie zainstalowany. Express ma własne zależności, te zależności mogą mieć kolejne zależności, a każda z nich może zmienić się w wyniku rozwiązania zakresu semantycznego wersji. Dlatego ocena bezpieczeństwa wyłącznie na podstawie listy dependencies z package.json jest niepełna. ^[3]

To właśnie zależności przechodnie często odpowiadają za alerty pojawiające się po aktualizacji pozornie niezwiązanej z funkcją biznesową. Biblioteka do obsługi dat, formatowania logów czy kompilacji TypeScript może wciągnąć komponent podatny na ReDoS, przechodzenie przez katalogi, prototype pollution albo wykonywanie niebezpiecznych wyrażeń. W aplikacji backendowej ryzyko będzie inne niż w bibliotece uruchamianej wyłącznie podczas budowania frontendu, ale sam fakt obecności komponentu powinien zostać zarejestrowany i oceniony.

Kluczowym dokumentem jest lockfile. package-lock.json, pnpm-lock.yaml lub plik blokady używany przez Yarn zapisuje konkretny graf wersji, a często także integralność archiwum i adres pobrania. Bez lockfile’a dwa uruchomienia instalacji wykonane w różnym czasie mogą pobrać inny zestaw paczek mimo niezmienionego package.json. To utrudnia odtworzenie kompilacji, analizę incydentu i ustalenie, która wersja faktycznie trafiła do produkcji.

Punkty kontrolne audytu repozytorium

Audyt zależności powinien zacząć się od ustalenia, jaki menedżer pakietów jest źródłem prawdy. Obecność kilku lockfile’ów jednocześnie, na przykład package-lock.json i yarn.lock, jest sygnałem ostrzegawczym. Różne narzędzia mogą wtedy rozwiązywać graf odmiennie, a programista lokalnie może uruchamiać inną wersję zależności niż serwer CI.

Minimum kontroli obejmuje:

• wersję Node.js i menedżera pakietów zapisaną w projekcie lub obrazie CI,
• obecność dokładnie jednego używanego lockfile’a,
• instalację w trybie powtarzalnym, na przykład npm ci zamiast swobodnego npm install w pipeline,
• sprawdzenie źródeł registry i konfiguracji plików .npmrc,
• analizę skryptów preinstall, install, postinstall, prepare oraz skryptów wywoływanych przez narzędzia budujące,
• kontrolę zmian w lockfile’u podczas code review,
• ustalenie, czy zależności deweloperskie są obecne w obrazie produkcyjnym.

Skrypty instalacyjne zasługują na szczególną uwagę, ponieważ mogą uruchamiać kod jeszcze przed zakończeniem instalacji. Nie oznacza to, że każdy postinstall jest złośliwy. Pakiety natywne mogą korzystać z takich skryptów do kompilacji dodatków, a niektóre biblioteki pobierają binaria dla konkretnej platformy. Sygnałem ryzyka jest jednak skrypt, który wykonuje nieuzasadnione żądania sieciowe, odczytuje szeroki zestaw zmiennych środowiskowych, zapisuje pliki poza katalogiem projektu lub pobiera kod bez weryfikacji integralności.

Jak rozpoznać anomalie w paczce

Sam wynik skanera nie odpowie na pytanie, czy wydanie zostało naruszone. W przypadku podejrzenia kompromitacji trzeba porównać wersję poprzednią i obecną. Analizuje się między innymi zmianę maintainerów, historię publikacji, różnice w liczbie plików, nowe pliki wykonywalne, minifikowane fragmenty kodu, obfuskację, dodatkowe skrypty oraz komunikację z nieznanymi domenami.

Niepokojące są nagłe wydania patch bez zmian w repozytorium źródłowym, wersja opublikowana wiele miesięcy po ostatnim commicie, duży skok rozmiaru archiwum albo dodanie pliku uruchamianego przy instalacji. Trzeba też sprawdzić, czy paczka nie używa dynamicznych konstrukcji, takich jak eval, new Function, nietypowe dekodowanie Base64 i odczyt kluczy SSH, tokenów chmurowych czy plików konfiguracyjnych.

Jeśli zespół polega wyłącznie na deklaratywnych wersjach w package.json, bez stałego monitorowania drzewa zależności i lockfile’a, ryzyko przeoczenia luki rośnie wraz z każdym poziomem zagnieżdżenia. Jeśli repozytorium ma jeden kontrolowany lockfile, powtarzalną instalację i przegląd skryptów lifecycle, łatwiej odtworzyć stan projektu oraz odróżnić zwykłą aktualizację od potencjalnego naruszenia integralności.

Wariant 1: wbudowane mechanizmy npm, pnpm i Yarn

Mechanizm działania i źródła danych

Wbudowany audyt menedżera pakietów jest najniższym progiem wejścia do bezpieczeństwa npm. W przypadku npm podstawowe polecenie to npm audit, a instalację i audyt można połączyć przez npm install lub kontrolowany proces CI. Polecenie analizuje zainstalowane zależności i porównuje ich wersje z informacjami o znanych podatnościach udostępnianymi przez ekosystem rejestru oraz bazy advisory.

W praktyce komunikat obejmuje nazwę pakietu, zakres wersji podatnych, poziom ryzyka, ścieżkę zależności oraz sugerowaną wersję naprawioną, jeżeli taka istnieje. Opcja npm audit --json umożliwia przekazanie wyniku do dalszego przetwarzania. npm audit fix może zaktualizować część komponentów automatycznie, lecz nie powinien być uruchamiany bez kontroli zmian. Przy aktualizacji major może dojść do zmiany API albo zachowania aplikacji. ^[1]

W zależności od wersji i konfiguracji narzędzia dane mogą pochodzić z endpointów audytowych rejestru oraz źródeł advisory wykorzystywanych w ekosystemie npm. GitHub Advisory Database jest jednym z ważnych punktów odniesienia dla informacji o podatnościach open source, ale zespół powinien sprawdzić, jakie dokładnie źródło, synchronizacja i zakres są używane przez wybrane narzędzie. Nie każdy skaner oparty na tej samej bazie pokazuje identyczny wynik, ponieważ różnią się reguły dopasowania, priorytety i sposób oceny osiągalności kodu.

pnpm udostępnia podobne możliwości audytu, natomiast Yarn może wykorzystywać mechanizm audytowy zależny od wersji i konfiguracji. Wspólną cechą tych rozwiązań jest ścisłe powiązanie z menedżerem pakietów i lockfile’em. To zaleta w małym projekcie, ale też ograniczenie, gdy organizacja chce analizować wiele repozytoriów, generować raporty dla audytora lub łączyć wyniki z systemem zarządzania ryzykiem.

Zalety prostego audytu w codziennym workflow

Największą zaletą jest brak dodatkowego wdrożenia. Programista może uruchomić polecenie lokalnie, a zespół może dodać je do pipeline’u bez instalowania serwera, agenta lub osobnej platformy. To dobry wariant startowy dla biblioteki, prototypu, małej aplikacji wewnętrznej oraz projektu, który dopiero wprowadza podstawowe kontrole bezpieczeństwa.

Mechanizm działa blisko miejsca, w którym powstaje problem. Jeżeli nowa zależność trafia do lockfile’a, audyt może zostać wykonany w tym samym pull requeście. Przy odpowiednim ustawieniu kod wyjścia procesu zablokuje kompilację, gdy pojawi się podatność o określonym poziomie. Prosty przykład kontroli w CI może wyglądać następująco: ^[2]

npm ci
npm audit --audit-level=high
npm test

Takie ustawienie nie powinno być traktowane jako kompletna polityka bezpieczeństwa. Jest punktem kontrolnym, który wykrywa część znanych problemów w konkretnym momencie. Dodatkowy harmonogram, uruchamiany nawet bez zmian w repozytorium, jest potrzebny dlatego, że baza podatności zmienia się niezależnie od kodu aplikacji.

Ograniczenia: szum informacyjny i brak analizy kontekstowej

Wbudowany audyt nie zawsze rozumie, czy podatny fragment jest osiągalny w konkretnej konfiguracji aplikacji. Może zgłosić problem w zależności używanej tylko w narzędziach deweloperskich albo w module, którego ścieżka nie występuje w finalnym bundlu. Z drugiej strony samo usunięcie pakietu z frontendu nie musi rozwiązać problemu, jeśli ta sama zależność pozostaje w obrazie serwera lub skrypcie uruchamianym w CI.

Warto przeczytać również powiązany artykuł: Bezpieczne UI w przeglądarce: biblioteki do walidacji, sanitizacji i kontroli danych.

Drugim ograniczeniem jest presja związana z fałszywymi alarmami i brakiem priorytetyzacji biznesowej. Setki ostrzeżeń bez informacji o ekspozycji, dostępności endpointu i rodzaju danych szybko prowadzą do ignorowania komunikatów. Zespół może wtedy używać wyjątków lub flag wyciszających bez terminu ponownej oceny. Wyjątek bez właściciela, uzasadnienia i daty wygaśnięcia staje się trwałą luką procesową.

Wariant 2: skanery SCA i usługi monitorujące zależności

Drugi wariant zakłada użycie narzędzia klasy SCA (Software Composition Analysis), które analizuje zależności projektu szerzej niż pojedyncze polecenie menedżera pakietów. Przykładami takich rozwiązań są platformy Snyk, GitHub Dependabot, Mend lub komercyjne systemy zintegrowane z repozytorium i pipeline’em. Dokładny zakres funkcji zależy od produktu, planu oraz sposobu podłączenia repozytorium.

Skaner może pobierać informacje z package.json, lockfile’a, obrazu kontenera albo wygenerowanego SBOM. Następnie łączy wykryte komponenty z bazą advisory, śledzi nowe informacje o podatnościach i tworzy alerty niezależnie od tego, czy ktoś właśnie zmienił kod. W praktyce jest to ważne, ponieważ podatność może zostać opublikowana długo po wdrożeniu konkretnej wersji aplikacji.

Co odróżnia SCA od prostego audytu

Platformy SCA zwykle oferują centralny widok zależności z wielu repozytoriów, historię alertów, przypisywanie właścicieli oraz reguły ignorowania problemów. Mogą też analizować pull requesty i proponować aktualizację konkretnej paczki. Dzięki temu wynik nie kończy się na komunikacie w terminalu, lecz trafia do procesu obsługi podatności.

Nie należy jednak zakładać, że każda platforma automatycznie rozstrzygnie, czy podatny kod jest osiągalny. Jedne narzędzia lepiej oceniają ścieżkę użycia, inne skupiają się na obecności komponentu i wersji. Przed wdrożeniem trzeba sprawdzić, czy skaner rozróżnia dependencies produkcyjne i deweloperskie, analizuje zależności przechodnie oraz obsługuje sposób budowania konkretnej aplikacji.

Zalety i ograniczenia wariantu SCA

• Zalety: centralny raport dla wielu projektów, alerty po zmianie bazy advisory, integracja z pull requestami, możliwość przypisywania właścicieli oraz śledzenie wyjątków.
• Zalety: lepsze wsparcie dla procesu triage, gdy organizacja musi obsługiwać dużą liczbę repozytoriów.
• Ograniczenia: dodatkowa konfiguracja, koszty lub zależność od zewnętrznej usługi.
• Ograniczenia: ryzyko nadmiaru alertów, jeżeli reguły nie uwzględniają środowiska uruchomieniowego i faktycznej ekspozycji komponentu.
• Ograniczenia: konieczność sprawdzenia, jakie dane o kodzie, nazwach repozytoriów i zależnościach są przekazywane do dostawcy.

Ten wariant ma sens dla zespołu, który utrzymuje wiele aplikacji, potrzebuje raportowania dla audytu lub nie chce budować własnego procesu na podstawie surowego wyniku npm audit --json. W małym projekcie może być natomiast zbyt rozbudowany, jeśli nie ma osoby odpowiedzialnej za przegląd i zamykanie alertów.

Wariant 3: skaner CLI oparty na niezależnej bazie advisory

Alternatywą dla platformy SCA jest osobny skaner uruchamiany lokalnie lub w CI. Przykładem może być OSV-Scanner, który korzysta z bazy OSV i analizuje między innymi manifesty, lockfile’e oraz inne formaty zależności obsługiwane przez narzędzie. W tym modelu zespół zachowuje większą kontrolę nad miejscem wykonywania analizy i może dodać skanowanie do istniejącego pipeline’u bez wdrażania centralnej aplikacji.

Osobny skaner bywa przydatny jako druga opinia. Menedżer pakietów i niezależne narzędzie mogą korzystać z innych źródeł advisory albo odmiennie dopasowywać wersje. Różnica w wynikach nie oznacza automatycznie, że jedno z narzędzi jest błędne. Powinna skłonić zespół do sprawdzenia identyfikatora podatności, zakresu wersji, ścieżki w grafie oraz sposobu użycia komponentu.

Plusy i minusy niezależnego skanowania

Najważniejszym plusem jest prostota wdrożenia i możliwość uruchomienia narzędzia w kilku miejscach: na stacji dewelopera, w pre-commit hooku, w CI oraz podczas zaplanowanego skanu. CLI łatwo również wykorzystać w obrazie narzędziowym albo w zadaniu automatyzacji, bez udostępniania całego repozytorium zewnętrznej platformie.

Minusem jest brak pełnego systemu zarządzania przypadkami. Sam skaner nie musi wiedzieć, kto jest właścicielem usługi, czy podatność ma zaakceptowany wyjątek i kiedy wyjątek powinien wygasnąć. Raporty trzeba przekazać do systemu zgłoszeń albo uzupełnić własnym mechanizmem. Przy dużej liczbie projektów może to oznaczać dodatkową pracę administracyjną.

Ten wariant pasuje do zespołów, które preferują narzędzia open source, mają ograniczenia dotyczące przesyłania kodu poza organizację albo chcą uzupełnić audyt npm o niezależne źródło danych. Nie zastępuje jednak kontroli skryptów lifecycle, analizy podejrzanych wydań ani oceny podatności w uruchomionym obrazie.

osv-scanner scan source -r .

Składnia i dostępne tryby mogą zmieniać się wraz z wersją narzędzia, dlatego polecenie powinno zostać przypięte do konkretnego obrazu CI lub zweryfikowane w dokumentacji używanej wersji. Istotniejsze od samej komendy jest określenie, co dokładnie jest skanowane: repozytorium, lockfile, katalog po instalacji czy artefakt przeznaczony do wdrożenia.

Wariant 4: SBOM i kontrola zależności w artefakcie wdrożeniowym

Czwarty wariant koncentruje się nie tylko na repozytorium, ale na tym, co faktycznie trafia do środowiska uruchomieniowego. Zespół generuje SBOM, czyli spis komponentów wytworzonego artefaktu, a następnie przekazuje go do skanera podatności lub systemu zarządzania ryzykiem. W ekosystemie Node.js SBOM może obejmować zależności aplikacji, a w przypadku kontenera także system bazowy i narzędzia obecne w obrazie.

Takie podejście odpowiada na problem rozbieżności między kodem źródłowym a wdrożeniem. W obrazie mogą pozostać zależności deweloperskie, pliki z cache’em, narzędzia kompilacyjne albo inna wersja Node.js niż ta używana lokalnie. Skanowanie samego package.json nie pokaże całego składu takiego artefaktu.

Kiedy SBOM daje największą wartość

SBOM jest szczególnie przydatny w organizacjach, które muszą szybko ustalić, czy nowo ujawniona podatność dotyczy już wdrożonych usług. Jeżeli każda wersja obrazu ma powiązany spis komponentów, można wyszukać podatny pakiet bez ręcznego odtwarzania stanu każdego repozytorium.

Ten wariant wymaga jednak dojrzałego procesu budowania. Trzeba ustalić, w którym momencie powstaje SBOM, jak jest przechowywany, z jakim digestem obrazu jest powiązany i kto aktualizuje wynik po zmianie bazy podatności. Sam dokument nie zabezpiecza łańcucha dostaw, jeśli nie ma kontroli nad jego pochodzeniem i integralnością.

• Plus: widoczność składników rzeczywiście dostarczanych do środowiska.
• Plus: szybsze wyszukiwanie podatnego komponentu w wielu obrazach i usługach.
• Minus: większa złożoność procesu oraz potrzeba przechowywania i aktualizowania artefaktów.
• Minus: SBOM nie ocenia samodzielnie jakości kodu, konfiguracji ani bezpieczeństwa skryptów instalacyjnych.

Porównanie wariantów i dobór do dojrzałości zespołu

Kryteria wyboru narzędzia

Przed wyborem rozwiązania warto odpowiedzieć na kilka praktycznych pytań:

• Czy analiza ma obejmować tylko repozytorium, czy także obraz kontenera i artefakt produkcyjny?
• Czy narzędzie rozpoznaje zależności przechodnie oraz rozdziela komponenty produkcyjne od deweloperskich?
• Czy wynik zawiera ścieżkę zależności, identyfikator advisory i wersję naprawioną?
• Czy można przypisać alert właścicielowi, ustawić termin wyjątku i zachować uzasadnienie decyzji?
• Czy skaner działa przy zmianie bazy podatności, nawet gdy repozytorium nie otrzymało nowego commita?
• Czy dane pozostają w infrastrukturze organizacji, czy są przesyłane do usługi zewnętrznej?
• Czy narzędzie pozwala zakończyć proces kodem błędu dopiero po ustaleniu poziomu ryzyka i zakresu projektu?

Rekomendowany model warstwowy

Dla większości zespołów najlepszym wyborem nie jest zastąpienie jednego narzędzia drugim, lecz połączenie kontroli na różnych etapach. W małym projekcie podstawą może pozostać audyt menedżera pakietów, uzupełniony o zaplanowany skan niezależnym CLI. Gdy liczba repozytoriów rośnie, warto dodać platformę SCA z właścicielami i terminami obsługi. Jeżeli aplikacje są dostarczane jako kontenery, kolejną warstwą powinno być skanowanie SBOM lub obrazu wdrożeniowego.

Ważne, aby każda warstwa miała odrębną funkcję. Audyt w pull requeście ma szybko zatrzymać nową podatną zależność. Skan okresowy ma wykryć zmianę w bazie advisory bez zmian w kodzie. SCA ma wspierać priorytetyzację i obsługę wyjątków, a SBOM ma odpowiedzieć na pytanie, co rzeczywiście działa w produkcji. Dublowanie tego samego skanu w kilku miejscach bez określenia odpowiedzialności zwiększa liczbę komunikatów, ale niekoniecznie poprawia bezpieczeństwo.

Rekomendowany punkt wyjścia to przypięty lockfile, powtarzalna instalacja, audyt w CI oraz okresowy skan niezależnym narzędziem. Platformę SCA warto wybrać wtedy, gdy ręczne zarządzanie alertami przestaje być wykonalne, a SBOM wtedy, gdy organizacja musi kontrolować skład wielu wdrażanych artefaktów. Niezależnie od wariantu, każdy wyjątek powinien mieć właściciela, uzasadnienie, zakres oraz datę ponownej oceny.

Kluczowe Wnioski

• Bezpieczeństwo łańcucha dostaw npm wymaga analizy zależności bezpośrednich i przechodnich, a nie tylko kodu własnego projektu.
• Lockfile, powtarzalna instalacja oraz kontrola zmian w package.json i pliku blokady pomagają odtworzyć dokładny stan zależności.
• npm audit, pnpm i Yarn zapewniają podstawowy poziom wykrywania znanych podatności, ale ich wyniki warto uzupełnić o monitoring, analizę skryptów instalacyjnych i kontrolę źródeł pakietów.
• Szczególną uwagę należy zwrócić na typosquatting, przejęcia kont maintainerów, anomalie w nowych wydaniach oraz skrypty preinstall, install i postinstall.
• Wyniki skanowania powinny być częścią procesu CI/CD, code review i procedury reakcji na alerty, zamiast pozostawać jednorazową kontrolą wykonywaną lokalnie.

Źródła

• [1] npm Docs – Auditing package dependencies for security vulnerabilities
• [2] npm Docs – npm-audit
• [3] GitHub Docs – Dependabot security updates
• [4] npm Docs – npm: Threats and Mitigations