npm audit

Jak działa npm audit

npm audit wysyła opis zależności projektu do domyślnego rejestru i pyta o znane podatności. Potrzebuje pliku package-lock.json lub pliku shrinkwrap, ponieważ dzięki niemu wie, jakie wersje są używane. Szczegóły zawiera dokumentacja npm.

npm audit                       # report everything
npm audit --omit=dev            # skip dev dependencies
npm audit --audit-level=high    # fail only on high or critical
npm audit --json                # machine-readable output

Jak czytać raport

• Ważność pochodzi z biuletynu. Mówi, jak poważna jest luka ogólnie, a nie jak poważna jest dla Państwa.
• Ścieżka zależności pokazuje, co pobrało pakiet. Większość znalezisk to zależności przechodnie, a poprawka zwykle dotyczy pakietu wyżej.
• Zależność deweloperska czy produkcyjna. Luka w narzędziu testowym nie trafia do użytkowników, ale samo narzędzie nadal działa w Państwa buildzie, więc nie należy jej całkowicie ignorować.

Przy długiej liście warto zacząć od tego, co jest wykorzystywane w atakach i co jest dostarczane. Zob. jak priorytetyzować podatności.

npm audit fix i kiedy go nie wymuszać

Polecenie	Co robi	Ryzyko
npm audit fix	Stosuje zgodne aktualizacje w ramach Państwa zakresów wersji	Niskie. Testy i tak należy uruchomić, ponieważ polecenie wykonuje pełną instalację
npm audit fix --force	Dopuszcza też zmiany poza Państwa zakresami, łącznie z wersjami głównymi	Wysokie. Może zepsuć aplikację, a npm zaleca, aby nie używać go bez jasnego pojęcia o tym, co chce się osiągnąć

Jeśli poprawka nie jest dostępna, można zaktualizować pakiet nadrzędny lub użyć pola overrides w package.json, aby wymusić załataną wersję przechodnią. Należy to przetestować, ponieważ pakiet nadrzędny nie był budowany z tą wersją.

Uruchamianie npm audit w CI

Domyślnie npm audit kończy się kodem niezerowym, gdy cokolwiek znajdzie, co powoduje niepowodzenie zadania przy każdym biuletynie niskiej ważności. Zespoły zwykle ustawiają próg. Warto pamiętać, że --audit-level zmienia tylko próg niepowodzenia i nie filtruje raportu.

- run: npm ci
- run: npm audit --omit=dev --audit-level=high

Taka kontrola może też spowodować niepowodzenie buildu bez żadnej zmiany w kodzie, ponieważ w nocy opublikowano nowy biuletyn. Przed jej włączeniem należy ustalić, kto odpowiada za takie niepowodzenie. Więcej zawiera strona gdzie uruchamiać skany SCA.

Czego npm audit nie wykrywa

• Niczego spoza npm. Państwa obrazu bazowego, pakietów systemu operacyjnego, narzędzi Pythona i GitHub Actions nie ma w package-lock.json.
• Kodu pobieranego podczas instalacji. Skrypty instalacyjne mogą pobierać pliki, których nie zapisuje żaden lockfile. Zob. czego lockfile nie zapisuje.
• Nowych złośliwych pakietów. Dopasowuje opublikowane biuletyny, więc pakiet bez biuletynu przechodzi bez zastrzeżeń.
• Tego, co już dostarczono. Raportuje o projekcie, który ma przed sobą. Nowy biuletyn dotyczący zeszłorocznego wydania pojawi się tylko wtedy, gdy ktoś ponownie uruchomi audyt na tej wersji.
• Tego, czy problem Państwa dotyczy. Nie wie, czy Państwa kod używa podatnej funkcji. Tym zajmuje się analiza osiągalności.

npm audit signatures to osobne polecenie, które weryfikuje podpisy rejestru i atestacje pochodzenia zainstalowanych pakietów. Sprawdza, skąd pochodzi pakiet, a nie czy jest bezpieczny.

npm audit i CRACI

Proszę nadal uruchamiać npm audit przy pull requestach. Jest bezpłatny i wcześnie wychwytuje znane problemy. CRACI obejmuje to, czego on nie widzi: jako Państwa runner GitHub Actions rejestruje każdy pakiet, który każde zadanie faktycznie pobrało z npm i z każdego innego źródła, łącznie z pakietami przywróconymi z cache CI i plikami pobranymi przez hooki instalacyjne. Następnie dalej sprawdza SBOM dostarczonego oprogramowania w miarę publikowania nowych podatności. Zob. najlepsze narzędzia SCA lub generowanie SBOM w trakcie buildu.

npm audit: najczęściej zadawane pytania

Co robi npm audit?

Wysyła opis zależności do rejestru npm, sprawdza je względem znanych biuletynów bezpieczeństwa i raportuje podatne pakiety wraz z ich ważnością i sposobem, w jaki trafiły do projektu.

Czy npm audit fix jest bezpieczne?

Zwykłe npm audit fix jest zazwyczaj bezpieczne, ponieważ nie wychodzi poza zakresy wersji, ale potem należy uruchomić testy. npm audit fix --force może zainstalować nowe wersje główne i zepsuć aplikację.

Dlaczego npm audit pokazuje tak wiele podatności?

Większość pochodzi z zależności przechodnich i narzędzi deweloperskich. --omit=dev pozwala skupić się na tym, co jest dostarczane, a priorytety należy ustalać według wykorzystania i ekspozycji, a nie liczby.

Jak zignorować podatność w npm audit?

npm audit nie ma wbudowanej listy ignorowanych podatności. Zespoły używają pola overrides, aby zmienić wersję, progu z --audit-level lub narzędzia opakowującego, które zapisuje zaakceptowane znaleziska.

Czy npm audit wymaga lockfile?

Tak, domyślnie wymaga package-lock.json lub pliku shrinkwrap. Można to obejść za pomocą --no-package-lock, ale wyniki mogą się wtedy różnić między uruchomieniami.

Czy npm audit wykrywa złośliwe oprogramowanie?

Tylko wtedy, gdy dla pakietu opublikowano już biuletyn. Nowy złośliwy pakiet nie ma biuletynu, więc w dniu pojawienia się nie zostanie zgłoszony.