Pakiet npm ma zielony znacznik? To dopiero początek weryfikacji

Przed dodaniem pakietu npm sprawdź dokładną wersję, którą ma pobrać projekt: jej pochodzenie, commit źródłowy i workflow publikacji, a następnie opiekunów, zależności oraz skrypty w opublikowanej paczce. Instrukcja npm dotycząca provenance wskazuje, że zielony znacznik przy polu Version oznacza publikację z informacją o pochodzeniu i prowadzi do szczegółów procesu budowania. Sam znacznik pozwala ustalić drogę wydania, lecz nie ocenia bezpieczeństwa kodu, który zostanie uruchomiony w projekcie.

Najpierw porównaj dane wydania z repozytorium i obejrzyj archiwum bez wykonywania skryptów. Dopiero po tym etapie sprawdź podpisy i atestacje pobranych zależności poleceniem npm audit signatures. Ta kontrola wymaga wcześniejszej instalacji zależności, więc warto wykonać ją w odizolowanym środowisku z wyłączonymi skryptami, przed zwykłym dodaniem paczki do projektu.

Od znacznika przejdź do commitu i workflow

Na stronie pakietu w npm wybierz wersję, którą rzeczywiście planujesz dodać. Kliknij zielony znacznik obok pola Version, a potem View more details. Zapis pochodzenia obejmuje środowisko budowania, odnośnik do przebiegu workflow, commit źródłowy, plik workflow i wpis w publicznym rejestrze przejrzystości. Zwróć uwagę, czy odnośniki dotyczą oczekiwanego repozytorium i tego samego wydania.

Otwórz commit, od którego pochodzi paczka, i zobacz, co zmieniło się względem poprzedniego wydania: szczególnie pliki publikacyjne, skrypty oraz kod wykonywany przy instalacji. W pliku workflow sprawdź kroki przygotowania i publikacji oraz to, skąd pobierane są używane w nim działania. Poprawny zapis pochodzenia mówi, skąd i jak opublikowano wydanie; nie przesądza, czy sam commit i proces budowania są bezpieczne.

npm sprawdza dostępność wskazanego commitu i repozytorium podczas otwierania danych provenance. Jeśli repozytorium usunięto lub stało się prywatne, przy danych pojawia się ostrzeżenie i nie da się już potwierdzić wskazanego połączenia ze źródłem tą drogą. W takiej sytuacji poproś opiekunów o wyjaśnienie albo wybierz wersję, której historię można prześledzić.

Sprawdź opiekunów i historię utrzymania

Ocena opiekunów dotyczy obecnej odpowiedzialności za pakiet, a nie samej daty ostatniego wydania. Zalecenia ENISA dotyczące wyboru pakietów obejmują przegląd danych opiekunów, aktywności repozytorium, historii wydań, skryptów i drzewa zależności. W rejestrze odczytaj opiekunów poleceniem npm view nazwa@wersja maintainers, a historię publikacji poleceniami npm view nazwa versions oraz npm view nazwa time.

Porównaj nazwy kont z informacjami w repozytorium. Sprawdź, czy zgłoszenia otrzymują odpowiedzi, czy poprawki trafiają do wydań oraz czy istnieje opis zmian i sposób zgłaszania problemów bezpieczeństwa. Długa przerwa może być naturalna dla małej, stabilnej biblioteki; ważniejsze jest, czy ktoś potrafi wyjaśnić istotną zmianę i zareagować na zgłoszenie. Sama popularność albo częste publikacje nie zastępują takiej oceny.

Jeśli nowa wersja wprowadza zmianę sposobu budowania lub nowe skrypty, przejrzyj ją dokładniej, nawet gdy starsze wydania były dobrze utrzymywane. Przy pakiecie o podobnej nazwie do znanego projektu upewnij się też, że wybrana nazwa i zakres npm są właściwe. Zaufanie do wcześniejszej wersji nie przechodzi automatycznie na nowo opublikowaną paczkę.

Ustal, jakie zależności trafią do projektu

Polecenie npm view nazwa@wersja dependencies optionalDependencies peerDependencies pokazuje deklaracje dla wybranej wersji bez dodawania jej do projektu. dependencies wskazuje zależności bezpośrednie, optionalDependencies pakiety opcjonalne, a peerDependencies wymagania wobec pakietów w projekcie. Sprawdź zwłaszcza nowe albo nieoczekiwane nazwy, ich przeznaczenie i wersje. Atestacja głównej paczki nie obejmuje automatycznie pochodzenia każdej z jej zależności.

Deklaracje bezpośrednie nie pokazują całego drzewa. W kopii projektu możesz przygotować propozycję pliku blokady poleceniem npm install --package-lock-only nazwa@wersja; ta opcja aktualizuje package-lock.json bez pobierania paczek do node_modules. Obejrzyj różnicę w pliku: nowe pakiety pośrednie, rozstrzygnięte wersje i adresy, z których mają być pobrane. Taka kontrola pozwala zauważyć, gdy niewielka funkcja wprowadza duży lub trudny do wyjaśnienia zakres zależności.

Sam rozmiar drzewa nie jest werdyktem. Biblioteka może potrzebować wielu uzasadnionych modułów, a niewielki pakiet nadal może wykonywać niepożądany kod. Ważne jest, czy każda nowa zależność ma związek z funkcją, której potrzebujesz, i czy dodatkowy zakres utrzymania jest akceptowalny dla zespołu.

Przeczytaj skrypty i zawartość opublikowanego archiwum

W metadanych wybranej wersji odczytaj pole scripts, na przykład przez npm view nazwa@wersja scripts. Zwróć uwagę na preinstall, install i postinstall, a następnie otwórz pliki wywoływane przez te polecenia. Krótki wpis w package.json może uruchamiać dłuższy program, pobierać dodatkowy kod albo uruchamiać powłokę. Szczególnego wyjaśnienia wymaga dostęp do zmiennych środowiskowych, plików projektu i zasobów sieciowych podczas instalacji.

Repozytorium nie zawsze pokazuje dokładnie te pliki, które opublikowano w npm: paczka może zawierać zbudowane pliki albo inny układ katalogów. Dokumentacja npm pack opisuje pobranie wskazanego wydania jako archiwum .tgz oraz opcję --ignore-scripts, która wyłącza skrypty z package.json. W osobnym katalogu użyj npm pack --ignore-scripts nazwa@wersja, a potem obejrzyj zawartość archiwum bez uruchamiania znajdującego się w nim kodu.

Porównaj package.json w archiwum z metadanymi oraz sprawdź pliki wskazane przez skrypty i główne pliki wejściowe pakietu. Jeżeli commit pokazuje niewielką poprawkę, a paczka zawiera nowe polecenia instalacyjne lub obcy kod, potrzebne jest wyjaśnienie rozbieżności przed dopuszczeniem wydania. Podobnie potraktuj pobieranie pliku wykonywalnego z adresu, którego pochodzenia i integralności nie umiesz ustalić.

Po pobraniu sprawdź podpisy i atestacje

Po przejrzeniu archiwum można w odizolowanej kopii projektu uruchomić npm ci --ignore-scripts na przygotowanym pliku blokady, a następnie npm audit signatures. Pierwsze polecenie pobiera zależności bez wykonywania skryptów z package.json; drugie sprawdza podpisy rejestru i dostępne atestacje pochodzenia pobranych wersji. Nie uruchamiaj w tym środowisku kodu pobranego pakietu ani skryptów projektu przed zakończeniem oceny.

Błąd podpisu lub atestacji wymaga wyjaśnienia przed zwykłą instalacją. Brak provenance dla którejś zależności oznacza słabszą możliwość prześledzenia jej publikacji, lecz sam w sobie nie dowodzi złośliwości. Jeżeli pakiet potrzebuje skryptu instalacyjnego do działania, dopuść jego wykonanie dopiero po przejrzeniu kodu i ustaleniu, po co potrzebuje wskazanych uprawnień oraz dostępu do sieci.