TL; DR
Det er enkelt å finne sårbarheter i npm-pakker. npm audit gjør det på fire sekunder og gir deg 400 funn. Den vanskelige delen er de neste to spørsmålene: hvilke av dem kan faktisk nås i applikasjonen din, og hvilken oppgradering som løser problemet uten å ødelegge byggingen.
- Det meste av listen er ikke ditt problem. Å bruke tilgjengelighet og kjøretidskontekst på «kritiske» funn, lar en liten brøkdel fortsatt være kritisk. Det er samtalegrafanalyse som forteller deg hvilke.
npm audit fix --forceer ikke en fiksstrategi. Den løser advarsler ved å hoppe over større versjoner, som er hvordan en sikkerhetsoppgave blir et driftsavbrudd.- Transitive avhengigheter er der volumet befinner seg. Du valgte dem ikke, du kan ofte ikke oppgradere dem direkte, og de dominerer antallet funn.
- Fiks før sammenslåingen, ikke etter utgivelsen. En port i CI og en automatisert pull request koster minutter. En produksjonsoppdatering koster en helg.
Hvorfor antallet funn ikke er problemet
Hvert Node-prosjekt som har gått utover sitt første år, gir den samme opplevelsen. Du kjører en skanning, du får hundrevis av sårbarheter i npm-pakker, og listen er så lang at den rasjonelle responsen er å lukke terminalen.
Den reaksjonen er riktig, som er den ubehagelige delen. Nesten tre fjerdedeler av kodebasene inneholder høyrisikokomponenter med åpen kildekode, og det meste av det en skanner rapporterer på en gitt dag finnes faktisk i avhengighetstreet ditt. Listen er nøyaktig. Det er bare ikke en arbeidskø.
Gapet mellom en nøyaktig liste og en handlingsrettet liste er kontekst, og det kommer ned til en håndfull spørsmål.
- Er den sårbare koden faktisk tilgjengelig fra applikasjonen min?
- Er det noen som utnytter dette i naturen?
- Har det det påvirker noen betydning for bedriften?
En skanner som ikke kan svare på dem, gir deg en inventarliste og kaller det en rapport.
Slik sjekker du npm-pakker for sårbarheter
Det finnes fire praktiske måter å sjekke npm-pakker for sårbarheter, og de svarer på forskjellige spørsmål.
Begynne med npm audit fordi det ikke koster noe og tar sekunder. Ikke stopp der, for svaret det gir er «her er alt», og alt er ikke en plan.
En ting som er verdt å vite hvis du stoler på rådgivende feeder: GitHub Advisory Database inneholder skadevareråd for npm-økosystemet, men Dependabot varsler bevisst ikke om dem, fordi en nedstrømsbruker vanligvis ikke kan løse dem ved å oppgradere. Det er et strukturelt gap, ikke en innstilling du kan slå på. Ondsinnede pakker trenger en annen kontroll: deteksjon ved publisering i stedet for etter avsløring. Xygenis Tidlig advarsel om skadelig programvare analyserer nylig publiserte pakker på tvers av npm, PyPI, Maven og andre registre i det øyeblikket de dukker opp, ved hjelp av atferds- og anomalianalyse i stedet for å vente på en signatur, og det er inkludert i den gratis utviklerplanen. Vi dekker det i skadelig npm-pakker.
Filtrene som forvandler 400 funn til en kort liste
Dette er den delen som endrer hvordan et team fungerer.
| Filtrer | Spørsmålet den besvarer | Hva den vanligvis fjerner |
|---|---|---|
| reachability | Kan kjøringen i applikasjonen min faktisk nå den sårbare funksjonen? | Det største kuttet. De fleste rådene ligger i koden som applikasjonen aldri kaller. |
| Tilgjengelighet av utnyttelse | Finnes det en fungerende offentlig utnyttelse, og blir denne utnyttet i naturen akkurat nå? | Skiller teoretisk risiko fra våpenbasert risiko. Et funn med en offentlig utnyttelse hopper i køen uansett hva alvorlighetsgraden angir. |
| Sannsynlighet for utnyttelse (EPSS) | Hvor sannsynlig er det at det vil bli utnyttet i naturen i løpet av de neste 30 dagene? | Funn med høy alvorlighetsgrad som ingen utnytter, noe som sjelden er denne ukens arbeid |
| Forretningskontekst | Har den berørte tjenesten noen betydning, og er den eksponert? | Tilgjengelige, utnyttbare funn i systemer som ikke medfører noen betydelig risiko |
| Fiks tilgjengelighet | Finnes det en versjon som løser dette uten å ødelegge for meg? | Skiller det du kan avslutte i dag fra det som trenger en løsning |
- reachability er det første og største kuttet. En sårbarhet i en pakke du er avhengig av, kan bare utnyttes hvis utførelsen faktisk kan nå den sårbare funksjonen. Kallgrafsporing svarer på det på funksjonsnivå i stedet for å gjette fra manifestet, og det skiller komponenter du faktisk bruker fra de som bare er til stede. Xygenis tilgjengelighetsanalyse reduserer falske positiver med opptil 70 %.
Tilgjengelighet av utnyttelse er den andre, og det er et faktum snarere enn en prognose. En fungerende offentlig utnyttelse, eller bekreftet utnyttelse i naturen, endrer prioriteten til et funn uavhengig av hva alvorlighetsgraden sier. Denne skillet har sluttet å være god praksis og blitt en forpliktelse: i henhold til Cyber Resilience Act har en produsent som blir oppmerksom på en aktivt utnyttet sårbarhet i produktet sitt en 24-timers rapporteringsklokke. Et program som ikke kan skille «aktivt utnyttet» fra «høy CVSS», kan ikke overholde den klokken.
Sannsynligheten for utnyttelse er det tredje, og det er det samme spørsmålet med prediksjonen lagt inn igjen. EPSS vurderer sannsynligheten for at en sårbarhet vil bli utnyttet i det fri i løpet av de neste 30 dagene, noe som er et helt annet spørsmål enn hvor ille det ville vært hvis det ble det. En høy CVSS-poengsum med en ubetydelig EPSS-poengsum er sjelden denne ukens arbeid.
- Forretningskontekst er den tredje, og det er den ingen generisk feed kan tilby. En tilgjengelig, utnyttbar sårbarhet i en internettbasert betalingstjeneste er ikke det samme funnet som den samme CVE i et internt rapporteringsverktøy.
Når disse filtrene brukes sammen, gjør de rutinemessig en liste ingen leser om til en liste noen fullfører. Kjøretid og tilgjengelighetskontekst etterlater vanligvis bare et lite mindretall av «kritiske» funn som fortsatt er kritiske. Xygeni behandler tilgjengelighet, utnyttelsestilgjengelighet, EPSS og forretningskontekst som konfigurerbare stadier i en prioriteringstrakt, opptil åtte av dem, slik at «nåelig og aktivt utnyttet» blir en stående kø i stedet for en spørring noen kjører manuelt.
Åpning av sårbarheter i npm-pakken uten å ødelegge bygget
Å finne er den enkle halvdelen. Grunnen til at sårbarheter i npm-pakker ikke er løst i flere måneder, er at det å fikse dem medfører en egen risiko, og utviklerne vet det.
Spørsmålet som er viktig før en oppgradering er ikke «oppdaterer denne CVE-en». Det er tre spørsmål samtidig: hvilke sårbarheter forsvinner med denne versjonen, hvilke nye som følger med, og om versjonen knekker koden min.
Xygeni viser alle tre for hver sårbare avhengighet, så valget står mellom synlige alternativer i stedet for et sprang. Deretter genererer Autofix pull request Med den oppdaterte versjonen bruker masseutbedring flere rettelser i én handling, og Xygeni Bot kjører på forespørsel, på pull requests eller daglig, slik at etterslepet krymper uten at noen planlegger det.
For transitive avhengigheter, der du ikke bare kan oppgradere en versjon du ikke har valgt, er det nyttige resultatet den korteste oppgraderingsstien i treet som løser meldingen, ikke et varsel som forteller deg at en pakke fire nivåer nedover er sårbar.
Før de sender: Hvor sjekken hører hjemme
«Før de sender» er en planleggingspåstand, og det kommer ned til tre plasseringer.
- I IDE-en, så en utvikler ser problemet når de velger avhengigheten, som er det billigste tidspunktet å endre den.
- På pull request, der en bot kommenterer hva som er endret og åpner rettelsen, og der en sikkerhetsport kan feile en bygging på funn over en terskel. Det er alene alvorlighetsgrad som gjør at team deaktiverer porten. Det er tilgjengelige og utnyttbare funn som gjør at de beholder den.
- Kontinuerlig etter utgivelsen, fordi en avhengighet som var ren ved sammenslåingen blir sårbar den dagen en veiledning publiseres. Kontinuerlig overvåking på tvers av registre er det som fanger opp det, uten at noen trenger å huske å skanne på nytt.
Og resultatet av alle tre hører hjemme i én prioritert kø ved siden av din SAST, hemmeligheterog beholderfunn, inkludert de som er hentet fra verktøy du allerede kjører. liste over sårbarheter som bor i sin egen konsoll er en liste som konkurrerer om oppmerksomhet med arbeidet den skulle informere.
Send løsningen, ikke funnet
En skanner som gir deg 400 npm pakkesårbarheter har ikke gjort jobben. Den har flyttet jobben.
Xygeni snevrer inn avhengighetsfunn etter tilgjengelighet, sannsynlighet for utnyttelse og forretningskontekst, viser hva hver oppgradering fikser og hva den kan ødelegge, og åpner pull request med den oppdaterte versjonen. Den kjører i din pipeline, produserer SBOM og VDR-utdata i SPDX og CycloneDX, bevisene CRA, NIS2 og DORA ber om, og plasserer avhengighetsfunn i samme prioriterte kø som resten av risikoen din, inkludert funn fra skannere du ikke erstatter.
Start gratis og skanne et arkiv, eller se hvordan tilgjengeligheten endrer listen.
FAQ
Hvordan sjekker jeg npm-pakker for sårbarheter?
Kjør npm audit For en umiddelbar visning, bruk deretter et verktøy med tilgjengelighetsanalyse for å begrense listen til funn der den sårbare koden faktisk kan kalles. Rådgivende databaser som OSV og GitHub Advisory Database er nyttige for å sjekke en bestemt pakke og versjon.
Is npm audit fix trygt å løpe?
Den ikke-tvungne versjonen er vanligvis trygg, siden den holder seg innenfor semver-kompatible områder. npm audit fix --force er ikke: den oppgraderer på tvers av større versjoner for å løse råd, og det er der avbrytende endringer kommer fra.
Hvorfor har jeg så mange sårbarheter i npm-pakker?
Fordi de fleste av dem er transitive. Du installerer en håndfull direkte avhengigheter og arver hundrevis av indirekte, hver med sin egen rådgivningshistorikk. Volumet er normalt. Det er triagen som mangler.
Hva er tilgjengelighetsanalyse?
Å avgjøre om utførelse i applikasjonen din faktisk kan nå den sårbare funksjonen i en avhengighet. Det er den største støyreduksjonen som er tilgjengelig innen avhengighetssikkerhet, fordi de fleste rapporterte sårbarheter ligger i koden applikasjonen din aldri kaller.
Bør jeg bruke CVSS eller EPSS til å prioritere?
Begge deler, av forskjellige grunner. CVSS beskriver hvor alvorlig en sårbarhet ville være hvis den utnyttes. EPSS anslår hvor sannsynlig utnyttelse er i løpet av de neste 30 dagene. Alvorlighetsgrad uten sannsynlighet produserer en kø sortert etter feil akse.
Hvor ofte bør jeg sjekke npm-pakker for sårbarheter?
Kontinuerlig, ikke etter en plan. En ren skanning på mandag betyr ingenting på onsdag hvis en advarsel lander på en pakke du allerede sender.
