TL; DR
Znalezienie luk w pakietach npm jest łatwe. npm audit robi to w cztery sekundy i podaje Ci 400 wyników. Najtrudniejszą częścią jest odpowiedź na dwa kolejne pytania: do którego z nich można faktycznie dotrzeć w Twojej aplikacji i która aktualizacja rozwiązuje problem, nie zakłócając kompilacji.
- Większość z tej listy nie jest Twoim problemem. Zastosowanie kontekstu dostępności i czasu wykonania do „krytycznych” ustaleń pozostawia niewielką część nadal krytyczną. Analiza grafów wywołań pozwala określić, które z nich są istotne.
npm audit fix --forcenie jest strategią naprawczą. Rozwiązuje ostrzeżenia, przeskakując między wersjami głównymi, w ten sposób zadanie związane z bezpieczeństwem staje się awarią.- Zależności przechodnie to miejsce, w którym znajduje się wolumen. Nie wybierałeś ich, często nie możesz ich bezpośrednio uaktualnić i dominują one w liczbie znalezionych wyników.
- Napraw przed scaleniem, a nie po wydaniu. Brama w CI i automatyka pull request Kosztuje minuty. Poprawka produkcyjna kosztuje weekend.
Dlaczego liczba znalezionych elementów nie stanowi problemu
Każdy projekt Node po pierwszym roku daje takie samo doświadczenie. Przeprowadzasz skanowanie, otrzymujesz setki luk w zabezpieczeniach pakietów npm, a lista jest tak długa, że racjonalną reakcją jest zamknięcie terminala.
Ta reakcja jest prawidłowa, ale to właśnie ta niewygodna część. Prawie trzy czwarte baz kodu zawiera komponenty open source wysokiego ryzyka, a większość tego, co skaner raportuje każdego dnia, rzeczywiście znajduje się w drzewie zależności. Lista jest prawidłowa. To po prostu nie jest kolejka zadań.
Różnica między dokładną listą a listą wykonalną leży w kontekście, który sprowadza się do odpowiedzi na kilka pytań.
- Czy do podatnego kodu można faktycznie dotrzeć z poziomu mojej aplikacji?
- Czy ktoś wykorzystuje to w środowisku naturalnym?
- Czy sprawa, której dotyczy, ma znaczenie dla biznesu?
Skaner, który nie potrafi odpowiedzieć na te pytania, podaje Ci inwentarz i nazywa go raportem.
Jak sprawdzać pakiety npm pod kątem luk w zabezpieczeniach
Istnieją cztery praktyczne sposoby sprawdzania pakietów npm pod kątem luk w zabezpieczeniach, które odpowiadają na różne pytania.
Zacznij od npm audit Bo nic nie kosztuje i zajmuje sekundy. Nie zatrzymuj się na tym, bo odpowiedź brzmi: „tu jest wszystko”, a nie wszystko jest planem.
Warto wiedzieć, jeśli korzystasz z kanałów informacyjnych: baza danych GitHub Advisory Database zawiera ostrzeżenia dotyczące złośliwego oprogramowania dla ekosystemu npm, ale Dependabot celowo nie generuje alertów, ponieważ użytkownik końcowy zazwyczaj nie jest w stanie ich rozwiązać poprzez aktualizację. To luka strukturalna, a nie ustawienie, które można włączyć. Złośliwe pakiety wymagają innej kontroli: wykrywania w momencie publikacji, a nie po ujawnieniu. Xygeni Wczesne ostrzeganie przed złośliwym oprogramowaniem Analizuje nowo opublikowane pakiety w npm, PyPI, Maven i innych rejestrach w momencie ich pojawienia się, wykorzystując analizę behawioralną i analizę anomalii, zamiast czekać na podpis. Jest ona zawarta w darmowym planie Developer. Omówimy ją w złośliwy pakiety npm.
Filtry, które zamieniają 400 wyników w krótką listę
To jest ten element, który zmienia sposób pracy zespołu.
| Filtruj | Pytanie, na które odpowiada | Co zwykle usuwa |
|---|---|---|
| Osiągalność | Czy wykonywanie kodu w mojej aplikacji faktycznie dotrze do podatnych na ataki funkcji? | Największe cięcie. Większość ostrzeżeń znajduje się w kodzie, którego aplikacja nigdy nie wywołuje. |
| Wykorzystaj dostępność | Czy istnieje działający, publiczny exploit i czy jest on obecnie wykorzystywany w praktyce? | Oddziela ryzyko teoretyczne od ryzyka uzbrojonego. Znalezisko z publicznym exploitem omija kolejkę, niezależnie od jego poziomu ważności. |
| Prawdopodobieństwo wykorzystania (EPSS) | Jakie jest prawdopodobieństwo eksploatacji na wolności w ciągu najbliższych 30 dni? | Odkrycia o dużym znaczeniu, których nikt nie wykorzystuje, a które rzadko pojawiają się w tym tygodniu |
| Kontekst biznesowy | Czy rodzaj usługi, której to dotyczy, ma znaczenie i czy jest ona ujawniana? | Osiągalne, możliwe do wykorzystania ustalenia w systemach, które nie niosą ze sobą żadnego znaczącego ryzyka |
| Napraw dostępność | Czy istnieje wersja rozwiązująca ten problem, która mnie nie zepsuje? | Oddziela to, co możesz zamknąć dzisiaj, od tego, co wymaga obejścia |
- Osiągalność To pierwsze i największe cięcie. Luka w pakiecie, od którego jesteś zależny, jest możliwa do wykorzystania tylko wtedy, gdy wykonanie może faktycznie dotrzeć do podatnej funkcji. Śledzenie grafu wywołań odpowiada na to pytanie na poziomie funkcji, zamiast zgadywać z manifestu, i odróżnia komponenty, których faktycznie używasz, od tych, które są jedynie obecne. Analiza osiągalności Xygeni redukuje liczbę fałszywych alarmów nawet o 70%.
Wykorzystaj dostępność jest drugim i jest faktem, a nie prognozą. Działający, publiczny exploit lub potwierdzona eksploatacja w środowisku naturalnym zmienia priorytet odkrycia niezależnie od jego poziomu ważności. To rozróżnienie przestało być dobrą praktyką, a stało się obowiązkiem: zgodnie z ustawą o odporności cybernetycznej (Cyber Resilience Act), producent, który dowiaduje się o aktywnie wykorzystywanej luce w swoim produkcie, znajduje się w 24-godzinnym cyklu raportowania. Program, który nie potrafi oddzielić „aktywnie wykorzystanej” od „wysokiego CVSS”, nie może dotrzymać tego limitu.
Prawdopodobieństwo wykorzystania luk to trzecia kwestia, i to samo pytanie, ale z powrotem wprowadzona prognoza. EPSS ocenia prawdopodobieństwo, że luka zostanie wykorzystana w ciągu najbliższych 30 dni, co jest zupełnie innym pytaniem niż to, jak źle by było, gdyby tak się stało. Wysoki wynik CVSS przy znikomym wyniku EPSS rzadko jest wynikiem z tego tygodnia.
- Kontekst biznesowy Jest to trzecia i niedostępna w żadnym ogólnym kanale. Dostępna, możliwa do wykorzystania luka w zabezpieczeniach usługi płatności internetowej to nie to samo odkrycie, co ten sam CVE w wewnętrznym narzędziu do raportowania.
Zastosowane razem, te filtry rutynowo zamieniają listę, której nikt nie czyta, w listę, którą ktoś kończy. Kontekst środowiska wykonawczego i osiągalności zazwyczaj pozostawia jedynie niewielką mniejszość „krytycznych” ustaleń. Xygeni traktuje osiągalność, dostępność exploitów, EPSS i kontekst biznesowy jako konfigurowalne etapy w leju priorytetyzacji, maksymalnie osiem, więc „osiągalne i aktywnie wykorzystywane” staje się kolejką oczekujących, a nie zapytaniem uruchamianym ręcznie.
Naprawianie luk w zabezpieczeniach pakietów npm bez przerywania kompilacji
Znalezienie to najłatwiejsza połowa. Powodem, dla którego luki w zabezpieczeniach pakietów npm pozostają nierozwiązane przez miesiące, jest to, że ich naprawa niesie ze sobą ryzyko i programiści o tym wiedzą.
Pytanie, które ma znaczenie przed jakąkolwiek aktualizacją, nie brzmi: „czy to łata CVE”. Chodzi o trzy pytania naraz: które luki znikają wraz z tą wersją, które nowe pojawiają się wraz z nią i czy ta wersja psuje mój kod.
Xygeni pokazuje wszystkie trzy dla każdej podatnej zależności, więc wybór dotyczy widocznych opcji, a nie skoku. Następnie Autofix generuje pull request w przypadku wersji z poprawkami, zbiorcze naprawy stosują wiele poprawek w jednej akcji, a bot Xygeni działa na żądanie, pull requests lub codziennie, dzięki czemu zaległości maleją bez konieczności planowania ich przez kogokolwiek.
W przypadku zależności przechodnich, gdy nie można po prostu zaktualizować wersji, której się nie wybrało, przydatnym wyjściem jest najkrótsza ścieżka aktualizacji w drzewie, która rozwiązuje ostrzeżenie, a nie alert informujący, że pakiet cztery poziomy niżej jest podatny na ataki.
Przed wysyłką: gdzie jest miejsce na czek
„Zanim zostaną wysłane” to stwierdzenie dotyczące harmonogramu, które sprowadza się do trzech miejsc docelowych.
- W środowisku IDE, więc deweloper widzi problem już na etapie wyboru zależności, kiedy jest najtańszy moment na jej zmianę.
- Na pull request, gdzie bot komentuje zmiany i otwiera poprawkę, a bramka bezpieczeństwa może zablokować kompilację z powodu ustaleń powyżej określonego progu. Bramka bezpieczeństwa sama w sobie jest powodem, dla którego zespoły wyłączają bramkę. Bramka bezpieczeństwa oparta na dostępnych i podatnych na wykorzystanie ustaleniach jest powodem, dla którego ją zachowują.
- Ciągle po wydaniu, Ponieważ zależność, która była czysta podczas scalania, staje się podatna na ataki w dniu opublikowania ostrzeżenia. Ciągły monitoring rejestrów pozwala to wykryć, bez konieczności ponownego skanowania.
A wynik wszystkich trzech powinien znaleźć się w jednej, priorytetowej kolejce obok Twojego SAST, tajniki, ustalenia dotyczące kontenerów, w tym te pobierane z narzędzi, które już uruchamiasz. lista luk w zabezpieczeniach która znajduje się we własnej konsoli, jest listą konkurującą o uwagę z pracą, o której miała informować.
Wyślij rozwiązanie, a nie znalezisko
Skaner, który podaje Ci 400 luk w zabezpieczeniach pakietów npm, nie wykonał zadania. Przeniósł je.
Xygeni zawęża ustalenia zależności według dostępności, prawdopodobieństwa wykorzystania i kontekstu biznesowego, pokazuje, co naprawia każda aktualizacja i co może zepsuć, i otwiera pull request z poprawioną wersją. Działa w twoim pipeline, produkuje SBOM i dane wyjściowe VDR w SPDX i CycloneDX, dowody wymagane przez CRA, NIS2 i DORA, a także umieszcza ustalenia dotyczące zależności w tej samej priorytetowej kolejce co resztę ryzyka, łącznie z ustaleniami ze skanerów, których nie zastępujesz.
Zacznij za darmo i zeskanuj repozytorium lub zobacz jak dostępność zmienia listę.
FAQ
Jak sprawdzić pakiety npm pod kątem luk w zabezpieczeniach?
Uruchom npm audit Aby uzyskać natychmiastowy podgląd, użyj narzędzia z analizą dostępności, aby zawęzić listę do wyników, w których podatny kod faktycznie może zostać wywołany. Bazy danych z poradami, takie jak OSV i baza danych GitHub Advisory Database, są przydatne do sprawdzania konkretnego pakietu i wersji.
Is npm audit fix Czy bieganie jest bezpieczne?
Wersja niewymuszona jest zazwyczaj bezpieczna, ponieważ mieści się w zakresie kompatybilności semver. npm audit fix --force nie jest: uaktualnia się w kolejnych wersjach, aby rozwiązać ostrzeżenia, i to właśnie stamtąd biorą się zmiany powodujące przerwanie działania programu.
Dlaczego mam tak wiele luk w pakietach npm?
Ponieważ większość z nich jest przechodnia. Instalujesz garść bezpośrednich zależności i dziedziczysz setki pośrednich, z których każda ma własną historię doradczą. Objętość jest normalna. Brakuje tylko triażu.
Czym jest analiza osiągalności?
Określenie, czy wykonanie w aplikacji może faktycznie dotrzeć do podatnej funkcji w zależności. To największa redukcja szumów dostępna w zabezpieczeniach zależności, ponieważ większość zgłaszanych luk znajduje się w kodzie, którego aplikacja nigdy nie wywołuje.
Czy do ustalania priorytetów powinienem używać CVSS czy EPSS?
Oba, ale dla różnych celów. CVSS opisuje, jak poważna byłaby luka w zabezpieczeniach, gdyby została wykorzystana. EPSS szacuje prawdopodobieństwo wykorzystania w ciągu najbliższych 30 dni. Powaga bez prawdopodobieństwa powoduje utworzenie kolejki posortowanej według niewłaściwej osi.
Jak często powinienem sprawdzać pakiety npm pod kątem luk w zabezpieczeniach?
Ciągle, a nie według harmonogramu. Czyste skanowanie w poniedziałek nic nie znaczy w środę, jeśli ostrzeżenie pojawi się na paczce, którą już wysłałeś.
